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

Groups > gnu.bash.bug > #15809 > unrolled thread

Re: temp setting POSIXLY_CORRECT turns alias expansion off

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: temp setting POSIXLY_CORRECT turns alias expansion off Martijn Dekker <martijn@inlv.org> - 2020-01-16 20:05 +0100

#15809 — Re: temp setting POSIXLY_CORRECT turns alias expansion off

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.

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:

   1. Shell options and variables are fundamentally different things,
      so implementing one as another causes behaviour that violates the
      principle of least astonishment.

   2. It's asking for corner case bugs, as there is plenty of weirdness
      associated with shell assignments, particularly when they precede
      commands.

   3. It makes it impossible to 'export POSIXLY_CORRECT=y' to use all
      external commands in POSIX mode while using bash in native mode
      -- something that would entirely make sense when writing bash
      scripts that should run on multiple different operating systems.

(Also, 4. this kills process substitution. You never responded to my 
patch last month, did you forget about it?)

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).

Other than that, I think -o posix and POSIXLY_CORRECT should be 
decoupled completely and POSIXLY_CORRECT should just be a variable like 
any other.

Scripts should then simply set -o/+o posix in order to enable/disable 
POSIX mode for the shell where desired. I would bet that most already do 
that anyway, because that is how other shells work.

This might be a breaking change, but I think the incompatibility would 
be minor, and worth the improvement in consistent behaviour.

- Martijn

-- 
modernish -- harness the shell
https://github.com/modernish/modernish

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web