1

I encountered a bash script ending with the exit line. Would anything changes (save scaring users who 'source' rather than calling straight when the terminal closes )?

Note that I am not particularly interested in difference between exit and return. Here I am only interested in differences between having exit without parameters in the end of a bash script (one being closing console or process which sources the script rather than calling).

Could it be to address some less known shell dialects?

Serge
  • 3,387
  • 3
  • 16
  • 34
  • basically, `exit` will close the subshell you're in. This can be useful if you're in a script you want to stop running (less so if you `source` the script). – jeremysprofile Jul 04 '19 at 19:05
  • end of script file will close anyway – Serge Jul 04 '19 at 19:44
  • 1
    I don't know if this is a duplicate or not, but it's *not* a duplicate of the question referenced above. – William Pursell Jul 04 '19 at 19:56
  • 1
    The only benefit is that it makes things more explicit. `exit` with no parameters is the same as `exit $?` which is the same as not explicitly exiting at all. People often forget the the value returned by the script is important. Adding an explicit `exit` can remind the reader that the returned value matters. – William Pursell Jul 04 '19 at 19:58
  • Also, if you don't want to have to think about the implications of the last command's exit status becoming the status of the script itself, then it's reasonable to develop the habit of using an explicit `exit` whether or not it's really needed in a particular case. – Gordon Davisson Jul 04 '19 at 20:00
  • Lastly, If you have a bunch of stuff uncommented below the `exit`, it is simply ignored. So you can use `exit` to explicitly tell the interpreter where to stop processing the file. – David C. Rankin Jul 04 '19 at 21:03

2 Answers2

3

There are generally no benefits to doing this. There are only downsides, specifically the inability to source scripts like you say.

You can construct scenarios where it matters, such as having a sourceing script rely on it for termination on errors, or having a self-extracting archive header avoid executing its payload, but these unusual cases should not be the basis for a general guideline.

that other guy
  • 116,971
  • 11
  • 170
  • 194
  • You pointed out only benefits and no downsides while claiming the answer is the opposite. I would suggest filling out the answer with the downsides to show how your claim is true. – Tanktalus Jul 04 '19 at 22:15
0

The one significant advantage is that it gives you explicit control over the return code.

Otherwise the return code of the script is going to be the return code of whatever the last command it executed happened to be. Which may or may not be indicative of the actual success or failure of the script as a whole.

A slightly less significant advantage is that if the last command's exit code is significant, and you follow it up with "exit $?" that tells the maintenance programmer coming along later that yes, you did consider what the exit code of the program should be and he shouldn't monkey with it without understanding why.

Conversely, of course, I wouldn't recommend ending a bash script with an explicit call to exit unless you really mean "ignore all previous exit codes and use this one". Because that's what anyone else looking at your code is going to assume you wanted and they're going to be annoyed that you wasted their time trying to figure out why if you did it just by rote and not for a reason.

Perkins
  • 121
  • 6