I'm shelling out of my Ruby script to call a system command as follows
puts "Reached point #1"
begin
system("sh my_shell_script.sh")
rescue StandardError => e
puts "There was an error"
end
puts "Reached point #2"
I purposely added an error in my shell script so it would fail (i.e. I spelled "echo" as "eho"). I would expect that my Ruby script would output that it reached marker #1, and then rescue the error to display "There was an error".
Instead, I'm getting:
"Reached point #1"
line 1: eho: command not found
"Reached point #2"
It certainly throws the correct error, but the shell error from system(...) isn't rescued. Any thoughts as to why?
From the documentation for Kernel#system:
system returns true if the command gives zero exit status, false for non zero exit status. Returns nil if command execution fails. An error status is available in $?.
This means that you have many ways to proceed (none of which involve rescuing a raised error), depending on exactly which failure information you want. If you just want to distinguish successfully executing the command with zero exit status from all forms of failure, this is the translation from your code:
puts "Reached point #1"
unless system("sh my_shell_script.sh")
puts "There was an error"
end
puts "Reached point #2"
You can of course distinguish between command execution failure and non-zero exit status by looking at the return value, and you can get the exit status code from $? if needed, as per the documentation.
Instead, I'm getting:
"Reached point #1"
line 1: eho: command not found
"Reached point #2"
So in other words, it got rescued, but not in the way that you're expecting.
What you actually want is probably more like this:
ret = system("sh my_shell_script.sh")
puts $? unless ret
http://www.ruby-doc.org/core-2.0/Kernel.html#method-i-system
Related
I have a Ruby application which- unexpectedly - from time to time outputs a lone line feed character to stderr. I would like to find the place in my program where this happens. Static analysis (grepping case-insensitively for stderr) did not reveal anything useful, i.e. while there were some STDERR.puts statements, they always output also something else besides the \n, so they can't be the culprit.
Does anybody have some idea how I can somehow catch every write to stderr, and if it happens, at least print a backtrace, so that I can see where this write originates?
If you need to trap all calls to a particular object there's a lot of utility in method_missing:
class Exploder
def method_missing(name, *args)
raise "Method #{name} was called!"
end
end
You can then substitute it and trap calls:
$stderr = Exploder.new
Any call like $stderr.write will now raise an exception.
I was doing some programming and I get an error message when I try and run it. my code:
MsgBox ("hi")
sleep (2)
MsgBox ("you ok" vbYesNo, "how are you?")
Select Case result
Case vbYes,
MsgBox ("that's good!")
Case vbNo, MsgBox ("sorry to hear that.")
End Select
Line: 3
Char: 18
Error: Expected ')' Source: Microsoft VBScript compilation error.
The problem is as the error says you have compilation issues but looking at the rest of the example code you also have other issues waiting to be corrected.
Missing argument syntax in MsgBox() Function:
Line: 3
Char: 18
Error: Expected ')' Source: Microsoft VBScript compilation error.
is because the Function MsgBox() expects arguments separated by a comma but the argument separator after "you ok" is missing causing the compiler to throw the exception.
Cannot use parentheses when calling a Sub:
When calling a procedure that doesn't return a value using brackets around multiple arguments passed to the procedure will cause;
Microsoft VBScript compilation error: Cannot use parentheses when calling a Sub
There is a caveat to this which is if it's just one argument it will not fail to compile, but this isn't because it accepts one argument but because it sees the brackets as part of the argument not part of the procedure (Eric Lippert discusses this at length in his blog);
MsgBox("Hi") 'Will work
This is equivalent to writing;
Call MsgBox(("Hi")) 'Note the extra brackets
This can be a little confusing so when it comes to multiple arguments you might think this is ok;
MsgBox("you ok", vbyesno, "how are you?") 'This will error
But as the brackets now denote the argument parentheses it becomes invalid and throws a compilation error. To avoid this there are three things you can do;
Remove the parentheses
MsgBox "you ok", vbyesno, "how are you?"
Return a value (if the procedure can return a value)
result = MsgBox("you ok", vbYesNo, "how are you?")
As you check the value of result on the next line this would be the correct option as it result will contain the outcome of clicking either vbYes or vbNo in the MsgBox() function.
Use the Call statement to prefix the procedure call
Call MsgBox("you ok", vbYesNo, "how are you?")
Syntax Error:
Microsoft VBScript compilation error: Syntax error
This comes down to trailing commas after the Case arguments, just remove the commas and the code will compile.
Select Case result
Case vbYes
Call MsgBox("that's good!")
Case vbNo
Call MsgBox("sorry to hear that.")
End Select
The Sleep duration:
The Sleep() function expects a value expressed in milliseconds not seconds, at the moment the example code is waiting for 0.002 seconds. To wait for 2 seconds (which I'm assuming was the intention) use;
Call Sleep(2000)
Useful links
Answer to Can't Use Parentheses When Calling a Sub - VBScript
Is it possible to do the following in a expect script:
expect "phrase"
if timeout reached:
do this
else:
do that
See expect's man page:
expect [[-opts] pat1 body1] ... [-opts] patn [bodyn]
... ...
If the arguments to the entire expect statement require more than
one line, all the arguments may be "braced" into one so as to
avoid terminating each line with a backslash. In this one case,
the usual Tcl substitutions will occur despite the braces.
... ...
For example, the following fragment looks for a successful login.
(Note that abort is presumed to be a procedure defined elsewhere
in the script.)
expect {
busy {puts busy\n ; exp_continue}
failed abort
"invalid password" abort
timeout abort
connected
}
Whenever you want to execute something on the command line, you can use the following syntax:
%x(command to run)
However, I want to catch an error or at least get the response so I can parse it correctly. I tried setting:
result = %x(command to run)
and using a try-catch
begin
%x(command to run)
rescue
"didn't work"
end
to no avail. How can I capture the results instead of having them printed out?
So this doesn't directly answer your question (won't capture the command's output). But instead of trying begin/rescue, you can just check the exit code ($?) of the command:
%x(command to run)
unless $? == 0
"ack! error occurred"
end
Edit: Just remembered this new project. I think it does exactly what you want:
https://github.com/envato/safe_shell
You might want to redirect stderr to stdout:
result = %x(command to run 2>&1)
Or if you want to separate the error messages from the actual output, you can use popen3:
require 'open3'
stdin, stdout, stderr = Open3.popen3("find /proc")
Then you can read the actual output from stdout and error messages from stderr.
Here's how to use Ruby's open3:
require 'open3'
include Open3
stdin, stdout, stderr = popen3('date')
stdin.close
puts
puts "Reading STDOUT"
print stdout.read
stdout.close
puts
puts "Reading STDERR"
print stderr.read
stderr.close
# >>
# >> Reading STDOUT
# >> Sat Jan 22 20:03:13 MST 2011
# >>
# >> Reading STDERR
popen3 returns IO streams for STDIN, STDOUT and STDERR, allowing you to do I/O to the opened app.
Many command-line apps require their STDIN to be closed before they'll process their input.
You have to read from the returned STDOUT and STDERR pipes. They don't automatically shove content into a mystical variable.
In general, I like using a block with popen3 because it handles cleaning up behind itself.
Look through the examples in the Open3 doc. There's lots of nice functionality.
You need a mix of #Cam 's answer and #tonttu 's answer.
decent explanation of $? and others.
Edit: the domain http://blog.purifyapp.com is now in hands of a domain-squatter and scammer.
result = %x(command to run 2>&1)
unless $? == 0 #check if the child process exited cleanly.
puts "got error #{result}"
end
i have a Broken pipe (Errno::EPIPE) error popping up and i don't understand what it is or how to fix it. the full error is:
example.rb:19:in `write': Broken pipe (Errno::EPIPE)
from example.rb:19:in `print'
from example.rb:19
line 19 of my code is:
vari.print("x=" + my_val + "&y=1&z=Add+Num\r\n")
It means that whatever connection print is outputting to is no longer connected. Presumably the program began as input to some other program:
% ruby_program | another_program
What's happened is that another_program has exited sometime before the print in question.
Note:
The 1st section applies to Ruby scripts designed to act as terminal-based command-line utilities, assuming they require no custom handling or cleanup on receiving SIGPIPE, and assuming that you want them to exhibit the behavior of standard Unix utilities such as cat, which terminate quietly with a specific exit code when receiving SIGPIPE.
The 2nd section is for scripts that require custom handling of SIGPIPE, such as explicit cleanup and (conditional) output of error messages.
Opting into the system's default handling of SIGPIPE:
To complement wallyk's helpful answer and tokland's helpful answer:
If you want your script to exhibit the system's default behavior, as most Unix utilities (e.g., cat) do, use
Signal.trap("SIGPIPE", "SYSTEM_DEFAULT")
at the beginning of your script.
Now, when your script receives the SIGPIPE signal (on Unix-like systems), the system's default behavior will:
quietly terminate your script
report exit code 141 (which is calculated as 128 (indicating termination by signal) + 13 (SIGPIPE's number))
(By contrast, Signal.trap("PIPE", "EXIT") would report exit code 0, on receiving the signal, which indicates success.)
Note that in a shell context the exit code is often not apparent in a command such as ruby examble.rb | head, because the shell (by default) only reports the last command's exit code.
In bash, you can examine ${PIPESTATUS[#]} to see the exit codes of all commands in the pipeline.
Minimal example (run from bash):
ruby -e "Signal.trap('PIPE','SYSTEM_DEFAULT');(1..1e5).each do|i| puts i end" | head
The Ruby code tries to output 100,000 lines, but head only outputs the first 10 lines and then exits, which closes the read end of the pipe that connects the two commands.
The next time the Ruby code tries to the write end of that now broken pipe (after filling up the pipeline buffer), it triggers signal SIGPIPE, which terminates the Ruby process quietly, with exit code 141, which you can verify with echo ${PIPESTATUS[0]} afterwards.
By contrast, if you removed Signal.trap('PIPE','SYSTEM_DEFAULT'), i.e. with Ruby's default behavior, the command would break noisily (several lines of stderr output), and the exit code would be the nondescript 1.
Custom handling of SIGPIPE:
The following builds on donovan.lampa's helpful answer and adds an improvement suggested by
Kimmo Lehto, who points out that, depending on your script's purpose, receiving SIGPIPE shouldn't always terminate quietly, because it may indicate a legitimate error condition, notably in network code such as code for downloading a file from the internet.
He recommends the following idiom for that scenario:
begin
# ... The code that could trigger SIGPIPE
rescue Errno::EPIPE
# ... perform any cleanup, logging, ... here
# Raise an exception - which translates into stderr output -
# but only when outputting directly to a terminal.
# That way, failure is quiet inside a pipeline, such as when
# piping to standard utility `head`, where SIGPIPE is an expected
# condition.
raise if $stdout.tty?
# If the stack trace that the `raise` call results in is too noisy
# use something like the following instead, which outputs just the
# error message itself to stderr:
# $stderr.puts $! if $stdout.tty?
# Or, even simpler:
# warn $! if $stdout.tty?
# Exit with the usual exit code that indicates termination by SIGPIPE
exit 141
end
As a one-liner:
... rescue Errno::EPIPE raise if $stdout.tty?; exit 141
Note: Rescuing Errno::EPIPE works, because if the signal is ignored, the system call writing to the pipeline returns to the caller (instead of the caller process getting terminated), namely with standard error code EPIPE, which Ruby surfaces as exception Errno::EPIPE.
Although signal traps do work, as tokland said, they are defined application wide and can cause some unexpected behavior if you want to handle a broken pipe in some other way somewhere else in your app.
I'd suggest just using a standard rescue since the error still inherits from StandardError. More about this module of errors: http://ruby-doc.org/core-2.0.0/Errno.html
Example:
begin
vari.print("x=" + my_val + "&y=1&z=Add+Num\r\n")
rescue Errno::EPIPE
puts "Connection broke!"
end
Edit: It's important to note (as #mklement0 does in the comments) that if you were originally piping your output using puts to something expecting output on STDOUT, the final puts in the code above will raise another Errno::EPIPE exception. It's probably better practice to use STDERR.puts anyway.
begin
vari.print("x=" + my_val + "&y=1&z=Add+Num\r\n")
rescue Errno::EPIPE
STDERR.puts "Connection broke!"
end
#wallyk is right on the problem. One solution is to capture the signal with Signal.trap:
Signal.trap("PIPE", "EXIT")
If you are aware of some problem with this approach, please add a comment below.