Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Martijn Dekker Newsgroups: gnu.bash.bug Subject: Re: temp setting POSIXLY_CORRECT turns alias expansion off Date: Thu, 16 Jan 2020 20:05:45 +0100 Lines: 69 Approved: bug-bash@gnu.org Message-ID: References: NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1579201560 27732 209.51.188.17 (16 Jan 2020 19:06:00 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 In-Reply-To: Content-Language: en-GB X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 37.59.109.123 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: Xref: csiph.com gnu.bash.bug:15809 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