Re: temp setting POSIXLY_CORRECT turns alias expansion off

[Chet Ramey]

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/