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
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).
With history expansion enabled (set +H):
$ echo '!!' # good
!!
$ echo "$(echo '!!')" # not good; !! expands
echo "$(echo
On Sun, 20 Apr 2014 22:29-0400, Chet Ramey wrote:
> On 4/19/14, 3:44 PM, Trond Endrestøl wrote:
> > Hi,
> >
> > I'm running GNU bash 4.3.11 on several branches of FreeBSD, more
> > specifically stable/{8,9,10}, and head (11.0-CURRENT), both 32-bit
> > (i386) and 64-bit (amd64).
> >
> > Wheneve
Alan Young writes:
> greo=$(command -v greo)
>
> if [ -n $greo ]; then
> $greo ...
> fi
>
> command will search the directories defined in $PATH for the command
> greo and return the fully qualified path. If it isn't found it will
> return null. So, if $greo is non-zero, greo exists and you c
11 matches
Mail list logo
