I am running Ruby as a wrapper to an EDA tool, in RH5.The tool segfaulted. However, the command line did not show any indication. Only when running the command that Ruby launched, did we learn that the segfault happened. How can I get the segfault message within the wrapper?
Thanks.
From Kernel#system documentation:
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 $?.
So, if you just want to make sure that everything went ok, you just check if the return value of system was true. If you want to specifically check if there was a segmentation fault, then the return value will be false and $: will be like this:
puts $?
#=> pid 3658 SIGSEGV (signal 11)
Related
I have the following Ruby code:
system "clang test.c -o test"
system "./test"
When I execute the above Ruby code, the stdout is printed, but the stderr is not.
When I run clang test.c -o test && ./test from the terminal, I get a segmentation fault, but the Ruby script does not print this.
How can I get the Ruby script to print all output from the system command?
The output "segmentation fault" is not printed by your test program itself. If you see this in your shell, it is in fact printed by the shell itself as a result of your program segfaulting.
Ruby does not print this. You can check the return code of your program after the system call returned however using the $? variable which contains a Process::Status object.
Here, you can e.g. check for signaled? to check if the process aborted due to a signal and then get this signal with the termsig method. The signal number for a segmentation fault is 11.
With your example, this could look like this:
system "./test"
# => false
$?.success?
# => nil
$?.signaled?
# => true
$?.termsig
# => 11
On Ubuntu 14's Ruby 1.9.3, when I run the script
#!/usr/bin/env ruby
and the script
#!/usr/bin/env ruby
exit 0
they do the same thing. In particular, a subsequent echo $? prints 0. How universal is this behavior? Can I safely omit exit 0 from the end of a nontrivial script?
Universally in UNIX, 0 is reserved for success and codes other than 0 - different sorts of errors.
In any normal language, unless your program throws some sort of exception or explicitly exits with a different code, you can safely assume that it exited with 0.
As per the documentation of Process#exit:
exit(status=true)
[...]The optional parameter is used to return a status code to the invoking environment. true and FALSE of status means success and failure respectively.
The interpretation of other integer values are system dependent.
Meaning Ruby exits with success by default, whatever success means for the underlying system.
As per the documentation of exit codes from The Linux Documentation Project:
[...] A successful command returns a 0, while an unsuccessful one returns a non-zero value that usually can be interpreted as an error code. Well-behaved UNIX commands, programs, and utilities return a 0 exit code upon successful completion, though there are some exceptions. [...]
Meaning you are will get 0 in a UNIX environments.
As per Microsoft's documentation on exit codes:
ERROR_SUCCESS
0 (0x0)
The operation completed successfully.
Meaning you will also get zero in Windows.
I know the $? means the return value of the lastly executed command. I was curious; if the command is invalid, then what will $? be?
It was 127. What does it mean? Why is it 127?
> echo a
a
> echo $?
0
> invalidcommandasdf
invalidcommandasdf: not found
> echo $?
127
The exit status does double duty: it might return information from a program, but it also might return information from whoever ran the program about how the program exited. While a program can, in theory, have any exit code in the range 0 to 255, many of them are assigned special meaning by, say, the POSIX standard, and are not available for use by the program itself.
126 and 127, for instance, are for use by the shell (or other command runner) running the command. 127 means the command could not be found, and 126 means the command was found, but wasn't executable.
Any exit status greater than 128 indicates the program exited due to a signal: 129 when it exits due to signal 1, 130 due to signal 2, etc. In general, 128 + k means it exited due to signal k.
(I'm not sure if 128 itself is reserved for anything in particular.)
In practice, this means your command should not explicitly use any exit code greater than 125. That generally shouldn't be a problem; most commands don't need to distinguish between 125 different errors (0, of course, means it exited without error.) curl is an example of a program that uses a lot of different codes, but even it only uses most of the available values between 1 and 90.
$? gives the exist status code of last executed command/process. 127 status code means Command Not found
for more detail : bash-shell-exit-status/
The primary use of "$?" is to check if the last run command has exit value true or false. You will get output as '0' or '1' where '0' is returned if the last run command is true and '1' if its false.
For unknown commands you will get output such as you have shown.
You can try this by simple using random string (sajdgh / uytwegf) as unrecognized commands and you can see you get a different output.
However the primary use of this command is check the logical status of last used command. Fire ls and see the output of "echo $?" will be '0' now just try 'cat unknown.txt' (considering you actually dont have file named 'unknown.txt') you will get output as '1'
On SSHkit-Github it's says:
All backends support the execute(*args), test(*args) & capture(*args)
From SSHkit-Rubydoc, I understand that execute is actually an alias to test?
What is the difference between test, execute, capture in Capistrano/SSHKit and when should I use either?
execute
just executes command.
raises error with non-0 exit.
test
method behaves exactly the same as execute however it returns boolean (true if command exits with a 0 exit, and false otherwise). it'll usually be used for control flow in your tasks.
capture
method will execute the command on the first matching server, and will return the stdout output of the command as a string. stderr output will be ignored (use ls 2>&1 to redirect stderr to stdout).
raises error with non-0 exit.
In the book learn ruby the hard way, I found a syntax to exit from the program:
Process.exit(0)
Why is the parameter 0 being passed in the exit method here even though it works if I pass another integer or do not pass any parameter? What is the significance of 0?
This is an 'exit code'.
This exit code has special meaning in some cases (see for example http://tldp.org/LDP/abs/html/exitcodes.html)
You can pass whatever you want, if the code isn't caught after, this will have no effects.
Here '0' is for 'Everything works fine !'
It is because when a child process is started (child process being your Ruby script in that case) the parent process (shell, system, etc.) can wait for it to finish.
Once it's finished, it can tell the parent process what is the status of it's execution. Zero usually means that the execution has been successfull and completed without any errors.
If you, on example, run your script from bash shell, and it will call Process.exit(0), you could check if it succeeded using $? variable:
$ ./my_ruby.script # calls Process.exit(0)
$ echo $?
0 # ok, script finished with no errors.