Re: CVS commit: src/bin/sh

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Sun, Mar 18, 2018 at 04:12:16 +0700, Robert Elz wrote:

>     Date:        Sat, 17 Mar 2018 22:52:51 +0300
>     From:        Valery Ushakov <uwe%stderr.spb.ru@localhost>
>     Message-ID:  <20180317195251.GJ3278%pony.stderr.spb.ru@localhost>
> 
>   | Environment variable is a name/value pair stored in an environment
> 
> If you stopped there I'd agree with you.
> 
>   | that a C program can access via getenv() call.
> 
> That's one way - not the only way though, and isn't really material
> 
>   | Some C functions check
>   | environment variables to change their behaviour.
> 
> And this is completely irrelevant - all kinds of different things
> can be done with them, as above, they are just name/value
> pairs.
>
>   | Yes, shell "inherits" environment variables so that they become
>   | exported shell variables. 
> 
> Where shells are a bit different than most other programs, is that
> most others simply pass through the environment (of which the
> environment vars are a part - often the whole but not necessarily)
> with some of them making small changes.
> 
> The shells on the other hand completely dominate the environment,
> generally consuming what is there at startup, and creating a whole
> new environment for the programs that they run.
> 
> There is no real distinction between which shell variables are
> environment variables and which are not - any might be - all of them
> might be.
>
> If you're thinking about things purely as a C coder, writing C code,
> then yes, there's a difference, but to the user of the shell, there
> isn't - all the vars in every sh script are potentially environment
> variables, and (if the script wants) can be inherited from, and
> exported to, other programs through the environment.  Trying to
> split them up is futile.

We must have so completely different ways of thinking about this,
because we take the same premises and then conclude from them to the
complete opposites.

IIRC, at the very beginning of Farmer's "To Your Scattered Bodies Go",
when all the people find themselves in the Riverworld, one lady
notices that where everyone is naked, nobody is.  To me it's precisely
because shell dominates the environment that it doesn't make any sense
to discuss these variables in the ENVIRONMENT section or to think of
them as, primarily, environment variables.

At this point I'm inclined to just chalk it up to English culture
being nominalistic par excelence and give up any further attempts to
find common viewpoint.


> Once again, what the section heading in the man page should be
> should reflect more what makes the man page more usable, rather than
> any meaningless debate about what is, and what is not, an
> environment variable - it is even less important (a point you made
> about a different issue a day or two ago) which mdoc markup macro
> gets used to refer to them (Dv vs Ev vs Li ...)

I'd say that discussing shell variables in a sub-section right next to
the sub-section on parameter substitution (like ksh(1) or bash(1)
manuals do) makes it more usable.

If there are no objections, I'd like to move that material as-is
(including LINENO section) accordingly and drop the ENVIRONMENT
section.

-uwe