tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Next steps for /bin/sh

On Sat, 27 Feb 2016, Robert Elz wrote:


That one relates to what
	sh -c 'set -e; false && false; echo foo'
should do.

When the PR was filed, and during the discussion, up till when the PR
was suspended, the POSIX standard in this area was nonsense - which I
believe is what caused the problems, with some believing the standard
should be followed, and others arguing for the "obviously" correct
and intended result.

In the interim, the 2013 version of the posix std has been published,
with considerably better wording relating to the -e option.  Now both
the standard and the "obviously correct" interpretation agree.  That
is, the shell given the comamnd above should exit(1) and not print "foo"
when the 2nd of the two "false" commands is executed.

Now all that would be simple, and an obvious change to make (once I figure
out what code changes are needed to correct it, but I hope that won't
be a problem) if it wasn't for one other issue.

That is: as far as I can determine, there isn't a single other modern
shell that implements this the way it should be implemented, they all
do the same as NetBSD's shell, which is to echo foo and exit(0).
It is possible the ancient /bin/sh on (some versions of?) Solaris that
everyone mostly loves to find ways to avoid because it is so ancient might
be the sole surviving (actually used) shell that does this correctly.
I don't have access to that one to test it.

So, if we make this change, we will be the one and only shell doing it
this way (at least for now: I suspect when bash 4.4 is released, at a
very minimum in posix mode, it will also change, others might update
eventually too).

So, should we change it?    If so, I'll look into what code needs altering.

In my opinion, having the standard finally updated is a big step in the right direction. Since both the standard and the "obviously correct" result now agree, I would vote in favor of fixing this bug. I'm quite certain it won't be the first time we're in the vanguard of correctness, and perhaps our efforts might be used by others to justify adopting the updated standard.


| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at |

Home | Main Index | Thread Index | Old Index