I am writing an R script as a command to run in terminal, and I found if an error happen when running this script, the command still returns a normal exit signal. So I cannot check the running results by checking [ $? -ne 0 ], it just returns succeed.
This is because R will continue running the next command when it encounters an error in previous command. Is there any way to solve this situation?
Best,
Shixiang
I combine tryCatch() and quit() to solve this problem. I firstly wrap my main function to tryCatch structure to let it detect if an error occurred, once an error is detected, I print the error message and call quit("no", -1) to quit R with exit status signature -1.
Related
I am new at coding. I am working on jupyter notebook using anaconda environment. I have this sample code where I am using sys.exit() command. When it gets executed it exits script with several error messages. Here is my sample code.
import sys
name = 'joh'
if name == 'john':
print('Name matches')
else:
print('Incorrect name')
sys.exit(0)
... some more code
Upon execution, it returns
Incorrect name
An exception has occurred, use %tb to see the full traceback.
SystemExit: 0
C:\Users\ankur.kulshrestha\AppData\Local\Continuum\Anaconda3\lib\site-packages\IPython\core\interactiveshell.py:2889: UserWarning: To exit: use 'exit', 'quit', or Ctrl-D.
warn("To exit: use 'exit', 'quit', or Ctrl-D.", stacklevel=1)
How can I gracefully exit the script without receiving all these error messages (apart from the first line which I have actually put in the code.)
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.
Let suppose there is a simple R script with only one statement:
q()
Using the R Script plugin in Pentaho Kettle/Spoon, executing the above R script causes Spoon/Kettle to crash.
How can we stop Kettle/Spoon from crashing abnormally with the above statement in our R script?
Kettle should instead stop executing the script and execution control should return to Kettle.
Try to use a return(value) instead q() to expect kettle handle the value from R script and continue the common kettle row flow.
i=14
l=8
if(i>l){q()}
print(i)
print(l)
above code is what I simplfied and when I run code above, it ends up with " R session aborted. R encountered a fatal error"
pls advise me way to avoid this error
Calling q() inside an if block from a script in the editor pane of RStudio crashes my RStudio in a similar manner, with a fatal error dialog box. I suspect this is an RStudio bug and should be reported if it recurs with the latest RStudio.
Just putting q() in a script not in an if block quits RStudio as expected, without error messages.
The correct way to terminate a script without killing R in any way is to use stop("why").
if(1>0)stop("am stopping")
print("No")
I've tried to run command in R 2.15.2
rsaga.geoprocessor(lib="ta_channels", module=0, param=list(ELEVATION="DEMflt.sgrd", CHNLNTWRK=paste("channels", i, ".sgrd", sep=""), CHNLROUTE="channel_route.sgrd", SHAPES="channels.shp", INIT_GRID="DEMflt.sgrd", DIV_CELLS=3, MINLEN=40), show.output.on.console=FALSE)
and I'm constantly getting this warning:
Warning message:
running command '"C:/Users/Nenad/Documents/R/win-library/2.15/RSAGA/SAGA-GIS/saga_cmd.exe" ta_preprocessor 2 -DEM "DEM1.sgrd" -RESULT "DEMflt.sgrd" -MINSLOPE "0.05"' had status 1
I use windows 8 and also tried to ran R as admin.
Any idea what is the problem? Thanks!
Idk how actual it is, but I've been struggling with "had status 1" warning a lot. Especially it got really annoying when I tried to use seasonal package to conduct the X13-ARIMA-SEATS seasonal decomposition of time series. The seasonal::seas command just didn't work, because in the code of this command there is a stop condition when running a certain stuff with cmd.exe returns non-zero status. While, as it was mentioned before, 'status 1' doesn't prevent command execution, in case of seasonal package it does.
The problem in my case was caused by some mistake in Windows Registry (Win 10), that in turn caused warning System cannot find the path specified when launching CMD.exe or PowerShell, which caused warning inside R as well. So to fix it:
Press Win+R -> regedit
In HKEY_CURRENT_USER\SOFTWARE\Microsoft\Command Processor folder clean the value of Autorun record (it should be empty)
Do the same for Autorun in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor
After these actions annoying warning with "has status 1" has gone and seasonal::seas started to work perfectly.
Hope it will be usefull for somebody.
Running system commands from R can be really tricky. In my experience, as long as the exit code is not 127 then the command did run, and you could use the intern=TRUE switch in the system command for a more verbose output. If you run the command again, the warning message could contain a errmsg attribute as well for some more info. hth