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

[Christoph Anton Mitterer]

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.


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).

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.


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.


Anyway... no need to change bash behaviour here :-) I merely thought
that would be a nice candidate for a shopt option.


Cheers,
Chris.