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

[Kerin Millar]

On Sun, 11 Feb 2024 23:57:31 +0100
Christoph Anton Mitterer <calestyo@scientia.org> wrote:

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

Interesting. Perhaps your version of dash is too old to contain the following 
change?

https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=ee5cbe9fd6bc02f31b4d955606288de36c3d4eab

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

I see.

-- 
Kerin Millar