bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GROUPS


From: Robert Elz
Subject: Re: GROUPS
Date: Thu, 12 Aug 2021 01:06:46 +0700

    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.

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

Even then (using either solution), what does a script do if it wants to
be invoked as:

        GROUPS='abelian ...' script [options]

?   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

followed by either "which cannot be regained for the lifetime of
the shell" or "which can be returned by ..." if some mechanism
is provided to allow that to happen.

Further this can safely be changed, as because of "Assignments
to MAGIC have no effect" no bash script can be depending on being
able to do "MAGIC=abracadabra" with any useful purpose, thus we
can assume that none do so (or not without "unset MAGIC" first).
Since scripts written for other shells do not know they need to
do "unset MAGIC" to make "MAGIC=abracadabra" work (it simply does)
they can't be expected to do that, and requiring scripts to be
modified to work with bash doesn't seem like a productive design.

So, if the change above were made, it would break nothing, but
make things work much better.

kre




reply via email to

[Prev in Thread] Current Thread [Next in Thread]