bug-bash
[Top][All Lists]
Advanced

[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    address@hidden    http://tiswww.cwru.edu/~chet/



reply via email to

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