Based on past experiences, I am assuming the e-mail this is a reply to
was meant to be sent to the list and I am quoting it in full and
replying on the list for that reason.
On 10/03/2023 21:24, Robert Elz wrote:
Date: Fri, 10 Mar 2023 18:13:00 +0000
From: "Harald van Dijk via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <bf68c134-3ed2-f6d7-0a24-6dd185c8a...@gigawatt.nl>
| Other shells that exit are bosh, yash, and my own. It's both what POSIX
| currently requires (contrary to what kre wrote on the bug)
That's not how I intended what I wrote to be interpreted, I meant exactly
what you said - when I wrote "most shells are doing what shells always have,
and what the standard requires", I meant "exiting".
I'm glad that that is what you meant. I wrote my mail before reading
your mail where you said you tested something different, so when I read
that you wrote that what most shells are doing is what the standard
requires, it could only be interpreted to mean the opposite of what you
intended.
But as I wrote in my previous message, I was actually testing "command eval"
rather than "command ." which I would normally expect to work about the same
way in this regard, but it turns out that not shells all do. Further, and
subsequent to when I sent that last message, I went and looked at my tests
again - the way I do these is by (for tests like this one) composing a
command line as input to one shell (each has its own xterm in my shell
testing root window page - they're all tiled), then pasting it into the
windows for all the others - then I can see the results from all of them,
at the same time, and easily compare what happened (the command always
starts $SHELL kind of like the example Geoff showed, except I do not quote
that, because sometimes SHELL needs to be "bash -o posix" or similar, and
I want that field split, not treated as a quoted word.
For this, I tested both without, and with, "command" present ... but it turns
out that somehow, for some of the shells, instead of running both tests, I
managed to paste the wrong command, and ran the one without "command" twice,
without noticing. That even included the NetBSD sh test, which contrary
to what I said before, turns out does do the same thing for "." and "eval"
in both cases (exit without command, not exit with it) which is what I had
expected, before I saw the results of the incorrect test - before I noticed
it was incorrect.
| and what I think is probably the right thing for shells to do.
I don't. I want to be able to source arbitrary script fragments, and
eval arbitrary strings (there are no security issues here, the fragments
and strings, are all provided by the user running the shell - anything that
could be done buried one of those other ways, could simply be done as a
command without subterfuge) without risking the shell exiting. Sometimes
running them in a subshell works, but only sometimes.
Sourcing arbitrary script fragments and having assurance that they do
not exit the shell is not reasonable, as the arbitrary script fragment
could contain an 'exit' command. In order to be able to do this, a
subshell is needed. That will mean that variable assignments etc. do not
persist in the parent shell, but that is unavoidable. Either the sourced
script affects the parent shell, in which case it can cause the parent
shell to exit, or it does not affect the parent shell.
Beyond shell options and variable assignments not persisting in the
parent shell, are there any other issues you see with running them in a
subshell?
| Whether bug 1629 should introduce a significant shell consistency issue
| is not separate from bug 1629.
Perhaps that one, and some new one, yet to be submitted, should be
considered together, but resolving 1629 the right way should not be
held hostage by other ancient weirdness that might not be so easy
to alter.
But perhaps after all, it might be - if it is only yash, bosh and your
shell not already continuing after "command . file" fails because of
a syntax error, then those might not matter, and those, plus, I
think, mksh and ancient pdksh (and consequently, probably ksh88 as well)
for "command eval 'gibberish<;)'" failing the same way then I'd guess
mksh can get changed, and the others also no longer really matter.
You have left out bash 4 here. For 'command eval', that version behaves
the same way as for 'command .' in that it causes the shell to exit on
syntax errors.
| Bug 1629 started as trying to see what
| shell authors are willing to implement.
No, it started because read errors were not being handled in a rational
way. A proposed solution depended upon what shell authors are willing
to implement.
True, I should have said "the discussion on bug 1629 started" rather
than "bug 1629 started".
| and I know bosh sadly isn't going to see an update anyway,
Really? I thought some group of people had taken over Schilling's stuff.
Whether they consider bosh worth continuing with I am not sure (it still
has more important issues than this remaining in it, and I don't believe is
used much, if at all).
In the entirety of 2022, no code changes had been made to the bosh.
However, I stand corrected, earlier this year they made a one-line
change to bosh in its handling of 'set -b'.
I do not expect bosh to have a large user base (even if it will be wider
than mine), but as I am sure Jörg would have pointed out, the shell has
historical significance in that it is a descendant of the Bourne shell
from which POSIX shell language is also derived. If this was something
he has not changed in his shell, changes are the original Bourne shell
behaved the same way. This would be worth checking. If it does behave
the same way, if it also matches what POSIX has specified all along, and
if that hasn't caused issues, that would be a strong reason not to
change POSIX to require something different. (Although I wouldn't be
opposed to a change to POSIX to *allow* something different.)
| but I would hope that authors
| of the other shells also have the good sense to implement something that
| makes sense to them and keep it internally consistent,
There is so much in the shell already which is not internally consistent,
that one more thing (particularly in an area rarely seen) would hardly be
noticed,
You and I likely have very different goals for our shells. A significant
goal for me is to have a shell that makes sense. If it doesn't make
sense, then especially if it isn't likely to be noticed, I'll make
changes to it so that it does make sense. "Make sense" is obviously a
bit subjective, but that's okay. It's when it *is* likely to be noticed
that I would be more hesitant to make changes, as something likely to be
noticed is something likely to be used in existing scripts, and "make
sense", to me, does not include taking risks with changes that have a
fair chance of breaking existing scripts.
but I very much doubt that there will not be at least an attempt
to alter the "what happens when there's an error which is "shall exit"
detected when running a special built-in as a sub-command of "command".
Syntax errors aren't the only one,
command eval 'shift 0 >/'
is another (redirection errors are also "shall exit" when used with
a special built-in as is being done here).
Right, this is treated as a fatal error in more shells, it causes bash
(all versions), bosh, my shell, pdksh/posh/mksh, yash, and zsh all to
exit, but dash and busybox ash, and ksh, do not exit. This, I believe,
is an area where POSIX is ambiguous and either behaviour is defensible.
POSIX states:
If the command_name is the same as the name of one of the special
built-in utilities, the special properties in the enumerated list at
the beginning of Special Built-In Utilities shall not occur. In every
other respect, if command_name is not the name of a function, the
effect of command (with no options) shall be the same as omitting
command.
Now, clearly, the command_name is the same name as the name of one of
the special built-in utilities, so the special properties at the
beginning Special Built-In Utilities must not occur. What POSIX fails to
specify, however, is whether this applies only to the special built-in
utility named by the command_name, or any special built-in utility
invoked as part of the 'command' command. Another example of this might be
command set -$
command eval set -$
assuming no -$ extension is supported by the 'set' command. It seems
clear that the first must not cause the shell to exit, and most shells
seem to agree (pdksh/posh being the exception that do exit, though not
the pdksh-derived mksh). The second is less clear, and it behaves the
same as your test in that it causes bash (all versions), bosh, my shell,
mksh, yash, and zsh to exit. dash and busybox ash, and ksh, are the
shells that do not exit.
pdksh/posh/mksh are also odd in that where the standard clearly
specifies that the shell shall exit, they cause the *function* to exit:
f() {
set -$
echo a
}
f
echo b
Assuming 'set -$' is treated as an error, neither 'a' nor 'b' should be
printed. In pdksh/posh/mksh, 'a' is not printed, but 'b' is.
I expect that will probably succeed, even if we all need to make some
more changes to almost never encountered parts of the shell, and most
probably it won't be "we all" in any case.
kre
As long as the changes make sense, I have no problem making changes to
my shell to match POSIX. However, I have resisted following suit before
where I felt the direction taken by POSIX was not a sensible one, I
intend to continue to do so, and considering you do the same in your
shell (I remember your unwillingness to add the POSIX-specified 'cd -L'
to your shell) I suspect you can understand this.
Cheers,
Harald van Dijk
