Re: why does </proc/self/environ not work in bash?

[Chet Ramey]

On 2/12/24 4:09 PM, Christoph Anton Mitterer wrote:
> On Mon, 2024-02-12 at 10:33 -0500, Chet Ramey wrote:
> > "Environment variable names used by the utilities in the Shell and
> > Utilities volume of POSIX.1-2017 consist solely of uppercase letters,
> > digits, and the <underscore> ( '_' ) from the characters defined in
> > Portable Character Set and do not begin with a digit. Other
> > characters may
> > be permitted by an implementation; applications shall tolerate the
> > presence
> > of such names. "
> >
> > Bash tolerates those names by passing them through to children in
> > their
> > environment and not attempting to create shell variables from them.
>
> It's not really specified what "tolerate" means.
>
> While I agree with you that it's considered unspecified whether or not
> a shell exports such env vars to programs it executes,... I'd rather
> interpret the "tolerate" here in a way, meaning the shell itself shall
> not crash/error/auto-destruct if it's invoked with an environment that
> also contains env vars with names that are not valid shell var names.

Why? The shell already auto-exports variables it gets in the environment
and passes them to children unless a script unsets or unexports them, so
why not do the same thing with environment strings that aren't shell
identifiers? If a program communicates with its children or other processes
using environment variables that aren't shell identifiers, and happens to
use something like system(3) or popen(3) to create child processes, why
should the shell get involved in filtering those out?


> The broader reason why I, personally, prefer the behaviour of not
> having them further exported is as follows:
>
> Even if the shell permits further characters, it probably cannot permit
> everything what env var names permit. Cause AFAIU the env var name can
> consist of anything except = and NUL.
> So you could have a env var name <newline>.
>
> There seems at least no portable way to work with such env names in a
> shell script, cause even `env` (with not arguments) doesn't allow one
> to get the name of a env var named e.g. + (as env doesn't escape
> newlines in values).

Sure, from a script's perspective it's as if they don't exist.

> So from the shell script PoV there is no control / reasonable-way-to-
> interact at all over such env vars, one cannot even unset them except
> one starts every command via env -i, which is quite annoying.

Why bother, then? You can safely ignore their existence. If you really
want to invoke child processes without those variables, there are ways
to do that.

> The only proper use case seems to me, if any of the programs executed
> from the script, would make use of such env var, and that is then
> already set by the caller of the shell script.
>
> I wouldn't know anything that does that, so I rather prefer to
> "protected" executed programs from any such env vars, which are at best
> ignored but at worst cause somehow troubles.

The "I can't imagine anyone doing it so no one must be doing it" trap is
easy to fall into.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/