Re: GNU Bash v.4.4.23-5 built-in function 'set' produces variable outputs

[Bob Proulx]

Robert Elz wrote:
> ps: I did  not suggest that $_ should go away, I know that's not going to
> happen ... just that it would be nice for those who really don't want it to
> be able to turn it off.

I'm having a hard time understanding why one would want to turn off
this feature.  It isn't something that everyone uses but it is a
feature that has a lot of use.  If one goes down that path then the
end result taken to the logical extreme would be that every feature
would have a control to turn them on and off.  That just seems
extreme.  And for the case of $_ if you didn't know it existed then
one probably goes about their life continuing to not be bothered by it
too.  The original report wasn't really about $_ anyway.

Ricky Tigg wrote:
> Built-in function 'set' produces variable outputs.
> $ export SSLKEYLOGFILE=/home/user/test
> $ set | grep SSL
> SSLKEYLOGFILE=/home/user/test
> _=SSLKEYLOGFILE
> $ set | grep SSL
> SSLKEYLOGFILE=/home/user/test

The original report was about the output being different in different
invocations.  But I think that is an invalid reason.  Because if so
then 'echo $RANDOM' is also a bug because it produces different output
in different invocations too.  And because set | grep is not a correct
way to look at the environment as such either.  The 'set' command is
designed to set or unset shell options or the positional parameters.
Without any arguments "set shall write the names and values of all
shell variables in the collation sequence of the current locale".
Since $_ is a shell variable it writes it out along with possibly
other data too.  I don't think anyone grep'ing for a string should
complain that the shell also prints out the contents of $_.

As an additional point 'set' writes out the internal data which
includes a lot of *stuff*.  It would be better in this case to use
'env' to write out only the exported variables.  And clearly in the
original report the string being looked for was part of the exported
data.  There is no problem then.

  $ export SSLKEYLOGFILE=/home/user/test
  $ env | grep SSL
  SSLKEYLOGFILE=/home/user/test
  $ env | grep SSL
  SSLKEYLOGFILE=/home/user/test

However even 'env' isn't the appropriate tool either.  There may be
other variables that happen to hit the grep pattern.  And there is the
problem of the variable value including newlines.  The -z,--null helps
here but life isn't simple.

Not that I would do it this way but 'printenv' seems to be the right
matching utility here.

  $ export SSLKEYLOGFILE=/home/user/test
  $ printenv SSLKEYLOGFILE
  /home/user/test

Using grep is fine.  But then the human must interpret the results
accordingly.  I think here understanding that 'set' is doing what is
expected and reasonable is enough.  However I would use 'env' to avoid
the internal data state.  And programatically neither are sufficient
for a fully robust program and other methods should be used.

Bob