22

At first this was a bit funny, like playing "Bash Roulette" ...but now it's getting old lol

Any command in my terminal that exits with non-zero code closes my terminal window

I was told that perhaps I have set -e set in some bash script somewhere that my terminal sources.

I have checked .bash_profile / .bashrc / .profile and it doesn't look like set -e is in there.

Would there be any other obvious culprits?

  • 7
    Execute a set +e, does it repair the problem? If so, which I assume, then you need to keep looking for that set -e. It could be in the global versions of these files under /etc, or in any other script sourced from them. Move your config files away, if the problem is fixed then add back the lines in smaller chunks to see where it breaks. – egmont Nov 27 '17 at 23:21
  • 3
    PS4=' ${BASH_SOURCE}:$LINENO: ' bash -lixc true |& grep -e set -e trap could be informative. – muru Nov 28 '17 at 3:23
  • You can inspect the set of currently enabled shell flags with the special variable - like so: echo $-. – David Foerster Nov 28 '17 at 12:57
21

Alright, so indeed, it was a wayward set -e that caused my trouble.

The way I found the set -e was using bash -lx

The best thing to do would be to use:

bash -lx > lx.log 2>&1

then open that log file and do a search for set...

once you find that wayward set -e you can remove that line and your problem should be gone! (Machine restart might be a good idea tho).

In my case, the set -e was in a file that .bash_profile sources, but the line was not in .bash_profile itself.

  • 3
    Things that are safe to source in your shell is a much smaller set than just "random shell scripts". -e can be useful in actual scripts, for dumb error checking. (Or to make sure you didn't forget to error-check anything.) – Peter Cordes Nov 28 '17 at 10:17
  • Apparently that's case...i wish there was something like global set -e so that set -e only affects the containing script – Alexander Mills Nov 28 '17 at 15:33
  • @AlexanderMills, to do that, you could check $- to check for the flag in the inner script and restore its state at the end, or just reset it at the main script if you know you have sourced scripts that would set it – ilkkachu Nov 28 '17 at 15:39
  • So I guess local set -e could only be used in a bash function? – Alexander Mills Nov 28 '17 at 16:14
13

If you just want to solve the problem, include set +e in your .bashrc — at the end.

You can go digging—there are a lot of other places where a set -e might be—but that will take care of the lot.

If, however, the set -e is part of your $PROMPT_COMMAND then the above will not work. Try printf '%s\n' "$PROMPT_COMMAND" and see what's in it.

  • on my machine, when I open a terminal, printf '%s\n' "$PROMPT_COMMAND" yields just whitespace, nothing there – Alexander Mills Nov 27 '17 at 23:33
  • @AlexanderMills, then that's not what your problem is. One common use for $PROMPT_COMMAND is to update the terminal tab name or window name; MacOS X and Ubuntu both do this. See apple.stackexchange.com/q/220641/151730 for data on this for Mac. – Wildcard Nov 28 '17 at 4:00
  • I found an answer to the problem and added my own answer, set +e didn't work, perhaps because it was before the set -e call in my sourced bash files. – Alexander Mills Nov 28 '17 at 5:28
  • 1
    @AlexanderMills, yes, I thought that was implicit. I meant to append set +e to your .bashrc, not put it in at the start. I've made that explicit in my answer now. Good that you found the source! – Wildcard Nov 28 '17 at 5:31
  • Yeah, set +e is just a band-aid obviously, but you stated that – Alexander Mills Nov 28 '17 at 5:43

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.