1

Is there any difference between these two commands:

   exec "$(dirname "$0")/suman-shell";
   exit $?;

and 

   exec "$(dirname "$0")/suman-shell";
   exit;

is the $? redundant in the first case?

| improve this question | |
  • So are the semicolons – jlliagre Nov 8 '17 at 16:50
  • semicolons are beautiful and signal intent :) plus if I wanted I could do x; exit; on the same line, yolo – Alexander Mills Nov 8 '17 at 16:58
  • Well, it could be argued $? do signal intent much more than the semicolons. Bash isn't C. – jlliagre Nov 8 '17 at 17:01
  • yeah but could you put commands on the same line tho – Alexander Mills Nov 8 '17 at 17:07
  • I use sc's in bash to put things on the same line and to signal intent. sometimes I write code without sc's, then go through it again later and add sc's after I determine that each line is correct. it's proof that everything works, you don't even need to test your code after that :) lol – Alexander Mills Nov 8 '17 at 17:12
5

There are several flaws in your script:

exec "$(dirname "$0")/suman-shell";
exit $?;

  • The first one is the ending semicolons are redundant. They are harmless but serve no purpose. An end of line is already a separator, semicolons are used as a separator between multiple commands on a single line. Their presence here is slightly worsen the code readability.

  • The second one is exit by default returns the exit status of the previous command, so stating $? is redundant, albeit signalling the intent.

  • The third one is exec never returns under normal circumstances1, so the exit call is not reached in the first place and is also redundant.

1 The only cases where exec returns is an empty argument, a broken redirection or the execfailbash option set (which is not the default setting). The first and second ones do not apply here, and there is no evidence the third one does.

| improve this answer | |
  • true with regard to the exec call, so I should either get rid of exec or exit.. – Alexander Mills Nov 8 '17 at 20:39
  • ixnay on the semicolon critique tho, there is nothing more beautiful than a properly placed semicolon, sometimes I put two or three just to look at them ;;; – Alexander Mills Nov 8 '17 at 20:39
  • Hmm, as beautiful as they might be, two or three semicolons in a row make nothing better than a syntax error as far as bash is concerned... – jlliagre May 22 at 21:06
5

From help exit:

Exits the shell with a status of N. If N is omitted, the exit status is that of the last command executed.

So yes, it is completely redundant.

| improve this answer | |
  • Or one could note that the difference in question occurs in a line of script that normally will never be reached, given the exec. – JdeBP Nov 8 '17 at 20:26
  • @IgnacioVazquez-Abrams The exit present in the script isn't reached in the first place. exec failing will directly exit the script bypassing any line that would follow. – jlliagre Nov 8 '17 at 20:45
3

Strictly speaking, there's a difference between exit and exit $? when $IFS contains digits when you forget to quote that $? and thus are invoking the split+glob operator:

$ bash -c 'IFS=123; false; exit $?'; echo "$?"
bash: line 0: exit: : numeric argument required
2
$ bash -c 'IFS=123; false; exit'; echo "$?"
1
$ bash -c 'IFS=123; false; exit "$?"'; echo "$?"
1
$ bash -c "exit ''"
bash: line 0: exit: : numeric argument required

In the first case, because the $? is unquoted, it's subject to word splitting. With $IFS containing 1, the content of $? (1) is split into one empty argument in bash, so it's as if you had called exit ''.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.