Date: Fri, 10 Mar 2023 23:40:18 +0000
From: "Harald van Dijk via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <ec9488fb-943d-dcaf-0885-c7d76611d...@gigawatt.nl>
| 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.
Thanks, and yes, it was - my MUA absolutely believes in the one true
meaning of Reply-To (where the author of the message to which the reply
is being sent requests that replies be sent -- to addresses in that field,
and no others). I need to manually override it when I choose to ignore
that request and send to different addresses (which is allowed, but in
general, done only with proper consideration of why). This list always
directs that all replies go only to the author of the message, and never
to the list itself. Irritating...
| 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.
Of course, deliberate exits aren't the issue, only accidental ones.
| 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?
The whole point of many . scripts is to alter the shell's environment,
if they were just arbitrary commands, not intended to affect the current
shell, they'd just be sh scripts, and run the normal way. The very act
of using the '.' command more or less means "must run in the current shell).
"(. file)" is silly, "file" would accomplish the same thing (if executable,
otherwise "sh < file" after finding the path to file) in a more obvious way.
Apart from options and variables, . files often define functions, change
the umask and perhaps ulimit, and may alter the current directory, set exit
(or other) traps, ... anything in fact.
As an example, consider what you might put in your .profile or $ENV
file - those are run in more or less the same way as a '.' file (just
without the PATH search to locate the file). XRAT C.2.5.3 says almost
exactly that about ENV. (Strangely though, even though .profile is
mentioned several times as a place where things can be set, it doesn't
appear in the standard (as something that shells process) at all - which
is kind of odd really, since it is considerably older then ENV, and as best
I can tell, supported by everything. The closest that we get is a mention
in XRAT that "some shells" run it at startup of a login shell. Which are
the other shells? That is, the ones that don't run .profile? And I don't
mean in situations like bash, which prefers .bash_profile if it exists.
I doubt that you'd want those scripts run in a subshell environment,
I also doubt that you want the shell to exit if there's an error in
one of them. How would you ever be able to log in (and start a shell)
if it exited before you ever had a chance to run a command? If you can't
log in, because your shell won't start, how would you ever fix the problem?
As best I can tell (I have done very limited testing of this) shells tend
to simply abort processing one of those scripts upon encountering an error
(like a syntax error, etc - not executing "exit" - that should exit) and
just go on to the next step of initialising the shell. They don't just
exit because there's a syntax error - most shells report the error (not all),
but I couldn't find one which exits.
| You have left out bash 4 here.
For the same reason I didn't include ancient versions of all the
other shells either. That's obsolete, not going to change in the
future, and has been replaced. [And because I happen not to have
a binary of it at the minute - I could make one, I do have sources,
just don't really see the need.]
| 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.
So is/was ksh88, and then ksh93 ... they were just modified more.
| (Although I wouldn't be
| opposed to a change to POSIX to *allow* something different.)
As I hinted in the note in bugid:1629 which spawned this discussion
(bugnote:6200) I expect this part might need to move to "may exit" rather
than "shall not exit" (away from "shall exit" which it is now, in the
cases in question, not all) for a release cycle (or two) - but then again
given the number, and popularity, of the shells which already don't exit
in these circumstances, perhaps that won't be needed. That should be
discussed further.
The reason that read errors are different in this regard (at least in
the main script, not in . files -- not sure it is possible to have an
equivalent to a read error in "eval" - perhaps an EILSEQ (bad char encoding)
in the string might count? -- and that the shell needs to exit, is that
there is nothing else that it can do - if reading a command just gives
an error, deciding to go back and read another command is folly. That's
different than syntax errors, they're not really the same thing, and don't
necessarily need to be treated the exact same way.
| As long as the changes make sense, I have no problem making changes to
| my shell to match POSIX.
Yes, though as you hinted in a section of your message I deleted, "make
sense" is rather subjective. I tend more to more ask myself "does this
seem like the right thing to do". Still subjective, but a better guide
to what should be being considered instead of just "could this be better?"
which "make sense" is often equivalent to.
| 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.
I do. We still don't (never will, though some years ago, there was a
half hearted attempt) support that. I am not planning on supporting
"declaration utilities" either - that's another bizarre, inconsistent,
and completely unnecessary change. Our "export" (etc) will continue
to have its args processed in exactly the same manner as any other
command, before anyone looks to see what the command is. By the time
anyone knows it is the "export" command (or readonly, or whatever else
might be added), it is too late to redo the arg processing, the original
strings (words) no longer exist. (This is different than the special
processing of "trap" in subshells, etc, which we also do not do by attempting
to look at the command line before deciding upon magic action, but within
the trap command itself).
I have no objection to anyone deciding to ignore what the standard says
if they disagree with it - that's the right thing to do, and how changes
to some of the more ancient crud can eventually get fixed. I might disagree
with whether a particular issue is one that rises to the state where it
ought be ignored - eg: just recently, Chet and I had a "discussion" on
whether or not there was any point to the special builtin distinction, other
than history. He feels not, I disagree. That's fine.
kre
