This question already has answers here:
What is the $? (dollar question mark) variable in shell scripting? [duplicate]
(9 answers)
Meaning of $? (dollar question mark) in shell scripts
(8 answers)
Closed 2 years ago.
I'm new in variable concept in bash and I have seen some courses how to use and when to use special variable like $# to see how many arguments were passed in bash script and $# to see all the arguments supplied to the Bash script.
but I haven't understood $? and they just say that $? (The exit status of the most recently run process) and also I haven't got anything.
I need a little explanation and please give an example.
That definition you gave, i.e. the exit status of the most recently run process, is exactly what is is; but if you don't get how processes and commands in general work on the command line, I can understand how that might be a bit confusing.
In general, any command you run on the command line will have an exit code. In something like C/C++, you might have seen it as the return 0; appended at the end of every main() routine, and in shell scripts you might have seen it as exit 0. These return codes are the primary way to signal to the external environment (in this case the terminal) that things either ended well, or they didn't.
This is where $? comes into play. The convention on Unix systems is to have a process return exit code 0 if everything went fine, and return a non-zero value if it didn't. So, let's say I wrote a simple main routine like so:
int main(int argc, char* argv[]) {
if (argv[1] == "true") { // not quite right, but fine for examples
return 0;
}
else if (argv[1] == "false") {
return 1;
}
}
If I run this in the commnand line as ./a.out true, then this program will return 0 and the $? variable will be set to 0 as well. If I type ./a.out false, however, the program will return 1 and $? will also be set to 1, which indicates that something went wrong.
This seems pretty redundant if you're just toying around in the command line, running commands and then echo $? to see the result, but this really becomes useful in Bash scripting, where you might want to see what the command you just ran returns. For example, the diff command returns 0 if the two files you specify don't differ, and 1 if they do. This gives a neat way to introduce some control flow into your program, but you have to be careful, because $? is set after every command you run.
I hope this helped!
Related
This question already has answers here:
Assignment of variables with space after the (=) sign?
(4 answers)
Assing a variable and use it inside of if statement shell scripting
(2 answers)
Difference between sh and Bash
(11 answers)
Closed 3 years ago.
So there is a kernel adiutor for android, that let's you add custom controls with shell scripting. I'm trying to add a switch, but I have trouble setting the switch up correctly, when it's active, and when it's not. So there is a (text)file I'm trying to read (you will see it in the code), whether it's 0 or 1 inside, and that determines the switch on-off state.
I've tried with cat, read, everything, but honestly I think the problem is that I'm not familiar with sh scripting, and there is a problem with my syntax. Sometimes the script won't return anything when using cat. Also, su is available so that's not a problem, also the file has the correct permissions.
#!/system/bin/sh
var= $(<sys/class/lcd/panel/mdnie/hdr)
if ( "$var" = 0) then
echo 0
else echo 1
fi
The problem with my code is that right now it returns 1 (on), even when the file has a 0.
When assigning a variable in shell, there must be no space after the assignment sign. Also, make sure you use the correct syntax for conditions (and be aware of whitespace sensitivity):
var=$(cat sys/class/lcd/panel/mdnie/hdr)
if [ "$var" = "0" ]; then
# if [ "$var" -eq 0 ], if you want numeric comparison (won't really matter here)
echo 0
else
echo 1
fi
I narrowed my problem to a simple example which puzzles me.
I have tested it with GNU bash 4.2.46 on Centos and 4.3.46 on Ubuntu.
Here is a bash function that returns non-zero (error) return code when called alone but reverses its behavior when I use either && or || to chain another command. It looks like a bug to me. Can someone explain why it is behaving as such?
$ echo $0
/bin/bash
$ function TEST() {( set -e; set -o pipefail; echo OK; false; echo NOT REACHED; )}
$ type TEST
TEST is a function
TEST ()
{
( set -e;
set -o pipefail;
echo OK;
false;
echo NOT REACHED )
}
$ TEST
OK
$ echo $?
1
$ TEST || echo "NON ZERO"
OK
NOT REACHED
$ echo $?
0
$ TEST && echo "UNEXPECTED"
OK
NOT REACHED
UNEXPECTED
$ echo $?
0
What you are seeing is the shell doing what it is specified to do. Non-zero return codes in if statements and loops, and || && logical operators do not trigger detection by set -e or traps. This makes serious error handling more difficult than in other languages.
The root of all problems is that, in the shell, there is no difference between returning a non-zero code as a meaningful and intended status, or as the result of a command failing in an uncontrolled manner. Furthermore the special cases the shell has will disable checking at all depths in the call stack, not just the first one, entirely hiding nested failures from set -e and traps (this is pure evil if you ask me).
Here is a short example that shows what I mean.
#!/bin/bash
nested_function()
{
returnn 0 ; # Voluntarily misspelled
}
test_function()
{
if
[[ some_test ]]
then
nested_function
else
return 1
fi
}
set -e
trap 'echo Will never be called' ERR
if
test_function
then
echo "Test OK"
else
echo "Test failed"
fi
There is an obvious bug in the first function. This function contains nothing that disables error checking, but since it is nested inside an if block (and not even directly, mind you), that error is completely ignored.
You do not have that problem in, say, Java, where a return value is one thing, and an exception is another thing, and where evaluating a return value in an if statement will not prevent an exception at any level in the call stack from doing its job. You have try/catch to handle exceptions, and there is no way to mix exceptions with return codes, they are fundamentally different things (exceptions can be used as return values, but do not trigger the exception mechanism then as when thrown).
If you want to have the same thing in shell programming, you have to build it for yourself. It can be done using a "try" function that is used in front of all calls and keeps state for each nested call, a "throw" equivalent that allows exceptions to be thrown (not as non-zero return codes, but stored inside variables), and trap ... ERR to intercept non-zero return codes and be able to do things like generate a stack trace and trigger a controlled exit (e.g. deleting temporary files, releasing other resources, performing notifications).
With this approach, "exceptions" are explicitly handled failures, and non-zero return codes are bugs. You trade a bit of performance I guess, it is not trivial to implement, and it requires a lot of discipline. In terms of ease of debugging and the level of complexity you can build in your script without being overwhelmed when trying to trace the source of a problem, it is a game changer though.
Handling error codes is the intended behavior of || and &&.
set -e is a great practice in Bash scripting to alert you to any unwanted errors. When using it sometime to chain commands like
set -e
possibly_failing_command || true
echo "This is always reached"
in order to avoid the program stopping.
I am trying to access a string returned by a shell script which was called from a parent shell script. Something like this:
ex.sh:
echo "Hemanth"
ex2.sh:
sh ex.sh
if [ $? == "Hemanth" ]; then
echo "Hurray!!"
else
echo "Sorry Bro!"
fi
Is there a way to do this? Any help would be appreciated.
Thank you.
Use a command substitution syntax on ex2.sh
valueFromOtherScript="$(sh ex.sh)"
printf "%s\n" "$valueFromOtherScript"
echo by default outputs a new-line character after the string passed, if you don't need it in the above variable use printf as
printf "Hemanth"
on first script. Also worth adding $? will return only the exit code of the last executed command. Its values are interpreted as 0 being a successful run and a non-zero on failure. It will NEVER have a string value as you tried to use.
A Bash script does not really "return" a string. What you want to do is capture the output of a script (or external program, or function, they all act the same in this respect).
Command substitution is a common way to capture output.
captured_output="$(sh ex.sh)"
This initializes variable captured_output with the string containing all that is output by ex.sh. Well, not exactly all. Any script (or command, or function) actually has two output channels, usually called "standard out" (file descriptor number 1) and "standard error" (file descriptor number 2). When executing from a terminal, both typically end up on the screen. But they can be handled separately if needed.
For instance, if you want to capture really all output (including error messages), you would add a "redirection" after your command that tells the shell you want standard error to go to the same place as standard out.
captured_output="$(sh ex.sh 2>&1)"
If you omit that redirection, and the script outputs something on standard error, then this will still show on screen, and will not be captured.
Another way to capture output is sending it to a file, and then read back that file to a variable, like this :
sh ex.sh > output_file.log
captured_output="$(<output_file.log)"
A script (or external program, or function) does have something called a return code, which is an integer. By convention, a value of 0 means "success", and any other value indicates abnormal execution (but not necessarily failure) : the meaning of that return code is not standardized, it is ultimately specific to each script, program or function.
This return code is available in the $? special shell variable immediately after the execution terminates.
sh ex.sh
return_code=$?
echo "Return code is $return_code"
I am working on some piece of python code that calls various linux tools (like ssh) for automation purposes. Right now I am looking into "return code" handling.
Thus: I am looking for a simple way to run some command that gives me a specific non-zero return code; something like
echo "this is a testcommand, that should return with rc=5"
for example. But of course, the above comes back with rc=0.
I know that I can call false, but this will always return with rc=1. I am looking for something that gives me an rc that I can control.
Edit: first answers suggest to exit; but the problem with that: exit is a bash function. So, when I try to run that from within a python script, I get "No such file or directory: exit".
So, I am actually looking for some "binary" tool that gives me that (obviously one can write some simple script to get that; I am just looking if there is something similar to false that is already shipped with any Linux/Unix).
Run exit in a subshell.
$ (exit 5) ; echo $?
5
I have this function defined in .bashrc:
return_errorcode ()
{
return $1
}
So, I can directly use something like
$ return_errorcode 5
$ echo $?
5
Compared to (exit 5); echo $? option, this mechanism saves you a subshell.
This is not exactly what you are asking but custom rc can be achieved through exit command.
echo "this is a test command, that should return with " ;exit 5
echo $?
5
How and who determines what executes when a Bash-like script is executed as a binary without a shebang?
I guess that running a normal script with shebang is handled with binfmt_script Linux module, which checks a shebang, parses command line and runs designated script interpreter.
But what happens when someone runs a script without a shebang? I've tested the direct execv approach and found out that there's no kernel magic in there - i.e. a file like that:
$ cat target-script
echo Hello
echo "bash: $BASH_VERSION"
echo "zsh: $ZSH_VERSION"
Running compiled C program that does just an execv call yields:
$ cat test-runner.c
void main() {
if (execv("./target-script", 0) == -1)
perror();
}
$ ./test-runner
./target-script: Exec format error
However, if I do the same thing from another shell script, it runs the target script using the same shell interpreter as the original one:
$ cat test-runner.bash
#!/bin/bash
./target-script
$ ./test-runner.bash
Hello
bash: 4.1.0(1)-release
zsh:
If I do the same trick with other shells (for example, Debian's default sh - /bin/dash), it also works:
$ cat test-runner.dash
#!/bin/dash
./target-script
$ ./test-runner.dash
Hello
bash:
zsh:
Mysteriously, it doesn't quite work as expected with zsh and doesn't follow the general scheme. Looks like zsh executed /bin/sh on such files after all:
greycat#burrow-debian ~/z/test-runner $ cat test-runner.zsh
#!/bin/zsh
echo ZSH_VERSION=$ZSH_VERSION
./target-script
greycat#burrow-debian ~/z/test-runner $ ./test-runner.zsh
ZSH_VERSION=4.3.10
Hello
bash:
zsh:
Note that ZSH_VERSION in parent script worked, while ZSH_VERSION in child didn't!
How does a shell (Bash, dash) determines what gets executed when there's no shebang? I've tried to dig up that place in Bash/dash sources, but, alas, looks like I'm kind of lost in there. Can anyone shed some light on the magic that determines whether the target file without shebang should be executed as script or as a binary in Bash/dash? Or may be there is some sort of interaction with kernel / libc and then I'd welcome explanations on how does it work in Linux and FreeBSD kernels / libcs?
Since this happens in dash and dash is simpler, I looked there first.
Seems like exec.c is the place to look, and the relevant functionis are tryexec, which is called from shellexec which is called whenever the shell things a command needs to be executed. And (a simplified version of) the tryexec function is as follows:
STATIC void
tryexec(char *cmd, char **argv, char **envp)
{
char *const path_bshell = _PATH_BSHELL;
repeat:
execve(cmd, argv, envp);
if (cmd != path_bshell && errno == ENOEXEC) {
*argv-- = cmd;
*argv = cmd = path_bshell;
goto repeat;
}
}
So, it simply always replaces the command to execute with the path to itself (_PATH_BSHELL defaults to "/bin/sh") if ENOEXEC occurs. There's really no magic here.
I find that FreeBSD exhibits identical behavior in bash and in its own sh.
The way bash handles this is similar but much more complicated. If you want to look in to it further I recommend reading bash's execute_command.c and looking specifically at execute_shell_script and then shell_execve. The comments are quite descriptive.
(Looks like Sorpigal has covered it but I've already typed this up and it may be of interest.)
According to Section 3.16 of the Unix FAQ, the shell first looks at the magic number (first two bytes of the file). Some numbers indicate a binary executable; #! indicates that the rest of the line should be interpreted as a shebang. Otherwise, the shell tries to run it as a shell script.
Additionally, it seems that csh looks at the first byte, and if it's #, it'll try to run it as a csh script.