Date: Mon, 23 Oct 2023 11:02:10 +0100
From: "Geoff Clare via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <ZTZEoscT7q3oI7Kt@localhost>
| do a search for "unexported" in the subject field
| (which produces 114 results).
I have now read all 114 - I will admit with some trepidation, as Stephane
indicated that there were some messages from me, and I wondered if the
state of my knowledge about all of this 7 and a half years ago was sufficient
that I wouldn't now be appalled at some of what I may have written.
Fortunately, with one exception not germane to anything related to the topic
of my more recent message re-introducing this topic (not having remembered
it was ever considered before) I couldn't find anything I said back then
which I disagree with now.
Unfortunately, of the 114 messages in that thread, only the first few (I
didn't count how many, probably not more than a dozen or so) had any
relationship at all with the topic of my recent message, before the
thread branched off into a long discussion about the resolution of bug 854
(PATH searching for builtins) and then even further afield (bugs reported,
or not reported, about GNU utilities).
The 854 discussion is where I no longer agree with what I said then, then
I indicated I could almost understand the dumb "find builtins via path
searching" nonsense - now, with more appreciation of the issues, I don't
accept that at all - it is a completely absurd way to specify things.
I could expand upon why shells should simply consider all built-in
commands to be intrinsic (or if you prefer, to always find a built-in
command before going anywhere near a PATH search) another time, that's
not the current issue.
OK, now back to the real thing ... those messages did touch upon the
issue of whether or not the built-in utilities (or perhaps just the
intrinsic ones) can access unexported shell variables - but I didn't
see any definite conclusion reached during that discussion (rather a
difference of opinions) - and I certainly did not see any reference
to anything in the standard which is intended to specify which answer
is correct.
But that was only the first of the questions I asked in my message of
(the early hours of) Fri Oct 20 (it was still Thu Oct 19 most places).
And that question was just preparatory lead up to the real issue I
was seeking an answer to, one example of which was given by the
example command sequence
pwd; OLDPWD=/foo; OLDPWD=/bar cd /tmp; echo $OLDPWD
where the question is what should be output by that final "echo"
(and for this, let's all just assume that OLDPWD never contains
anything which might cause different versions of echo to produce
different results, replace that final 'echo $OLDPWD' by
' printf %s\\n "$OLDPWD" ' if you prefer, the two are intended to
produce identical results here.
That is, should that final echo output the same thing as the pwd
command printed, or something different, and if different, what
should that be, and why? That's first just a philosophical
question (but by all means read the definition of what cd is
required to do with OLDPWD to assist with that).
Then whatever you believe should be done here, where in the standard
is there any language that supports (or contradicts) your interpretation.
Nothing related to this was in that earlier thread. Apparently there
was an even earlier 2009 thread, which was much before my time, so I can't
say what was discussed in that one.
There's a related issue (a slight complication of that one) which applies,
or not, depending upon the answer to the first question, and this one,
which is where a built-in utility is required to modify a shell variable,
which it also uses as part of its operation - if the consensus is that
built-ins should only be able to access exported variables (as if the
built-in were not built-in) and the variable that is being modified in
the shell is not exported in the current environment - after the variable
has been modified by the built-in utility, if its value is to be used
again, should the value to be used be the one that was modified (which
according to the assumed rule is not accessible) or the original (perhaps
a default) value ?
While pondering this message, I have also realised there's another problem
with how getopts is specified (related to all of this, in a sense) which
I will add as a note to bug 1784.
kre
kre
