Mon 03 Feb 2014 07:46:49 AM UTC, comment #1:
Got it. Couple of things:
- To be super clear, I wasn't the one to ask that first question; the obvious answer
to that is 'its improperly quoted'.
- I'm not taking any issue with the xpg_echo business. POSIX definitely munged
echo up, and that isn't bash's fault. Moreover, in other shells, printf
builtins are very frequently botched and insecure too, so myself I usually just:
and then use print "..." . Slow, but at least its predictable.
- I asked the second question (and sent in this bug) because history expansion
in POSIX mode immediately smacked of a bug to me, even prior to revisiting
the docs/specs for this issue. And it seems from what you've told me, I'm not
the first to raise this issue.
Because we're not talking about an error, but a choice in implementation, its only a 'bug' if you say it is. You say its not, so its not, and thats fully
within the prerogative of any developer I think. But if I might note:
> It's a compromise between one of the oldest bash features -- history expansion
predates posix mode by a lot of years -- and the desire to provide users a way
to get a strictly-conforming Posix environment if they really want one.
Thats slightly inaccurate. It predates POSIX by a number of years, not
just posix mode ! Neither is it really one of the oldest bash features. It's
one of the oldest csh features. It predates bash by some ten years I think,
probably straight out of Bill Joy's dorm room circa '78.
The error message is a dead giveaway here that that not really 'bash':
From (en.wikipedia.org/wiki/C_shell#Criticism):
'The implementation is also criticized for its notoriously poor error
messages, e.g., "0 event not found", which yields no useful information
about the problem.'
And so I think its fair to say we're basically now revisiting the csh v. ksh
debate that in large part was the very reason IEEE 1003.2 was necessary in the
first place. POSIX went with ksh, and on this issue in particular
it is in no way ambiguous.
The "Shell Command Language" spec says that ! is a reserved word, and spells out
precisely when and where it is to be so.
Moreover, it explicitly and repeatedly calls out bang history expansion:
Page 2997, 'nl':
"The logical page delimiter is "!+". Note that the ’!’ has to
be escaped when using csh as a command interpreter because of its history
substitution syntax. For ksh and sh the escape is not necessary, but does
not do any harm."
Page 3316, 'uucp':
"Note that the ’!’ character in addresses has to be escaped
when using csh as a command interpreter because of its history substitution
syntax. For ksh and sh the escape is not necessary, but may be used."
So given that, I would venture to say this:
if RC2 were released today as GM, it might not be shipping with a bug in
bash, but it would have several serious inaccuracies in the documentation.
Particularly, the phraseology of, for example:
--posix
Change the behavior of Bash where the default operation differs from
the POSIX standard to match the standard. This is intended to make Bash
behave as a strict superset of that standard.'
Should have 'behavior' become 'some behaviors', and have 'intended' and
'strict' removed, since this is not your intention (you've just told me
as much, no?) and it's therefore an improper superset, and a close subset, but not a strict superset.
If that seems unfair, it's not meant to be. I understand couching compliance
terminology in verbiage like that in the context of 'to our knowledge'. But I'm
not really sure I get the concept of a 'compromise' in this case. If there is
an intentional deviation, as I understand it, that means in the most literal
sense, 'non-compliant'. I think its kind of black and white...
> Bash-4.3 has been in testing for almost a year (4.3-alpha came out in March,
2013), and public test versions have been available for six months.
That was my point about the git repo! I definitely would have brought this up
earlier, but since I wasn't subscribed to the mailing list, I never knew that
until now, despite pulling that repo daily.
> that's going to have to wait for a future version
Well... that's a bummer. Version, not patch, correct? Given that bash seems to
get releases approximately every two years, does this means to look for
this maybe sometime in 2016?
> I would rather just disable it entirely by default.
I would rather you did too!
I suppose until then, in cases where (for example) one drops to an interactive
shell from another from another language and can't know which shell will be
invoked for this, a zsh-style "compatibility mode command" like:
[ x"$BASH_VERSION != x"" ] && set +o histexpand
...might work?
Only the highest regard and best of intentions,
Geoff Nixon
-email is unavailable-
On 2/1/14, 7:35 PM, Geoff Nixon wrote:
> 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?
It's a compromise between one of the oldest bash features -- history
expansion predates posix mode by a lot of years -- and the desire to
provide users a way to get a strictly-conforming Posix environment if they
really want one.
I got several requests to disable it entirely by default in bash-4.3, but
that's going to have to wait for a future version.
> 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.
It doesn't say that exactly. What the configure help string says is that
it will force bash to be conformant by default. Even when you enable
Posix mode, the behavior controlled by xpg_echo and histexpand has to be
tweaked to get a really strictly conforming environment. Since bash enters
Posix mode when it's called as `sh', I judged it would break too many
scripts to do away with `echo -n' and too many interactive user
expectations to disable history expansion. So, posix mode and history
expansion (and echo behavior) are decoupled.
|