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 by the reference manual >>

Re: inconsistent treatment of backslash-bang

Lawrence D'Oliveiro wrote: No idea about that. GNU project folks are well-known for deprecating man pages. I didn't. The man page and info manual are equally authoritative. Send reports of mistakes or discrepancies to me. In this case, as I said, the info manual contains the same text. Chet

Re: inconsistent treatment of backslash-bang

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 by the reference manual > . That

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

On Wednesday 23 July 2008 14:46, Lawrence D'Oliveiro wrote: >> In which way is that wrong? > > Maybe not: > > [EMAIL PROTECTED]:~> set +H > [EMAIL PROTECTED]:~> echo "y" > y > [EMAIL PROTECTED]:~> echo "\y" > \y > [EMAIL PROTECTED]:~> echo y > y > [EMAIL PROTECTED]:~> echo \y > y > > That still

Re: inconsistent treatment of backslash-bang

> That still leaves the issue of the discrepancy between the way bash actually > behaves, and the way it's documented to behave. Really. This is from the man page, in the QUOTING section: Enclosing characters in double quotes preserves the literal value of all characters within the quotes,

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 there! >> [EMAIL PROTECTED]:~> echo "hi there\!" >> hi there\! >> [EMAIL PRO

Re: inconsistent treatment of backslash-bang

On Tuesday 22 July 2008 13:38, Lawrence D'Oliveiro wrote: > 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 there! > [EMAIL PROTECTED]:~> echo "hi there\!" > hi there\! > [EMAIL PROTECTED

Re: inconsistent treatment of backslash-bang

Lawrence D'Oliveiro <[EMAIL PROTECTED]> 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 there! > [EMAIL PROTECTED]:~> echo "hi there\!" > hi there\! > [EMAIL PROTECTED]:~> echo h

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

Lawrence D'Oliveiro wrote: 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 esca

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

Lawrence D'Oliveiro <[EMAIL PROTECTED]> wrote: > It's not going to break any executable scripts, since it has already > been pointed out to me that history expansion doesn't happen in > scripts. History expansion doesn't happen in scripts *by default*, but it can be enabled explicitly. paul

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't: > > Sure it does ... I have shown that it doesn't. > Where they

Re: inconsistent treatment of backslash-bang

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't: Sure it does: in your examples, bash tries history expansion in exactly the same cases as tcsh.

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 exactly the same >> sort of output as interactively. > > H

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

Lawrence D'Oliveiro wrote: 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? Are you being deliberately obtuse? The rest of the message explained th

Re: inconsistent treatment of backslash-bang

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 exactly the same > sort of output as interactively. How did you invoke the script?

Re: inconsistent treatment of backslash-bang

On Friday 18 July 2008 07:35, Lawrence D'Oliveiro 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 exactly the > same sort of output as interactively. On my system, I g

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"

Lawrence D'Oliveiro wrote: 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

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

Lawrence D'Oliveiro 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 there, only

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

Re: inconsistent treatment of backslash-bang

> > If you want fully sh-compatible behavior, you have to turn off history > > expansion (set +o history). > >I find it adequate to set histchars to an empty string. Sorry, you turn off history expansion with `set +o histexpand'. You don't need to turn off history entirely. Chet -- ``The

Re: inconsistent treatment of backslash-bang

On 2008-07-16, Chet Ramey wrote: >> Machine Type: x86_64-pc-linux-gnu >> >> Bash Version: 3.2 >> Patch Level: 39 >> Release Status: release >> >> Description: >> In all contexts in which a character "X" has special meaning to bash, >> it should >> be possible to insert that character l

Re: inconsistent treatment of backslash-bang

> Machine Type: x86_64-pc-linux-gnu > > Bash Version: 3.2 > Patch Level: 39 > Release Status: release > > Description: > In all contexts in which a character "X" has special meaning to bash, > it should > be possible to insert that character literally by writing "\X". This > fails i

Re: inconsistent treatment of backslash-bang

On Wednesday 16 July 2008 04:47, Lawrence D'Oliveiro wrote: > Description: > In all contexts in which a character "X" has special meaning to bash, it > should be possible to insert that character literally by writing "\X". > This fails in one case: where "X" is "!", and the context is inside doubl