Since there appear to be no more opinions on the -n issues perviously
mentioned, I am planning on sending in a patch with -n "fixed' the
way previously described (incorporating David Holland's suggestion).
I've actually had this in the shell sources I have been using, and testing
against, for a while now (well, for however long since the issue arose,
a week or so I guess) with no problems - I have been just ripping out these
changes before making an update patch whenever they would affect things
for the previous patches.
Second, as some of you know, I have been cleaning up (so of) the open
sh related PRs (there are a few I won't touch.) The next one on my
list is PR 38736 (currently suspended) - another that relates to "set -e".
That one reported 4 problems, 2 of those are long fixed. One is now
regarded by everyone (I believe) as an erroneous report. So all that
is left is the fourth.
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.
Third, it has been brought to my attention that the bug in (my) PR
bin/50834 is actually (slightly) more of a real issue than I thought
it was (I had intended just leaving that issue sit there as being 100%
irrelevant - but it turns out it isn't.) So, that one is now on my
list to fix. (This is the one where unquoted ${unset_var-} produces
a null string instead of nothing.) No need for discussion on this.
Fourth, and last for now PR bin/35423 (about sh handling of file names
containing chars like 0x80 0x81 ...) is hard to fix in general, but easy
to copy the FreeBSD semi-solution, and at least make it that the chars
that cause a problem are ones that are not legal in UTF-8, rather than
the current set. This is still not a general solution, but it is a
trivial change, and will (I believe) fix much of the problem. Does
anyone have any problem with that being done ?
There are, of course, still more open PRs on /bin/sh, and some of them I
will get to eventually, but this list of (possible) fixes are enough
to consider today, I believe.
kre
