Re: inconsistent treatment of backslash-bang

Paul Jarc wrote: > Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote: > >> Chet Ramey wrote: >> >>> This is from the man page, in the QUOTING section: >> >> No idea about that. GNU project folks are well-known for deprecating man >> pages. I go

Re: inconsistent treatment of backslash-bang

Chet Ramey wrote: > This is from the man page, in the QUOTING section: No idea about that. GNU project folks are well-known for deprecating man pages. I go by the reference manual . That's the manual I use for reference. Being the reference ma

Re: inconsistent treatment of backslash-bang

Andreas Schwab wrote: > Lawrence D'Oliveiro writes: > >> And even with the specialness of bang turned off, it still doesn't work >> right: >> >> [EMAIL PROTECTED]:~> set +H >> [EMAIL PROTECTED]:~> echo "hi there!" >> hi ther

Re: inconsistent treatment of backslash-bang

Chet Ramey wrote: > Bash and csh both permit backslash to inhibit history expansion when in > double quotes. If a printable character has special meaning in syntax for representing data strings, then in any situation where it's special, it is expected to be possible to disable that specialness by

Re: inconsistent treatment of backslash-bang

Chet Ramey wrote: > csh allows backslash to act as an escape character > (that is, it is removed) when it precedes ! in a double-quoted string. > Bash doesn't ... But if it doesn't, then why does bang not have its history-expansion behaviour? Either it's acting as an escape or it isn't. Which is

Re: inconsistent treatment of backslash-bang

Paul Jarc wrote: > Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote: >> >> Chet Ramey wrote: >> >>> I already explained that bash follows csh as closely as possible >>> in its history expansion implementation. >> >> Well, it doesn&#x

Re: inconsistent treatment of backslash-bang

Paul Jarc wrote: > Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote: >> pk wrote: >>> This is documented in man bash, and only happens in interactive shells (not >>> scripts). >> >> I just tried putting my six cases into a script, and I get e

Re: inconsistent treatment of backslash-bang

Chet Ramey wrote: > I already explained that bash follows csh as closely as possible > in its history expansion implementation. Well, it doesn't: [EMAIL PROTECTED]:~> /bin/tcsh hypatia /home/ldo> echo hi there!0 0: Event not found. hypatia /home/ldo> echo "hi there!0" 0: Event not found. hypatia

Re: inconsistent treatment of backslash-bang

pk wrote: > This is documented in man bash, and only happens in interactive shells (not > scripts). I just tried putting my six cases into a script, and I get exactly the same sort of output as interactively.

Re: inconsistent treatment of backslash-bang

Chet Ramey wrote: > Here's the deal. Only single quotes and backslashes quote the history > expansion character. Double quotes don't matter ... Then why do they cause a difference in behaviour? > Since ! is not one of the characters for which Posix says the backslash > will act as an escape, t

Re: inconsistent treatment of backslash-bang"

Chet Ramey wrote: >> Chet Ramey wrote: >> >>> Yes, this is where the semantics of history expansion clash with traditional >>> shell behavior. Only single quotes inhibit history expansion. >> >> In that case, situation number 3 is producing the wrong result, since there >> are no single quotes t

Re: inconsistent treatment of backslash-bang

Chet Ramey wrote: > Yes, this is where the semantics of history expansion clash with traditional > shell behavior. Only single quotes inhibit history expansion. In that case, situation number 3 is producing the wrong result, since there are no single quotes there, only a backslash. Whichever way

inconsistent treatment of backslash-bang

tax.h-orig 2006-06-23 05:45:22.0 +1200 +++ syntax.h2008-05-31 16:23:36.0 +1200 @@ -23,7 +23,7 @@ /* Defines for use by mksyntax.c */ -#define slashify_in_quotes "\\`$\"\n" +#define slashify_in_quotes "\\`$\"!\n" #define slashify_in_here_document "\\`$" #define shell_meta_chars "()<>;&|" Originally reported as Gentoo bug 224309 <http://bugs.gentoo.org/show_bug.cgi?id=224309>. Lawrence D'Oliveiro