Re: GROUPS

[Chet Ramey]

On 8/11/21 8:00 PM, Franklin, Jason wrote:
> Chet:
>
> My apologies in advance for not responding in thread.  The bug-bash
> archive interface doesn't expose the "Message-ID" header anywhere I can
> find, and I am not a subscriber.  I suppose I should become one.  :)
>
> > I believe I'd rather have variables behave as they're documented. It's more
> > predictable.
>
> Is it?

Sure. Bash behaves as documented.

> The whole point of a standard like POSIX is that I should be able to
> write my code in accordance with the standard and have it run on
> compliant systems that I may not even be aware of or that might not have
> been developed yet.

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.

> The standard determines what is "predictable" behavior, not the Bash
> documentation.

Come on. The bash documentation describes how bash behaves.

> > That's one of the problems here: the author never intended this script to
> > run in any shell other that Debian's dash. If they had, maybe they would
> > have tested it on other shells, even other shells that Debian includes.
>
> The author intended for portability and POSIX compliance.  Otherwise,
> the script header would not have read "#! /bin/sh".  It runs as expected
> on dash and ksh.

Obviously not, since they never tested it on bash. It's more likely they
expected it to run on Debian's /bin/sh -- hence the hashbang -- which is
dash.

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

> Requiring someone to test on all possible current and future shells that
> claim POSIX-compliance defeats the purpose of a reference.
>
> As an aside:  I believe in thorough testing in as many environments as
> feasible!
>
> >      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.


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/