Re: CVS commit: src/bin/sh

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

On Sat, Mar 17, 2018 at 23:10:38 +0700, Robert Elz wrote:

>     Date:        Sat, 17 Mar 2018 16:18:58 +0300
>     From:        Valery Ushakov <uwe%stderr.spb.ru@localhost>
>     Message-ID:  <20180317131858.GI3278%pony.stderr.spb.ru@localhost>
> 
>   | Exactly.  And when all of them are, it kinda defeats the purpose of
>   | them being in the ENVIRONMENT section.
> 
> Why?    What exactly do you think an environment variable is?

Environment variable is a name/value pair stored in an environment
that a C program can access via getenv() call.  Some C functions check
environment variables to change their behaviour.

Yes, shell "inherits" environment variables so that they become
exported shell variables.  But e.g. the value of PS1 affects shell
behaviour regardless of whether PS1 was inhereted from environment or
set in the current shell.  Any pertinent documentation that describes
PS1 describes *shell* variable PS1, regardless of its exported status.


>   |  Like, CFLAGS is not an "environment variable" just because 
>   |     $ CFLAGS=-g make
> 
> I disagree, that is exactly what it is.

I was too brief here, but the elaboration of the argument I had in
mind is basically the same as above.  The fact that CFLAGS is passed
to this make invocation via environment is completely accidental and
doesn't any meanignful way affects the semantic of CFLAGS as a make
variable.  I thought that was obvious enough and I also wanted to use
another example of a program that has notion of "variables" and that
can inherit/export them.


-uwe