[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compgen gets confused when trying to complete ambiguous special char

From: Chet Ramey
Subject: Re: compgen gets confused when trying to complete ambiguous special char
Date: Mon, 17 Mar 2008 13:44:41 -0400
User-agent: Thunderbird (Macintosh/20080213)

Mika Fischer wrote:
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib   -g -O2 -Wall
uname output: Linux arthur 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 
2008 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu

Bash Version: 3.2
Patch Level: 33
Release Status: release

It is best described by the example below:
This is related to:

address@hidden:~$ mkdir test
address@hidden:~$ cd test
address@hidden:~/test$ mkdir -p "STORE'N'GO/test"
address@hidden:~/test$ mkdir -p "STORE\'N\'GO/test"
address@hidden:~/test$ compgen -f "STORE\'N"
address@hidden:~/test$ ls STORE\<TAB> # This will delete the backslash.
                                   # Then press CTRL-C
address@hidden:~/test(1)$ compgen -f "STORE\'N"
Strangely this will still work:
address@hidden:~/test(1)$ compgen -f "STORE\\\\\\'N"

And this also works before the messup. Can somebody explain where the all
the backslashes go?

(This reply primarily addresses the problems identified in the referenced
ubuntu bug reports.  Look at the end for the SIGINT issue.)

For historical reasons, complete/compgen dequote the filename they're
passed, removing backslash escapes and interpreting embedded quoted
substrings.  (One of the things bash should do when it does that is to
be better about obeying the shell rules about backslash-escaped characters
and double quotes, but that doesn't matter for this example -- though that
function has several problems.)

When it's called as the result of readline dispatching on a particular
character, this is appropriate -- the shell hasn't done any expansion
or quote removal, so the filenames still have embedded quoting.  When
called from the command line, as in these examples, it's not appropriate,
since the shell has already expanded the argument and stripped the

One possible change is to inhibit filename dequoting when compgen isn't
run via a readline keybinding, but I'm not sure how much of an effect
it will have on the problem, which occurs when completing.  It will make
the behavior when run on the command line closer to what the completion
will do.  This is an easy change; contact me if you're interested in
evaluating it.

A second change is to fix the filename dequoting function to be smarter
about single and double quotes -- that is, closer to the bash quoting
rules.  I can't see this being a bad thing, but it may have compatibility

(The problem with SIGINT is completely different.  Some library state
needs to be reset on SIGINT.  That will be fixed in the next version.)

``The lyf so short, the craft so long to lerne.'' - Chaucer
                       Live Strong.  No day but today.
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]