[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GROUPS
From: |
Chet Ramey |
Subject: |
Re: GROUPS |
Date: |
Wed, 11 Aug 2021 15:31:08 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 |
On 8/11/21 2:06 PM, Robert Elz wrote:
Date: Wed, 11 Aug 2021 10:16:42 -0400
From: Chet Ramey <chet.ramey@case.edu>
Message-ID: <26e01365-d7f0-448d-dc4d-83f244bd0fde@case.edu>
| As long as POSIX doesn't define a variable to have some special meaning, it
| doesn't have anything to say about how a shell chooses to use it. It's not
| a POSIX issue, period.
Perhaps - but that's true of all variables. How would you ever safely write
a script using variables, if any of them might be usurped by the shell for
some special purpose? Much better for the shell (as much as is possible)
to get out of the way for variables the user initialises, and retain
special meaning for only variables that are used without being set.
I believe I'd rather have variables behave as they're documented. It's more
predictable. Bash allows variables in the environment to override special
variables -- for example, UID and EUID -- and I've gotten bug reports about
that behavior for forever. Here's a relatively recent one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900564
| In this case, as is the case with just about all of the bash special
| variables, you can unset it and it will lose its special meaning.
Sure, but to do that the script writer must either unset every variable
the script is going to use before using it (in which case the possibility
of passing in values via the environment is lost) or somehow (via magic)
know which variable names are magic in every possible shell that might
ever exist and be used to run the script.
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 other problem is the OP assuming that posix mode would change it, when
posix mode means something else.
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.
That works with most shells (the script just accesses ${GROUPS}
or perhaps first includes ": ${GROUPS=a b c}" to set the default value
in case one is not provided. I write scripts like that quite often
(not using GROUPS as the variable, but some of the ones I do use
could easily be made magic in some shell or other - a few have names
that make that entirely plausible (like MINS)).
My point was that where the bash doc says:
Assignments to MAGIC have no effect. If MAGIC is unset,
it loses its special properties, even if it is subsequently
reset.
which (with s/MAGIC/whatever/) appears in the descriptions of
several variables, including GROUPS, it could just as easily
say (assuming the implementation were to make this happen)
If MAGIC is set or unset it loses its special properties
It could have, but I'm not seeing a good enough reason to change it
25-30 years in.
The original implementation was read-only, but that caused bug reports
because trying to unset a readonly variable is a fatal error in posix
mode.
--
``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/
- GROUPS, Franklin, Jason, 2021/08/09
- Re: GROUPS, Greg Wooledge, 2021/08/09
- Re: GROUPS, Franklin, Jason, 2021/08/09
- Re: GROUPS, Greg Wooledge, 2021/08/09
- Re: GROUPS, Chet Ramey, 2021/08/10
- Re: GROUPS, Robert Elz, 2021/08/10
- Re: GROUPS, Štěpán Němec, 2021/08/11
- Re: GROUPS, Andreas Schwab, 2021/08/11
- Re: GROUPS, Chet Ramey, 2021/08/11
- Re: GROUPS, Robert Elz, 2021/08/11
- Re: GROUPS,
Chet Ramey <=
- Re: GROUPS, Robert Elz, 2021/08/12
Re: GROUPS, Chet Ramey, 2021/08/10