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".
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.
| 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.
| 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.
| 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).
| 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, 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).
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
