On 4/21/14, 12:10 AM, Maxdamantus wrote:
> version: 4.3.11(5)
>
> This seems like a bug, but it seems to have been here for a few years
> (from the git repository, bash-3.0 displays this behaviour while
> bash-2.05b doesn't).
The history expansion code knows nothing about shell syntax, and barely
On 22 April 2014 04:24, Maxdamantus wrote:
> Yeah, I can see what you're saying, but it would probably lead to the
> bash-2 behaviour, which didn't observe double quotes.
>
> Given: echo "$(echo "foo")"
> I can't see how it would be desirable for anything to consider
> '"$(echo "' and '")"' to be
Chris Down writes:
> !! is not single-quoted in the ultimate expansion (bash knows nothing
> about what happens inside the subshell), which is all that matters. It's
> not too late to perform history expansion (which is different than
> parameter expansion).
To be more clear, the history expansion
Maxdamantus writes:
> It's not just inside a double-quoted block. It's inside a single-quoted block.
No, your ultimate expansion is in a double quoted block. What happens
inside the command substitution does not matter.
> The last two commands in my first email demonstrate that the $
> expansion
It's not just inside a double-quoted block. It's inside a single-quoted block.
The last two commands in my first email demonstrate that the $
expansion is aware of that, so it follows the rule of everything
inside single-quote blocks being literal except for the single quote
itself. ! doesn't.
ec
Maxdamantus writes:
> This seems like a bug, but it seems to have been here for a few years
> (from the git repository, bash-3.0 displays this behaviour while
> bash-2.05b doesn't).
>
> With history expansion enabled (set +H):
>
> $ echo '!!' # good
> !!
> $ echo "$(echo '!!')" # not good; !! exp
> With history expansion enabled (set +H):
That should have been -H (+H disables it).
After looking into the code, it turns out it's because history_expand
basically works as a finite state machine to determine whether it
should expand occurances of ! it runs into, so of course can't handle
subcommands (more specifically, quotes inside quotes). This leads to
interesting patterns tho
