Is there any difference between these two commands:

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


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

is the $? redundant in the first case?

  • So are the semicolons
    – jlliagre
    Nov 8, 2017 at 16:50
  • semicolons are beautiful and signal intent :) plus if I wanted I could do x; exit; on the same line, yolo Nov 8, 2017 at 16:58
  • Well, it could be argued $? do signal intent much more than the semicolons. Bash isn't C.
    – jlliagre
    Nov 8, 2017 at 17:01
  • yeah but could you put commands on the same line tho Nov 8, 2017 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 Nov 8, 2017 at 17:12

3 Answers 3


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 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.

  • true with regard to the exec call, so I should either get rid of exec or exit.. Nov 8, 2017 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 ;;; Nov 8, 2017 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, 2020 at 21:06

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.

  • 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, 2017 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, 2017 at 20:45

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
$ bash -c 'IFS=123; false; exit'; echo "$?"
$ bash -c 'IFS=123; false; exit "$?"'; echo "$?"
$ 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 ''.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .