Operator || disables set -e in subshells: Bug or feature?
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux hotel562.server4you.de 2.6.15-27-amd64-xeon #1 SMP PREEMPT Sat Sep 16 02:12:56 UTC 2006 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: Today I recognized a strange behavior of Bash with set -e and operator || (same for && as well). $ bash -ec 'set -e; ( set -e; /bin/false; echo wrong; ) || echo correct' wrong I would expect the output to be "correct", but it is "wrong". The bash comes from Ubuntu 6.06 LTS, however Debian Etch shows the same. Also ksh and zsh reproduce this strange behavior as well, so perhaps it's an undocumented feature? Same is true for "if" constructs: $ bash -ec 'set -e; if ! ( set -e; /bin/false; echo wrong; ); then echo correct; fi' wrong In contrast look at following line: $ bash -ec 'set -e; ( set -e; /bin/false; echo wrong; ); [ 0 = $? ] || echo correct' correct This outputs what I do expect from all above commands to output. Apparently the "||" operator (and "&&" and "if" as well) disable "set -e" within subshell execution. You even cannot re-enable it again! Is it only me who thinks that is very strange? At least this sideeffect *must* be documented somewhere very clearly (manual and help), as it may be crucial to have your commands terminated as soon as they do not return true. However surrounding commands with a sub-shell (which is convenient to PWD-changes or "catch exit" like in the "set -e" case) and then adding some '|| sequence' (or "if") does strange things. Note that this "set -e globally disabled" feature propagates through the complete script within your current shell. If you use any conditional on the command, even with function invocations, you will see this behavior. This means, when it comes to "set -e", there is a fundamental difference if you define some fn within the shell, and invoke "fn;" or "if fn; then ...", as in the first case it is run under "set -e" control, in the latter it isn't. Repeat-By: Following two commands behave strangely IMHO: bash -ec 'set -e; ( set -e; /bin/false; echo wrong; ) || echo correct' bash -ec 'set -e; if ! ( set -e; /bin/false; echo wrong; ); then echo correct; fi' Fix: Abstain from using script function with "if" or other conditionals. Instead check the return code manually, which is very tedious, like in: bash -ec 'set -e; ( set -e; /bin/false; echo wrong; ); [ 0 = $? ] || echo correct' Another "solution" seems to downgrade to Bash2 (taken from an old SuSE-Linux): $ bash --version GNU bash, version 2.05.0(1)-release (i386-suse-linux) Copyright 2000 Free Software Foundation, Inc. $ bash -ec 'set -e; ( set -e; /bin/false; echo wrong; ) || echo correct' correct However note on a very old KSH I can see the considered wrong behavior, too: $ ksh -c 'echo $KSH_VERSION; set -e; ( set -e; /bin/false; echo wrong; ) || echo correct' @(#)PD KSH v5.2.14 99/07/13.2 wrong
Bash enhancement request
Hi,
... I found this email address in the bash man-page, so I hope this is
the right address. I have a small feature request:
Can you make it possible that the EOF marker for here-documents be
nested too, i.e. preceeded with an arbitrary number of white spaces?
I often have this situation:
if [ condition ]; then
do something
if [ another condition ]; then
do something else
if [ -x "${ORACLE_HOME}/bin/sqlplus" ]; then
sqlplus -s <<-EOF
do some SQL here
EOF
fi
fi
fi
This looks nasty, especially if it occurs several times inside a
script. I would love to be able to align the "EOF" with the sqlplus
command to visually underline the block structure. Would that be
possible to do in future bash versions? I know I can use tabs under
certain conditions already but that doesn't suffice as I don't use a
tab width of 8 spaces.
Thanks very much and sorry if this was the wrong place to put the request.
--
cul8er
Paul
[EMAIL PROTECTED]
Re: Bash enhancement request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Foerster on 5/18/2008 11:03 PM: | | Can you make it possible that the EOF marker for here-documents be | nested too, i.e. preceeded with an arbitrary number of white spaces? Sorry, but this would violate the POSIX requirements on here-docs: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_07_04 | | Thanks very much and sorry if this was the wrong place to put the request. This is the right place, even though we are unable to do anything about it without breaking existing scripts. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgyHpAACgkQ84KuGfSFAYDMggCgx42Tf/bLz7jXhNlYHSC9ZcyY DFgAoJaJXVtx7h0e8GMnltI8AMCkLZYx =l+5e -END PGP SIGNATURE-
Re: Operator || disables set -e in subshells: Bug or feature?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to [EMAIL PROTECTED] on 5/19/2008 7:16 AM: | | Bash Version: 3.1 | Patch Level: 17 Consider upgrading. Bash is at 3.2, patch level 39. However, it also exhibits the same behavior. | | Today I recognized a strange behavior of Bash with set -e and operator || (same for && as well). POSIX states: When this option is on, if a simple command fails for any of the reasons listed in Consequences of Shell Errors or returns an exit status value >0, and is not part of the compound list following a while, until, or if keyword, and is not a part of an AND or OR list, and is not a pipeline preceded by the ! reserved word, then the shell shall immediately exit. http://www.opengroup.org/onlinepubs/009695399/utilities/set.html As worded, this is slightly ambiguous - you can argue, as ash does, that all simple commands in the subshell are subject to the most recent 'set - -e' also in that subshell; or you can argue, as bash, ksh, and zsh do, that the entire subshell is part of an exempt compound list, therefore the setting or clearing of 'set -e' in the subshell is irrelevant since the entire subshell is exempt. If you need more clarification, I would ask on the Austin Group mailing list if this ambiguity was intended. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgyJlMACgkQ84KuGfSFAYALcACg19ByNDCtc8KO6hVaMIIT0fPL 1JsAnRWwG5PJJtqbI46cH67JXlzBuFCS =Neop -END PGP SIGNATURE-
Bug with long color prompt + long command line?
I know the presence of "color" in my subject will cause people to tell me to read the FAQ section E3; so I already have ;-) Here's how I can reproduce: 1) set PS1 to use colors and reset the color at the end, as per the bash prompt HOWTO; eg. the "lightweight" prompt described here, http://www.gilesorr.com/bashprompt/howto/x924.html For example, here's my preferred prompt: PS1="\[\033[01;[EMAIL PROTECTED];34m\] \W \$\[\033[00m\] " As far as I can tell, everything is escaped properly... no? 2) cd to a directory with a name that is longer than $COLUMNS e.g. if COLUMNS == 80, something like this: mkdir \ reallylongname1345678901234567890123456789012345678901234567890123456789012345678901234567890 cd \ reallylongname1345678901234567890123456789012345678901234567890123456789012345678901234567890 3) type a command line longer than $COLUMNS; just enter random characters until it wraps. But don't hit enter, instead hit Ctrl-a (or Esc-0 if you prefer vi) Expected: The cursor moves to the beginning of the command line. Observed behavior: The cursor is displayed several characters after the beginning of the line, but edits behave as if you ARE at the beginning of the line, so what you see is not what you get, and editing the command line becomes almost impossible. I can reproduce this at the console or in any terminal I've tried (xterm, rxvt, gnome-terminal, ...) I checked with several coworkers and they can reproduce this too. Note that I don't get this problem if I leave out the color reset at the end of the prompt; eg this works fine: PS1="\[\033[01;[EMAIL PROTECTED];34m\] \W \$ " Workarounds: - don't use a color prompt - or, don't display \W or \w in the prompt Can anybody confirm if this is a real bug? Oh yeah: $ bash --version GNU bash, version 3.2.33(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. Thanks, - Paul Winkler
