(drifting away from redirection, latching on a small part of your
message instead)
On Sun 25 Nov 2018 at 02:38:20 +0700, Robert Elz wrote:
> Clearly that behaviour is required, we do not want to have to write
>
> X=1 :
>
> in order to get X to be 1 on the next line. (All shells do it this way.)
Actually, I would expect X to remain unset (or set as it was before) on
the next line. Just like it works with
X=1 /some/external/command
And that is what bash seems to do. Our /bin/{,k}sh however do set X (but
not in the exported environment).
I tried finding in sh(1) (on NetBSD 8.0) how this is documented to work.
But I could only find
Commands
The shell interprets the words it reads according to a language, the
specification of which is outside the scope of this man page (refer to
the BNF in the POSIX 1003.2 document). Essentially though, a line is
read and if the first word of the line (or after a control operator) is
not a reserved word, then the shell has recognized a simple command.
Otherwise, a complex command or some other special construct may have
been recognized.
Simple Commands
If a simple command has been recognized, the shell performs the following
actions:
1. Leading words of the form "name=value" are stripped off, the
value is expanded, as described below, and the results are
assigned to the environment of the simple command.
Redirection operators and their arguments (as described below)
are stripped off and saved for processing in step 3 below.
and no description of whether this may include "Built-ins" or "special
built-ins" (which don't seem to be defined at all). Given this lack of
description, one would assume that the "built-in"s are included in the
"simple command"s. Built-ins definitely qualify for redirection (as
discussed) so that argues for identical treatment.
I couldn't find this out from the bash(1) manual either.
Given the phrasing "the environment of the simple command" I would
expect the assignment to be temporary, even if "Shell built-ins are
executed internally to the shell, without spawning a new process." as
claimed in section "Search and Execution".
Besides, some commands are not always built-ins, such as test, and
changing assignment/redirection behaviour based on whether this shell
has it as a built-in or not seems like a bad idea to me. (Test is an
interesting case because it is not documented in sh(1) to be a built-in,
yet "type test" says it is)
Furthermore, that "X=1 :" has an effect on non-exported shell variables
makes it deviate even more from "X=1 /normal/command" because that only
has effect on environment variables, and has nothing to do with shell
variables.
So, I would argue that we must change sh and ksh to make sure that "X=1 :"
has no noticeable effect on X in the next line, whether shell or
environment variable.
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power
\X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond
Attachment:
signature.asc
Description: PGP signature