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: geoff.ni...@aol.com
Open/Closed: Open
Discussion Lock: Any
Operating System: *BSD
_______________________________________________________
Details:
From: geoff.ni...@aol.com
To: c...@po.cwru.edu, chet.ra...@case.edu,
c...@cwru.edu,bash-test...@case.edu, bash-test...@cwru.edu
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>
