bash script invocation shows inconsistent behavior

Question

I have written a test script( let's call it test.sh) in bash. and the start of the script has following declaration:

#!/bin/bash -e

followed by some code.

Now it shows different results when i invoke it as bash test.sh versus ./test.sh. How is it possible. I thought by default ./test.sh reads the default shell from the first line of script and invokes it with that. Is my understanding correct.

It only does that if you don't invoke it with another command. — 123
– 123, Commented Feb 8, 2016 at 10:25
If you want the -e behaviour in your script regardless of how it was called, use set -e instead. — choroba
– choroba, Commented Feb 8, 2016 at 10:46

Community · Accepted Answer · 2017-04-13 12:36:24Z

2

The #!/bin/bash -e shebang is only used when you (try to) execute a file (that isn’t a binary executable) as a command. This line informs the kernel which executable should be used to interpret the code in the script. See the shebang Wikipedia article for more information.

When you run ./test.sh, your current shell starts a new Bash sub-process with the -e option and this new process is the one that executes the commands in the script file.

When you run bash test.sh, you’re explicitly starting a new Bash sub-process (this time without the -e option) and it starts executing the commands in the file. When it encounters the shebang in the first line, it just treats it the same as any other comment beginning with #. (The shebang is also ignored as just another comment if you source the file using . test.sh).

To ensure that the Bash shell behaves a certain way, it’s best to use the set builtin instead of providing an option when invoking Bash. E.g., to ensure the shell exits when a command returns a non-zero status, you should include set -e at or near the start of the script.

For more in-depth information about how commands are executed with a Linux kernel, see this answer to What is the difference between running “bash script.sh” and “./script.sh” and the execve man page.

edited Apr 13, 2017 at 12:36

CommunityBot

11 silver badge

answered Feb 8, 2016 at 11:57

Anthony Geoghegan

12.1k5 gold badges54 silver badges59 bronze badges

Sign up to request clarification or add additional context in comments.

4 Comments

Walter A Over a year ago

Also note differences between using bash test.sh and sourcing the file (when you source the file, an exit will throw you out of the calling shell, when bash test.sh is finished changes in working dir and variables are lost).

Anthony Geoghegan Over a year ago

@WalterA I've been there. It's particularly annoying if you're debugging and also set -u but the script exits early (before the set +u and set +e commands). That stopped me using source or . when developing/debugging shell scripts. :)

Ankit Kumar Over a year ago

@AnthonyGeoghegan thanks for clearly explaining the behavior. but my question is still unanswered as to why would i get a incorrect result when executing the script like ./test.sh and i get the correct result if i run it bash test.sh way?

Anthony Geoghegan Over a year ago

Hi @AnkitKumar I answered the two questions, How is it possible? and Is my understanding correct? to the best of my possibilities given the (general) information provided. If you want help debugging a related problem specific to your script, it would be better to create a How to create a Minimal, Complete, and Verifiable example and use it as the basis for a new, more specific (non-general) question.

Collectives™ on Stack Overflow

bash script invocation shows inconsistent behavior

1 Answer 1

4 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

4 Comments

Your Answer

Sign up or log in

Post as a guest

Related