I've been unable to find a list of PuTTY (psftp.exe) exit values or return codes.
The only thing I found is this: https://the.earth.li/~sgtatham/putty/0.67/htmldoc/Chapter10.html#errors, but I need the return codes.
Your help is appreciated.
For most programs, there isn't generally a lot of informational content in exit codes. If you're trying to automate detailed error handling (why is your question tagged with java and c#?) you may need to parse error messages.
Looking at the source code, it appears that it returns 1 if there is a connection error or if it is unable to open a batch file, 2 if a command fails in batch mode, and 0 otherwise.
PSFTP has these exit codes:
0 - success
1 - fatal error
2 - command error (when -be is not used)
Related
The Jim Hester YouTube video video looks like a potentially really helpful way to put breakpoints in Rcpp code that passes some variables in unexpected ways. However, when I follow the start up directions (Rstudio console copied below) it fails with a message that is not helpful to a new user of lldb.
gcn#GCN-MacBook-Pro-7 ISIMIPData % R -d lldb
(lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R"
Current executable set to '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64).
(lldb) run
error: process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries when the attached failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))
(lldb)
The Console.app output that I could find is not very useful.
A later post post describes an updated process but it too fails in a similar way. I'm using Rstudio version 1.4.1717 with R version 4.1.
I'm trying to execute a command remotely through Robot Framework which is failing through Robot framework and giving me the wrong exit status of 13.
But if we run this manually exit status of TTman.sh is 112 which is actually pass(Not the standard return codes).
am I doing something wrong here?
You are not getting the remote code of the remote command, in fact the RC 13 you are getting from the run is most probably from the robotframework - on run completion its RC is the number of failed cases. I.e. 13 cases should have failed, when you observed this.
To get the return code of your command, a few changes in the case are needed; this is how the semi-last line should look like, with explanations below:
${rc}= Execute Command your_command_from_the_question &>/dev/null; echo $?
First, all the output of your command (stdout & stderr) is redirected to /dev/null - to not return it. Then the special var $? is printed - it holds the RC of the last executed command (and is available in most *sh variants, like bash).
Finally, that value is stored in the ${rc} robotframework variable, and you can do whatever checks you need on it, further in the case.
This approach has one drawback - as stderr is hidden, you will not be able to see any errors coming from running the command. But if it was not, then they would be interleaved with the RC, which would have required further processing of the {rc} var, to get the desired value. If you need it (the stderr output in case of failures), change accordingly.
P.S. don't add screenshots of a source in a question, it is much less usable than a text version.
I am trying to run Meteor on my computer and it does not work.
I get the exit code 8 + another error about not being able to allocate arraybuffer.
The error details are way too long for me to put everything here...
Do you have any ideas how to solde it?
Thanks in advance
Our automated build process incorporates a grunt task that periodically (more times than I'd like) generates a 6 return code.
According to the grunt web page 6 is a "Warning". Well okay, a warning for what? It's breaking our build since we would only pass on a 0 exit case. I'm looking at wrapping this in a script so I can catch this warning condition and generate a success exit code, though without any idea what the Warning might be I'm hesitant. It appears to work when I get this exit condition but would like a better understanding on what it may be.
Any ideas?
So this turned out to be an issue with grunt-contrib-less. I didn't recognize the associated less compiler error in our build log:
[39mnon_object_property_loadError: Cannot read property 'rules' of undefined in ../../XXXX/styles/modules/SomeLessFile.less on line null, column 0: [31m
Once I found this line a google search quickly found this in GitHub:
And have updated the grunt-contrib-less package. So far so good.
check http://gruntjs.com/api/grunt.fail:
If --stack is specified on the command-line and an error object was
specified, a stack trace will be logged.
Or try to run "grunt --verbose --force"
I've often been frustrated by R's cryptic error messages. I'm not talking about during an interactive session, I mean when you're running a script. Error messages don't print out line numbers, and it's often hard to trace the offending line, and the reason for the error (even if you can find the location).
Most recently my R script failed with the the incredibly insightful message: "Execution halted." The way I usually trace such errors is by putting a lot of print statements throughout the script -- but this is a pain. I sometimes have to go through the script line by line in an interactive session to find the error.
Does anyone have a better solution for how to make R error output more informative?
EDIT: Many R-debugging things work for interactive sessions. I'm looking for help on command-line scripts run through Rscript. I'm not in the middle of an R session when the error happens, I'm at the bash shell. I can't run "traceback()"
Try some of the suggestions in this post:
General suggestions for debugging in R
Specifically, findLineNum() and traceback()/setBreakpoint().
#Nathan Well add this line sink(stdout(), type="message") at the beginning of the script and you should get in console message both script content and output along with error message so you can see it as in interactive mode in the console. (you can then also redirect to a log file if you prefer keeping the console "clean")
Have a look at my package tryCatchLog (https://github.com/aryoda/tryCatchLog).
While it is impossible to improve the R error messages directly you can save a lot of time by identifying the exact code line of the error and have actual variables at the moment of the error stored in a dump for "post mortem" analysis!
The main advantages of the tryCatchLog function over tryCatch are
easy logging of errors, warnings and messages into a file or console
warnings do not stop the program execution (tryCatch stops the execution if you pass a warning handler function)
identifies the source of errors and warnings by logging a stack trace with a reference to the source file name and line number (since traceback does not contain the full stack trace)
allows post-mortem analysis after errors by creating a dump file with all variables of the global environment (workspace) and each function called (via dump.frames) - very helpful for batch jobs that you cannot debug on the server directly to reproduce the error!
This will show a more detailed traceback, but not the line number:
options(error = function() {traceback(2, max.lines=100); if(!interactive()) quit(save="no", status=1, runLast=T)})
One way inside a script to get more info on where the error occurred is to redirect R message to the same stream as errors :
sink(stdout(), type="message")
This way you get both messages and errors in the same output so you see which line raised the error...