Re: test for "command not found" before expanding shell parameters
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 can run > it. And if $greo is null the condition will also be true. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: bash 4.3.11 on FreeBSD stable/{8, 9, 10}, and head, bug with backwards incremental search whenever horizontal-scroll-mode is on
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).
> >
> > Whenever horizontal-scroll-mode is set to on in .inputrc, backwards
> > incremental search fails to repaint the command line when doing
> > successive tappings on C-r. bash will misbehave even further when I
> > hit the enter key. More explanation follows.
>
> Coincidentally, I've been looking at this problem for the last couple of
> days, based on another report. I've attached what I have so far, which
> seems to fix the problem according to the testing I've done so far. Let
> me know how it works for you.
This patch looks very promising. I've so far only tested the patch on
a physical computer while logged in by mosh.
Hitting C-r, then typing "cvs" to lookup a command like
"cvs diff -u 2>&1", and hitting the enter key would previously display
"", but with the new patch in effect the whole command is displayed
when hitting the enter key.
I've compared this patch to 4.3.11 as installed on said computer, and
the patch does work for me.
I'd like to test the patch on a few of my FreeBSD VMs at home later
today. I'll keep you posted.
Great work!
--
--
Trond Endrestøl | trond.endres...@ximalas.info
ACM, NAS, NUUG, SAGE, USENIX| FreeBSD 9.2-S & re-Alpine 2.03
Expansion of exclamation mark in single quotes in subcommand
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 'echo '!!'')" echo !! $ echo '$$' # good $$ $ echo "$(echo '$$')" # good $$
Re: Expansion of exclamation mark in single quotes in subcommand
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 though: echo '!!' # doesn't expand echo "$(echo '!!')" # expands echo "$(echo "$(echo '!!')")" # doesn't expand echo "$(echo "$(echo "$(echo '!!')")")" # expands echo "$(echo "$(echo "$(echo "$(echo '!!')")")")" # doesn't expand The reason it appeared to work in 2.05b was because it simply didn't account for double quotes, which meant it had things like: echo \' !! \' # expands echo "'" !! "'" # doesn't expand This seems like an architectural issue, so I probably wouldn't be able to fix it myself (I've never looked at bash's source until now)—logically, I'd expect the history expansion to happen in the same place as the variable use expansion, but there must be a reason that's not the case.
Re: Expansion of exclamation mark in single quotes in subcommand
> With history expansion enabled (set +H): That should have been -H (+H disables it).
Re: Expansion of exclamation mark in single quotes in subcommand
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; !! expands > echo "$(echo 'echo '!!'')" > echo !! > $ echo '$$' # good > $$ > $ echo "$(echo '$$')" # good > $$ I'm not totally sure why you think this is a bug. How can bash know what quoting style was used inside the command substitution? This is normal behaviour when history expansion is performed inside a double quoted block. Perhaps if you explained the reason you think this is a bug better, someone could give a more meaningful reply. :-) pgpXYMPXVLkf3.pgp Description: PGP signature
Re: Expansion of exclamation mark in single quotes in subcommand
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. echo "$(echo "$$")" # here, $$ is double-quoted, so should be expanded to something (it is) echo "$(echo '$$')" # here, $$ is single-quoted, so shouldn't be expand to something (it isn't) echo "$(echo "!!")" # here, !! is double-quoted, so should be expanded to something (it is) echo "$(echo '!!')" # here, !! is single-quoted, so shouldn't be expanded to something (it is—this seems wrong) I think my second email shows even more clearly that it's a bug: each time you nest a subcommand, the behaviour changes: it alternates between expanding an non-expanding On 22 April 2014 02:26, Chris Down wrote: > 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; !! expands >> echo "$(echo 'echo '!!'')" >> echo !! >> $ echo '$$' # good >> $$ >> $ echo "$(echo '$$')" # good >> $$ > > I'm not totally sure why you think this is a bug. How can bash know what > quoting style was used inside the command substitution? This is normal > behaviour when history expansion is performed inside a double quoted > block. > > Perhaps if you explained the reason you think this is a bug better, > someone could give a more meaningful reply. :-)
Re: Expansion of exclamation mark in single quotes in subcommand
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 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. No, that's to do with the order of operations. History expansion and parameter expansion are performed at two totally separate points during parsing. > echo "$(echo "$$")" # here, $$ is double-quoted, so should be expanded > to something (it is) > echo "$(echo '$$')" # here, $$ is single-quoted, so shouldn't be > expand to something (it isn't) This is because the parameter expansion has already been performed, so you're too late to expand $$. > echo "$(echo "!!")" # here, !! is double-quoted, so should be expanded > to something (it is) > echo "$(echo '!!')" # here, !! is single-quoted, so shouldn't be > expanded to something (it is—this seems wrong) !! 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). > I think my second email shows even more clearly that it's a bug: each > time you nest a subcommand, the behaviour changes: it alternates > between expanding an non-expanding The reason !! can be expanded and $$ can not is purely because of the order of expansions, which is clearly documented in the manual. pgpwJscg7UAzW.pgp Description: PGP signature
Re: Expansion of exclamation mark in single quotes in subcommand
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 is performed immediately after the line is read, before word splitting takes place. Perhaps this may be undesirable(?), but I don't think it's unexpected behaviour. pgptocDQGjvHb.pgp Description: PGP signature
Re: Expansion of exclamation mark in single quotes in subcommand
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 quoted and the rest, 'echo ' and 'foo' to > be unquoted. > With the bash-2 behaviour, the only quotes history expansion is aware > of is single quotes, which can't contain another set of single quotes. > > It looks like the current behaviour was added into bash-3 to make > history expansion more consistent with other expansions, but without > realising double quotes can be nested in the somewhat separate bash > language. > Maybe I should show some practical-looking commands that > (unexpectedly) runs into the problem: > > $ sed '3,10!d' > $ m="$(sed '3,10!d' -bash: !d': event not found > > Ironically, this actually works if the user instead writes: m="$(!!)" > In the process, it will print out the invalid command just above as if > that's the one it's executing. > > On 22 April 2014 03:55, Chris Down wrote: >> 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 is performed immediately after >> the line is read, before word splitting takes place. >> >> Perhaps this may be undesirable(?), but I don't think it's unexpected >> behaviour.
Re: Expansion of exclamation mark in single quotes in subcommand
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 understands quoting. It knows about backslashes, double quotes, and single quotes, and knows that single quotes don't have any special meaning inside double quotes. It's performed immediately after the shell reads a line, and it happens over the entire line. With those conditions, you should be able to figure out the behavior of the expansion FSM. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
