How do I mark a rule in Waf such that the build doesn't stop on that rule's failure?
ex.
bld(rule="magicalcommand {SRC} {TGT}", source="somefile", target="othersuchfile")
where magicalcommand may somehow fail (but it's okay for that command to fail).
Solved it by turning the rule from a string into a function with the actual execution call wrapped into a try/except block:
def somefunc(task):
# set up the command string using task.inputs, task.outputs [, and task.env]
cmd = 'magicalcommand ' + task.inputs[0].abspath() + ' ' + task.outputs[0].abspath()
try:
return bld.cmd_and_log(cmd)
except Exception as e:
from waflib import Logs
Logs.info('cmd failed!')
return 0
bld(rule=somefunc, source='somefile', target='othersuchfile')
Note that I'm using bld.cmd_and_log, not bld.exec_command. The former actually throws on error (and supposedly supplies access to the stdout and stderr of the command through e on failure), the latter just kills the entire build process for me.
Related
I'm trying to add helpful messages for arbitrary builds. If the build fails the user can, for example, install the package with different arguments.
My interface idea is to provide a function, build-with-message, that would be called with something like this:
build-with-message
''Building ${pkg.name}. Alternative invocations are: ..''
pkg
My implementation is based on builtins.seq
build-with-message = msg : pkg :
seq
(self.runCommand "issue-message" {} ''mkdir $out; echo ${msg}'')
pkg;
When I build a package with build-with-message I never see the message. My hunch is that seq evaluates the runCommand far enough to see that a set is returned and moves on to building the package. I tried with deepSeq as well, but a deepSeq build fails on runCommand. I also tried calling out some attributes from the runCommand, e.g.
(self.runCommand "issue-message" {} ''mkdir $out; echo ${msg}'').drvPath
(self.runCommand "issue-message" {} ''mkdir $out; echo ${msg}'').out
My thought being that calling for one of these would prompt the rest of the build. Perhaps I'm not calling the right attribute, but in any case the ones I've tried don't work.
So:
Is there a way to force the runCommand to build in the above scenario?
Is there already some builtin that just lets me issue messages on top of arbitrary builds?
Here's me answering my own question again, consider this a warning.
Solution:
I've in-lined some numbered comments to help with the explanation.
build-with-message = msg : pkg :
let runMsg /*1*/ = self.runCommand "issue-message"
{ version = toString currentTime; /*2*/ } ''
cat <<EOF
${msg}
EOF
echo 0 > $out /*3*/
'';
in seq (import runMsg /*4*/) pkg; /*5*/
Explanation:
runMsg is the derivation that issues the message.
Adding a version based on the current time ensures that the build of runMsg will not be in /nix/store. Otherwise, each unique message will only be issued for the first build.
After the message is printed, a 0 is saved to file as the output of the derivation.
The import loads runMsg--a derivation, and therefore serialized as the path $out. Import expects a nix expression, which in this case is just the number 0 (a valid nix expression).
Now, since the runMsg output will not be available until after it has been built, the seq command will build it (issuing the message) and then build pkg.
Discussion:
I take note of Robert Hensing's comment to my question--this may not be something Nix was not intended for. I'm not arguing against that. Moving on.
Notice that issuing a message like so will add a file to your nix store for every message issued. I don't know if the message build will be garbage collected while pkg is still installed, so there's the possibility of polluting the nix store if such a pattern is overused.
I also think it's really interesting that the result of the runMsg build was to install a nix expression. I suppose this opens the door to doing useful things.
I am using CCL Lisp to run batches of experiments in parallel. On my machine, everything is running fine. However, I would like to use this on a server. When I execute this on a server, I always get the following error message:
> Error: on #<BASIC-CHARACTER-OUTPUT-STREAM UTF-8 (PIPE/7) #x302001C2725D> :
> Broken pipe during write
> While executing: #<CCL::STANDARD-KERNEL-METHOD CCL::STREAM-IO-ERROR (STREAM T T)>, in process listener(1).
My code always reaches the same point when trowing this error. An excerpt of the code is given below:
;; ... A really long function
;; write commands to processes
(format t ".. writing commands to process ~a:~%" counter)
(loop for c in commands
do
(format t " ~a~%" c)
(write-string c output-stream)
(princ #\lf output-stream))
(force-output t)
(force-output output-stream)
(finish-output output-stream)
#-lispworks
(close output-stream))
I think this error occurs inside the loop statement, since not all of the commands are written to the output stream.
How can I further debug this and solve this issue?
"Broken pipe" means that the process which is supposed to be reading from the pipe is dead when the Lisp process is writing to the pipe.
IOW, the problem is probably outside of Lisp. You need to see what is happening with the other process.
PS. You can combine your write-string and princ into a single write-line. Also, you don't need force-output if you are calling finish-output immediately.
i have a batch file which helps to start my rails server.when i am starting my batch file the command prompt is opening but here i need the cmd should not visible to user or it will execute at windows background.I am explaining mt .bat file code below.
c:
cd c:\\Site\swargadwara_puri
rails server
Please help me.
You could run it silently using a Vbscript file instead. The Run Method allows you running a script in invisible mode. Create a .vbs file like this one :
Option Explicit
Dim MyBatchFile
MyBatchFile = "C:\New Floder\toto 1.bat"
Call Run(MyBatchFile,1,False) 'Showing the console
Call Run(MyBatchFile,0,False) 'Hidding the console
'*********************************************************************************
Function Run(MyBatchFile,Console,bWaitOnReturn)
Dim ws,Result
Set ws = CreateObject("wscript.Shell")
'A value of 0 to hide the MS-DOS console
If Console = 0 Then
Result = ws.run(DblQuote(MyBatchFile),Console,bWaitOnReturn)
If Result = 0 Then
'MsgBox "Success"
Else
MsgBox "An unknown error has occurred!",16,"An unknown error has occurred!"
End If
End If
'A value of 1 to show the MS-DOS console
If Console = 1 Then
Result = ws.run(DblQuote(MyBatchFile),Console,bWaitOnReturn)
If Result = 0 Then
'MsgBox "Success"
Else
MsgBox "An unknown error has occurred!",16,"An unknown error has occurred!"
End If
End If
Run = Result
End Function
'*********************************************************************************
Function DblQuote(Str)
DblQuote = Chr(34) & Str & Chr(34)
End Function
'*********************************************************************************
The second argument in this example sets the window style. 0 means "hide the window, and 1 means "show the window"
Complete syntax of the Run method:
object.Run(strCommand, [intWindowStyle], [bWaitOnReturn])
Arguments:
object: WshShell object.
strCommand: String value indicating the command line you want to run. You must include any parameters you want to pass to the executable file.
intWindowStyle: Optional. Integer value indicating the appearance of the program's window. Note that not all programs make use of this information.
bWaitOnReturn: Optional. Boolean value indicating whether the script should wait for the program to finish executing before continuing to the next statement in your script. If set to true, script execution halts until the program finishes, and Run returns any error code returned by the program. If set to false (the default), the Run method returns immediately after starting the program, automatically returning 0 (not to be interpreted as an error code).
You can minimize the batch command, for example using:
START /MIN rails server
I am running my own proxy objects which extend org.mozilla.javascript.ScriptableObject.
I also have my own functions which extend org.mozilla.javascript.Function.
My desire is to have any exceptions thrown here return the line no and if possible the column number where they occurred in the evaluated script. Is this possible? I only have access to the context and the scope.
Whenever an exception is thrown from a script, Rhino throws RhinoException which already has line and column number (and more). However when you execute the script you need to provide the line number that will be used by Rhino as the starting line number. The actual line number of where the exception/error occurred will be relative to this number. So something line this:
//-- Define a simple test script to test if things are working or not.
String testScript = "function simpleJavascriptFunction() {" +
" this line has syntax error." +
"}" +
"simpleJavascriptFunction();";
//-- Compile the test script.
Script compiledScript = Context.getCurrentContext().compileString(testScript, "My Test Script", 2, null);
//-- Execute the test script.
compiledScript.exec(Context.getCurrentContext(), anyJavascriptScope);
In the above code, the starting line number is set to 2 (third parameter of the call to compileString()). When this is executed, Rhino will throw a RhinoException that will have the lineNumber property set to the value '3' (the first line is treated as the second line b/c we passed 2).
Hope this helps.
I wrote the following two functions, and call the second ("callAndWait") from JavaScript running inside Windows Script Host. My overall intent is to call one command line program from another. That is, I'm running the initial scripting using cscript, and then trying to run something else (Ant) from that script.
function readAllFromAny(oExec)
{
if (!oExec.StdOut.AtEndOfStream)
return oExec.StdOut.ReadLine();
if (!oExec.StdErr.AtEndOfStream)
return "STDERR: " + oExec.StdErr.ReadLine();
return -1;
}
// Execute a command line function....
function callAndWait(execStr) {
var oExec = WshShell.Exec(execStr);
while (oExec.Status == 0)
{
WScript.Sleep(100);
var output;
while ( (output = readAllFromAny(oExec)) != -1) {
WScript.StdOut.WriteLine(output);
}
}
}
Unfortunately, when I run my program, I don't get immediate feedback about what the called program is doing. Instead, the output seems to come in fits and starts, sometimes waiting until the original program has finished, and sometimes it appears to have deadlocked. What I really want to do is have the spawned process actually share the same StdOut as the calling process, but I don't see a way to do that. Just setting oExec.StdOut = WScript.StdOut doesn't work.
Is there an alternate way to spawn processes that will share the StdOut & StdErr of the launching process? I tried using "WshShell.Run(), but that gives me a "permission denied" error. That's problematic, because I don't want to have to tell my clients to change how their Windows environment is configured just to run my program.
What can I do?
You cannot read from StdErr and StdOut in the script engine in this way, as there is no non-blocking IO as Code Master Bob says. If the called process fills up the buffer (about 4KB) on StdErr while you are attempting to read from StdOut, or vice-versa, then you will deadlock/hang. You will starve while waiting for StdOut and it will block waiting for you to read from StdErr.
The practical solution is to redirect StdErr to StdOut like this:
sCommandLine = """c:\Path\To\prog.exe"" Argument1 argument2"
Dim oExec
Set oExec = WshShell.Exec("CMD /S /C "" " & sCommandLine & " 2>&1 """)
In other words, what gets passed to CreateProcess is this:
CMD /S /C " "c:\Path\To\prog.exe" Argument1 argument2 2>&1 "
This invokes CMD.EXE, which interprets the command line. /S /C invokes a special parsing rule so that the first and last quote are stripped off, and the remainder used as-is and executed by CMD.EXE. So CMD.EXE executes this:
"c:\Path\To\prog.exe" Argument1 argument2 2>&1
The incantation 2>&1 redirects prog.exe's StdErr to StdOut. CMD.EXE will propagate the exit code.
You can now succeed by reading from StdOut and ignoring StdErr.
The downside is that the StdErr and StdOut output get mixed together. As long as they are recognisable you can probably work with this.
Another technique which might help in this situation is to redirect the standard error stream of the command to accompany the standard output.
Do this by adding "%comspec% /c" to the front and "2>&1" to the end of the execStr string.
That is, change the command you run from:
zzz
to:
%comspec% /c zzz 2>&1
The "2>&1" is a redirect instruction which causes the StdErr output (file descriptor 2) to be written to the StdOut stream (file descriptor 1).
You need to include the "%comspec% /c" part because it is the command interpreter which understands about the command line redirect. See http://technet.microsoft.com/en-us/library/ee156605.aspx
Using "%comspec%" instead of "cmd" gives portability to a wider range of Windows versions.
If your command contains quoted string arguments, it may be tricky to get them right:
the specification for how cmd handles quotes after "/c" seems to be incomplete.
With this, your script needs only to read the StdOut stream, and will receive both standard output and standard error.
I used this with "net stop wuauserv", which writes to StdOut on success (if the service is running)
and StdErr on failure (if the service is already stopped).
First, your loop is broken in that it always tries to read from oExec.StdOut first. If there is no actual output then it will hang until there is. You wont see any StdErr output until StdOut.atEndOfStream becomes true (probably when the child terminates). Unfortunately, there is no concept of non-blocking I/O in the script engine. That means calling read and having it return immediately if there is no data in the buffer. Thus there is probably no way to get this loop to work as you want. Second, WShell.Run does not provide any properties or methods to access the standard I/O of the child process. It creates the child in a separate window, totally isolated from the parent except for the return code. However, if all you want is to be able to SEE the output from the child then this might be acceptable. You will also be able to interact with the child (input) but only through the new window (see SendKeys).
As for using ReadAll(), this would be even worse since it collects all the input from the stream before returning so you wouldn't see anything at all until the stream was closed. I have no idea why the example places the ReadAll in a loop which builds a string, a single if (!WScript.StdIn.AtEndOfStream) should be sufficient to avoid exceptions.
Another alternative might be to use the process creation methods in WMI. How standard I/O is handled is not clear and there doesn't appear to be any way to allocate specific streams as StdIn/Out/Err. The only hope would be that the child would inherit these from the parent but that's what you want, isn't it? (This comment based upon an idea and a little bit of research but no actual testing.)
Basically, the scripting system is not designed for complicated interprocess communication/synchronisation.
Note: Tests confirming the above were performed on Windows XP Sp2 using Script version 5.6. Reference to current (5.8) manuals suggests no change.
Yes, the Exec function seems to be broken when it comes to terminal output.
I have been using a similar function function ConsumeStd(e) {WScript.StdOut.Write(e.StdOut.ReadAll());WScript.StdErr.Write(e.StdErr.ReadAll());} that I call in a loop similar to yours. Not sure if checking for EOF and reading line by line is better or worse.
You might have hit the deadlock issue described on this Microsoft Support site.
One suggestion is to always read both from stdout and stderr.
You could change readAllFromAny to:
function readAllFromAny(oExec)
{
var output = "";
if (!oExec.StdOut.AtEndOfStream)
output = output + oExec.StdOut.ReadLine();
if (!oExec.StdErr.AtEndOfStream)
output = output + "STDERR: " + oExec.StdErr.ReadLine();
return output ? output : -1;
}