[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: temp setting POSIXLY_CORRECT turns alias expansion off
From: |
Chet Ramey |
Subject: |
Re: temp setting POSIXLY_CORRECT turns alias expansion off |
Date: |
Fri, 17 Jan 2020 09:49:37 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
On 1/16/20 2:05 PM, Martijn Dekker wrote:
Op 16-01-20 om 17:02 schreef Chet Ramey:
On 1/15/20 10:24 PM, Martijn Dekker wrote:
When alias expansion is enabled for a script in bash native mode,
prefixing POSIXLY_CORRECT=y to any command will turn alias expansion
globally off. This is a bug because the assignment should only have
effect on that command.
You're probably right, but it's an interesting question.
The idea is that
POSIXLY_CORRECT=y true
is essentially equivalent (assuming POSIXLY_CORRECT is not already set) to
POSIXLY_CORRECT=y ; true; unset POSIXLY_CORRECT
and turning off posix mode resets a default environment.
I think it *should* be essentially equivalent to
(POSIXLY_CORRECT=y; true)
minus the actual forked subshell of course. But the state after the command
should be identical to the state before.
It gets into a larger question about variable setting and unsetting side
effects. POSIXLY_CORRECT is not the only variable for which side effects
occur.
Another odd behaviour: 'unset POSIXLY_CORRECT' resets a default environment
even if the variable was already unset. This is in all versions of bash.
If you'll forgive my frankness, I think the whole notion of coupling a
shell variable (POSIXLY_CORRECT) to a shell option (-o posix) is broken,
because:
Hindsight provides perspective. While `set -o posix' might be the more
shell-like way to do it, the GNU coding standards specified
POSIXLY_CORRECT, and still do, though in a weaker way. When I unified the
POSIXLY_CORRECT handling into posix mode in 1993, I had to support it
alongside `set -o posix'. The shell is a special beast because it allows
you to set variables, not just inherit them, so it had supported setting
POSIXLY_CORRECT as equivalent to inheriting it in the initial environment,
and I carried that behavior forward.
This was probably around the time I first ran bash through the POISIX
conformance test suite, so there were more places to check for posix
conformance. It quickly became unwieldy.
(Also, 4. this kills process substitution. You never responded to my patch
last month, did you forget about it?)
No, it's still there in the list of things to look at. It's not a high
priority right now.
So I think bash should only check at init time if POSIXLY_CORRECT exists in
the environment and set -o posix if so (the same way it checks if it was
invoked as sh).
The existing code didn't do that, since there were
`getenv("POSIXLY_CORRECT")' calls scattered around the source, and I didn't
want to break backwards compatibility.
(On most systems -- the NeXT being a notable exception -- bash redefined
getenv to look in the environment it passed to its children, so it picked
up exports to POSIXLY_CORRECT.)
--
``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/