inconsistent treatment of backslash-bang

[Lawrence D'Oliveiro]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -O2 -pipe
uname output: Linux theon 2.6.23-gentoo #6 SMP Sat Oct 27 20:31:22 NZDT 2007 
x86_64 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux
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 in
one case: where "X" is "!", and the context is inside double quotes.

Repeat-By:
Steps to Reproduce:
1. echo "hi there!0"
2. echo "hi there\!0"
3. echo hi there\!0
4. echo "hi there$0"
5. echo "hi there\$0"
6. echo hi there\$0

Actual Results:  
1. bash: !0: event not found
2. hi there\!0
3. hi there!0
4. hi there/bin/bash
5. hi there$0
6. hi there$0

Expected Results:  
1. bash: !0: event not found
2. hi there!0
3. hi there!0
4. hi there/bin/bash
5. hi there$0
6. hi there$0

Note the difference in number 2.

Fix:
The following patch (adding "!" to the "slashify_in_quotes" set) seems to fix
the problem:

--- syntax.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 
.

Lawrence D'Oliveiro

Re: inconsistent treatment of backslash-bang

[pk]

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 double
> quotes.

That is documented in man bash, and only appens in interactive shells (not
scripts). You can disable history expansion (set +H, set +o histexpand) to
avoid the problem, or use \! outside double quotes.

Re: inconsistent treatment of backslash-bang

[Chet Ramey]

> 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 in
>   one case: where "X" is "!", and the context is inside double quotes.

Yes, this is where the semantics of history expansion clash with traditional
shell behavior.  Only single quotes inhibit history expansion.

> The following patch (adding "!" to the "slashify_in_quotes" set) seems to fix
> the problem:

Unfortunately, this violates Posix and traditional sh behavior.

If you want fully sh-compatible behavior, you have to turn off history
expansion (set +o history).

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/

Re: inconsistent treatment of backslash-bang

[Chris F.A. Johnson]

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 literally by writing "\X". This 
>> fails in
>>  one case: where "X" is "!", and the context is inside double quotes.
>
> Yes, this is where the semantics of history expansion clash with traditional
> shell behavior.  Only single quotes inhibit history expansion.
>
>> The following patch (adding "!" to the "slashify_in_quotes" set) seems to fix
>> the problem:
>
> Unfortunately, this violates Posix and traditional sh behavior.
>
> 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.


-- 
   Chris F.A. Johnson, webmaster 
   ===
   Author:
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

Re: LC_COLLATE not used for filename expansion

[Chet Ramey]

Chris F.A. Johnson wrote:

With LC_COLLATE set to a locale with case-insensitive collation,
filename expansion does not use the locale. It does with LC_ALL.

In an empty directory:

$ touch a B c D e F
$ echo *
B D F a c e
$ LC_COLLATE=en_us
$ echo *
B D F a c e
$ LC_ALL=en_us
$ echo *
a B c D e F


It is, in fact, used to sort the results of filename expansion (as long
as strcoll is present and understands locales).  It seems like `en_us' is
not a valid locale value to assign to LC_COLLATE, but works with LANG.

Here's what I get with a slightly-instrumented bash:

$ cat x4
unset LC_COLLATE LC_ALL
echo LANG = $LANG
LC_COLLATE=C
cd scratch
touch a B c D e
echo *
LC_COLLATE=en_us
echo *
unset LC_COLLATE
LANG=en_us
echo *
LANG=C
LC_COLLATE=en_US.UTF-8
echo *
$ ./bash ./x4
LANG = en_US.UTF-8
TRACE: pid 25971: shell_glob_filename: LC_COLLATE = C
B D a c e
./x4: line 7: warning: setlocale: LC_COLLATE: cannot change locale (en_us): 
No such file or directory

TRACE: pid 25971: shell_glob_filename: LC_COLLATE = C
B D a c e
TRACE: pid 25971: shell_glob_filename: LC_COLLATE = en_US.UTF-8
a B c D e
TRACE: pid 25971: shell_glob_filename: LC_COLLATE = en_US.UTF-8
a B c D e

(FWIW, this is on ubuntu linux.)

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/

Re: shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied

[LynnOS]

*"You might be able to avoid the need for the getcwd call at startup by
exporting PWD*"

Sorry,would you give us more details about how to avoid the "error" message

Thanks very much

LynnOS

2008/7/13 Chet Ramey <[EMAIL PROTECTED]>:

> [EMAIL PROTECTED] wrote:
>
>  LynnOS wrote:
>>
>>> [EMAIL PROTECTED] Linux-vserver:~# pwd
>>> /root
>>> [EMAIL PROTECTED] Linux-vserver:~# ls -ld /root
>>> drwx--3 root root 4096 Jul  3 14:52 /root
>>> [EMAIL PROTECTED] Linux-vserver:~# su lynn
>>> *shell-init: error retrieving current directory: getcwd: cannot access
>>> parent directories: Permission denied*
>>> [EMAIL PROTECTED] Linux-vserver:/root$
>>>
>>
> This is not a bash problem.  You're in a directory which can be read and
> searched only by root, and you're su'ing to another user.  That user
> does not have permission to search the current directory, even to find
> `..', so getcwd is going to fail.
>
> *You might be able to avoid the need for the getcwd call at startup by
> exporting PWD, *so the child shell can read it, but there aren't any
> guarantees.
>
> Chet
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>
> Chet Ramey, ITS, CWRU[EMAIL PROTECTED]
> http://cnswww.cns.cwru.edu/~chet/ 
>
>
>


-- 
OpenEmbedded,Linux vserver,Python