[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 13 Aug 2021 10:10:42 -0400
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
On 8/11/21 8:00 PM, Franklin, Jason wrote:
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
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
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
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
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
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 firstname.lastname@example.org http://tiswww.cwru.edu/~chet/
Re: GROUPS, Chet Ramey, 2021/08/10
Re: GROUPS, Franklin, Jason, 2021/08/10
Re: GROUPS, Franklin, Jason, 2021/08/11
- Re: GROUPS, Greg Wooledge, 2021/08/11
- Re: GROUPS,
Chet Ramey <=
- Re: GROUPS, Franklin, Jason, 2021/08/13
- Re: GROUPS, Dale R. Worley, 2021/08/16
- Re: GROUPS, Robert Elz, 2021/08/17
- Re: GROUPS, Dale R. Worley, 2021/08/20