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

[Christoph Anton Mitterer]

On Sun, 2024-02-11 at 11:04 +0000, Kerin Millar wrote:
> Interestingly, your command may also fail to behave as you expected
> in dash, albeit under specific circumstances.
> 
> $ dash -c 'tr "\0" "\n" < /proc/self/environ' | wc -c
> 0

That doesn't happen with my dash, neither when I execute your command
from dash nor from bash (both interactive).

I always see some 3000-something number.


> I don't know whether bash is in the wrong per se, but would suggest
> that you open /proc/$$/environ instead.

I anyway need the behaviour of 
   cat /proc/self/environ
and that should be save.
So neither $$ nor a redirection, but the filename as argument.

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.

Plan is to do so via something like:
env -i 'VAR=valid-shell-variable-name' '+=invalid-shell-variable-name' 
/proc/self/exe -c "set -e; cd /; cd /;   cat /proc/self/environ  |  tr '\\000' 
'\\n'"

And then check (grep or so) whether
   VAR=valid-shell-variable-name
is there (which is just a mere safeguard and whether
   +=invalid-shell-variable-name
is not there (which is the actual check).

+ there is the environment var which is not a valid shell variable name
and thus not seen via e.g. export -p.


/proc/self/exe should be a symlink to the current shell's binary.
I though it would be safer than using $0 which may have been re-set,
but now with the knowledge that e.g. bash returns some unexepcted
values, I'm not so sure anymore.

The double cd / is merely to "clear" PWD and OLDPWD, that they don't
accidentally contain any of the strings my check will be looking for.

I'm a bit unhappy with the cat … | tr as that swallows my cat exit
status (and set -e won't help here).

It doesn't really help to do the tr in an extra step, and capture cat's
output in a variable (not possible, because of the 0x0 in it).


The whole thing what I initially wrote in the patch, was just an
accidental finding, when I tried to do:
  tr '\\000' '\\n'" </proc/self/environ
instead of cat | tr.
But even if that would work the same across all shells, it's not what I
want, cause for my check I need the env of cat respectively tr, as I
want to see whether the shell exported the "invalid" names to them.

So especially I do not want the /proc/self/environ of the executing
shell.

Cheers,
Chris.