Re: GROUPS

[Franklin, Jason]

On Fri, 2021-08-13 at 10:10 -0400, Chet Ramey wrote:
> As long as you stick to things POSIX standardizes. Relevant here, the
> standard even includes a list of variables you should avoid using because
> various shells and applications use them.

GROUPS is not on this list that I can tell.  It would be impossible for
the standard to list every variable that may be treated as special by
some shell or another.

> > The standard determines what is "predictable" behavior, not the Bash
> > documentation.
> 
> Come on. The bash documentation describes how bash behaves.

This evades the principle I'm trying to convey.  Developers should be
able to code tightly against the standard and have their code move
easily between interpreters and compilers (which might not yet be
written).

If you were writing a C program, and you wanted to use a variable "foo",
and you moved the project to another compiler and you were shut down
because assignments to "foo" at runtime were silently ignored, you'd be
surprised.

> > POSIX is supposed to enable portability.  Compliant code should run the
> > same on any compliant interpreter or compiler.  How can I possibly test
> > on all systems that try to be compliant?  I may not be aware of all of
> > them or one may not even exist yet.
> 
> That's an argument against extensions outside what POSIX standardizes. If
> you want a shell like that, they exist, but bash is not going to be that
> shell.

Now, this is at least addressing the core of the issue.  The only
problem here is that Bash won't run otherwise perfectly POSIX-compliant
scripts that happen to use no extensions and happen to assign to the
variables GROUPS, UID, or EUID, etc.

Of course, it sounds like Bash calls these variables extensions.

> > >      Even then (using either solution), what does a script do if it wants 
> > > to
> > >      be invoked as:
> > > 
> > >              GROUPS='abelian ...' script [options]
> > > 
> > >      ?
> > > 
> > > That case works, see above. Maybe it shouldn't, but it does.
> > 
> > This doesn't work unless it was recently fixed.  A variation does...
> 
> The assignment preceding the command is performed in the current shell
> context and obeys the current shell's assignment rules.
> 
> If bash sees GROUPS in the environment, it doesn't create a special
> variable with that name, as you discovered. The same with UID and EUID.

Right.  So, If I want to write the following script...

  #! /bin/sh
  FOO=x /usr/bin/other_program

I need to keep two things in mind:

1. FOO might be special under whatever shell /bin/sh is linked to.
2. Even if working with bash, FOO might be made special in a future
   version of bash while it's not special now.

All of my scripts must thus look like this now...

  #! /bin/sh
  unset FOO
  FOO=x /usr/bin/other_program

Of course, this still may fail if the shell that actually runs this
script happens to make FOO readonly in its current or future version.

I think this topic has been exhausted.  I don't have much else to say
here.  I am aware of the behavior now, so I can't run into this myself.

However, the choice to keep this behavior seems like an odd one.

-- 
Jason