bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sr #108491] Is `set -o histexpand` meant to trump `set -o posix`? [


From: Geoff Nixon
Subject: Re: [sr #108491] Is `set -o histexpand` meant to trump `set -o posix`? [eg, echo "#!/"] (Because it does.)
Date: Sat, 1 Feb 2014 19:35:06 -0500 (EST)

So having done some more playing around with this, I've found that when bash is configured and compiled with '--enable-strict-posix-default', this doesn't occur. I see this is documented in the change log for 4.3alpha, as:

k. When compiled for strict Posix conformance, history expansion is disabled by default.

But why is this a compile-time-only behavior?

There's nothing else in the documentation about any differences between bash compiled with -DSTRICT_POSIX v.s. enabling this mode with `bash --posix`. It just says that POSIX mode will become a default option. And reverse also seems to be true; if you compile with -DSTRICT_POSIX, invoke the shell, then 'set +o posix', history expansion remains disabled? This definitely seems like it could cause some trouble.

URL: http://savannah.gnu.org/support/?108491

Summary: Is `set -o histexpand` meant to trump `set -o posix`? [eg, echo "#!/"] (Because it does.)
                Project: The GNU Bourne-Again SHell
                Submitted by: None
                Submitted on: Sat 01 Feb 2014 01:32:34 PM UTC
                Category: None
                Priority: 5 - Normal
                Severity: 5 - Blocker
                Status: None
                Privacy: Public
                Assigned to: None
                Originator Email: address@hidden
                Open/Closed: Open
                Discussion Lock: Any
                Operating System: *BSD

   _______________________________________________________

Details:

From: address@hidden
To: address@hidden, address@hidden, address@hidden,address@hidden, address@hidden

Subject: Is `set -o histexpand` meant to trump `set -o posix`? [eg, echo "#!/"] (It does.)

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin13.1.0
Compiler: /usr/bin/clang
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='darwin13.1.0' -DCONF_MACHTYPE='x86_64-apple-darwin13.1.0' -DCONF_VENDOR='apple' -DLOCALEDIR='/Users/Shared/usr/local/opt/bash/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DMACOSX -DDEBUG -DMALLOC_DEBUG -I. -I. -I./include -I./lib -g -O2 uname output: Darwin air.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
Machine Type: x86_64-apple-darwin13.1.0

Bash Version: 4.3
Patch Level: 0
Release Status: rc2

Description:

Please see these:

http://stackoverflow.com/questions/21494213/why-cant-i-echo-the-characters-in-a-string-in-bash
http://stackoverflow.com/questions/21496049/what-is-the-intended-effective-ordering-of-set-o-options-in-bash-does-histe

Its still not at all clear to me if I'm correct or not; and I kind of got a serious beatdown for calling it a bug on Stack Overflow. So I'm not sure if this is a 'blocker' per se or even something you'll consider a bug. But it certainly blocks me from wanting to using bash to execute a POSIX-portable
script!

(Note that I now fully realize my statement there to the effect of 'bash never sees any updates so use a different shell' is erroneous. I made this claim because a keep a git checkout on my hard drive which gets pulled daily - but your master branch is configured to track 4.2 rather than devel, so that's what I thought was indeed the case. I was completely aghast to find that 4.3 is in rc2 having just made that statement, and I intend to redact it a soon as
there's some resolution to this "bug", be it a bug or not.)

I apologize if this appears in your inbox two dozen times. I don't know if
sendmail even works at all on my system; and there are three slightly
different emails in the bashbug script, in git, and the top hit in a web
search for your name. I'm trying to make sure this gets seen before the
'release' button gets pushed for 4.3.

Repeat-By:
        set -o histexpand && set -o posix && echo "#!/"
       set -o histexpand && set -o posix && echo "#!/bin/bash"
        echo $?

Fix:
        Disable `set -o histexpand` while parsing and expanding double-quoted
strings, at least for lines which begin with a hash symbol, when `set -o posix` is set.

   _______________________________________________________

Reply to this item at:

 <http://savannah.gnu.org/support/?108491>




reply via email to

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