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

[Christoph Anton Mitterer]

On Sun, 2024-02-11 at 23:57 +0100, Christoph Anton Mitterer wrote:
> What I basically do is, making a check, whether the current /bin/sh
> would export any variables in its own environment, that are not valid
> shell names, into executed utilities.

btw: In case anyone stumbles ever on this and is interested in it.


It seems to work even much easier... namely by simply using env twice:

env -i 'VAR=valid-shell-variable-name' '+=invalid-shell-variable-name' 
/proc/self/exe -c "set -e; cd /; cd /; env"


With e.g. bash:

$ env -i 'VAR=valid-shell-variable-name' '+=invalid-shell-variable-name' 
/bin/bash -c "set -e; cd /; cd /; env"
+=invalid-shell-variable-name
PWD=/
SHLVL=0
VAR=valid-shell-variable-name
OLDPWD=/
_=/usr/bin/env

(btw: would be nice if bash had a shopt to disable that exporting of
env vars with invalid shell var names... or is there one and I'm just
too blind to find it?)


With e.g. dash:

$ env -i 'VAR=valid-shell-variable-name' $'\n=invalid-shell-variable-name' 
/bin/dash -c "set -e; cd /; cd /; env"
OLDPWD=/
VAR=valid-shell-variable-name
PWD=/


And AFAICS, as per C std and POSIX, there is no way for an environment
to contain NUL bytes (other than as the terminators of the strings).
So no need to take care of NUL in values.

The above one can easily capture via command substitution.
My understanding was that POSIX effectively requires any conforming
shell to be able to hold any bytes (not just characters in the current
locale) in shell variables, except for NUL.
So it shouldn't even be necessary to use LC_ALL=C .

And then simply grep for the patterns.


Cheers,
Chris.