leo@philmds.UUCP (Leo de Wit) (10/03/88)
In article <13810@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >Regarding `set -e': again, beware! Old versions of /bin/sh will >exit if the test portion of an `if', `while', or `until' returns >a nonzero status, if `-e' is set. (These are fixed in 4.3BSD-tahoe.) But this is according to the spec: exit *IMMEDIATELY* if a command fails. Since the test portion is a command list, the first command of this list that fails should force an exit. However I agree the fix perhaps makes more sense. Maybe we need a new metacharacter (another one!) to indicate "ignore this command's exit status with regard to -e"; compare with make's - . >Incidentally, this bug in the 4BSD `/bin/sh'es accounts for >makefile lines like > > -[ -d ${DESTDIR}${LIBDIR} ] || mkdir ${DESTDIR}${LIBDIR} > >where the `-' before the test `[' seems erroneous: it tells make to run >sh without the -e flag, so that the mkdir can happen. An alternate >workaround is to use > > set +e; [ -d ${DESTDIR}${LIBDIR} ] || mkdir ${DESTDIR}${LIBDIR} > >which has the advantage that if mkdir fails, make stops. Playing around with -e revealed some funny things: After a set -e, $- contains not only e but also s: $ echo $- $ set -e $ echo $- se After typing a non-existing command, this shell exited, although it was started as an interactive shell (explicitly setting -i didn't make any difference). Since I had rn as a stopped job, I got: Caught a SIGTERM--.newsrc restored and I was logged off the system 8-) ! (Yes, Bourne shells doesn't have job control, but this was a Bourne derivative with job control; the /bin/sh suffered however from the same problem). After a set +e, an e flag in $- is not discarded; it seems to be treated as setting a positional parameter, but $- is changed (starting without the error flag): $ echo $- $ set +e $ echo $- s $ echo $1 +e so +e doesn't seem to work on my system. This happened with /bin/sh under Ultrix 2.0. Any comments? Leo.
chris@mimsy.UUCP (Chris Torek) (10/03/88)
>In article <13810@mimsy.UUCP> I noted: >>Regarding `set -e': again, beware! Old versions of /bin/sh will >>exit if the test portion of an `if', `while', or `until' returns >>a nonzero status, if `-e' is set. (These are fixed in 4.3BSD-tahoe.) In article <827@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >But this is according to the spec: exit *IMMEDIATELY* if a command fails. Well, yes, it *does* match the specification (in a twisted sort of way). It is merely useless. (We wanted to *test* something!) >However I agree the fix perhaps makes more sense. Maybe we need a new >metacharacter (another one!) to indicate "ignore this command's exit >status with regard to -e"; compare with make's - . Just use (set +e; cmd). (More on this in a moment.) >Playing around with -e revealed some funny things: > >After a set -e, $- contains not only e but also s: > >$ echo $- > >$ set -e >$ echo $- >se The `-s' option means `reading stdin'; it gets set automatically *after* the shell sets up $-. When you `set <anything>', sh updates its list of currently set flags, and -s suddenly appears. I regard this as a minor bug, which I may fix later. >After a set +e, an e flag in $- is not discarded; it seems to be treated >as setting a positional parameter ... +e doesn't seem to work on my system. >This happened with /bin/sh under Ultrix 2.0. Any comments? I must have been living in an alternate universe for the last few years :-) . `set +opt' fails in the 4BSD `/bin/sh'es. The odd thing is that I remember using it, and remember it working. . . . At any rate, `set +opt' is a SysV (SysIII?) addition. It is present in recent SunOS releases. With any luck it will also be in 4.4BSD. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris