Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15811

Re: temp setting POSIXLY_CORRECT turns alias expansion off

Show all headers | View raw

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/

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: temp setting POSIXLY_CORRECT turns alias expansion off Chet Ramey <chet.ramey@case.edu> - 2020-01-17 09:49 -0500

csiph-web