Temporarily change completion options
Hi, I'm currently working on the bash-completion package for Debian/Ubuntu. I'd like to know if it is possible to change the options of the programable completion within the completion function. An example would be to allow environment variables in place of filenames. But if I set -o filenames, the $ will be escaped and if I don't set it then other things like & won't be escaped. Another example would be java completion. There the first argument should be a class (foo.bar.class). But the further arguments should be treated as filenames. Since bash does not see . as a path separator I have to use -o nospace to make the first argument work but this is inconvenient for the filename arguments. It would be very convenient if the completion function could alter the options based on its understanding of the current command line. Setting the options globally for a command means that the same options apply to all arguments, which is often very inconvenient. If there is a way to do this, or a workaround for problems of this kind, I'd be glad for any pointers! Regards, Mika
Re: Fwd: Problem with bash completion
Eric Blake wrote: This was originally reported on the cygwin lists; it is still present in stock bash 3.2.33. This has already been fixed for the next version. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: compgen and filenames
Jonas Diemer wrote: I have already tried the "-o filenames" option to compgen, with no success. Is what I want at all possible with the current bash (I used GNU bash, version 3.2.25(1)-release (i486-pc-linux-gnu) from KUbuntu 7.10)? If not, can you fix it (e.g. by improving the "-o filenames" option)? The basic idea is that only the `top-level' completion function be specified with the `-o filenames' option, and that all lower-level completion generators return unquoted filenames. The `-o filenames' option tells readline to treat the completions as filenames, so it only does any good with the completer that generates the final list of completions to hand back to readline. I was able to produce the behavior you want by using a completion function specified with -o filenames and the code you included as the function body. Not for mercurial, though -- there's no completion for it on my ubuntu system, so I'm not sure exactly how the completion functions for it are structured. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: compgen gets confused when trying to complete ambiguous special char
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 Description: It is best described by the example below: This is related to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/123665 https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/197183 Repeat-By: [EMAIL PROTECTED]:~$ mkdir test [EMAIL PROTECTED]:~$ cd test [EMAIL PROTECTED]:~/test$ mkdir -p "STORE'N'GO/test" [EMAIL PROTECTED]:~/test$ mkdir -p "STORE\'N\'GO/test" [EMAIL PROTECTED]:~/test$ compgen -f "STORE\'N" STORE'N'GO [EMAIL PROTECTED]:~/test$ ls STORE\ # This will delete the backslash. # Then press CTRL-C [EMAIL PROTECTED]:~/test(1)$ compgen -f "STORE\'N" [EMAIL PROTECTED]:~/test(1)$ Strangely this will still work: [EMAIL PROTECTED]:~/test(1)$ compgen -f "STORE\\'N" STORE'N'GO 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 quotes. 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 implications. (The problem with SIGINT is completely different. Some library state needs to be reset on SIGINT. That will be fixed in the next version.) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: compgen gets confused when trying to complete ambiguous special char
* Chet Ramey <[EMAIL PROTECTED]> [2008-03-17 18:47]:
> For historical reasons, complete/compgen dequote the filename they're
> passed, removing backslash escapes and interpreting embedded quoted
> substrings.
Yes. I've run into this problem now several times while trying to fix
the bugs in bash_completion. As far as I can see it's impossible to do
the completion the same way as the built-in completion.
When my ${COMP_WORDS[COMP_CWORD]} is STORE\' and I have the following
files in $PWD:
STORE'N'GO
STORE\'N\'GO
Then I have a hard time getting this information to compgen. The only
way I can think of is to do the shell-quoting myself and then let
compgen strip it away again. This is obviously not very nice, certainly
error-prone and maybe even impossible. Do you agree?
> (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
Can you elaborate on the differences in case they're the cause of other
strange behaviours?
> though that function has several problems.)
Are you referring to compgen or some function in bash_completion?
> 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.
Yes, that would be nice. I'm willing to test it.
Another possibility would be to provide means to do shell-quoting and
de-quoting from within bash. Or is this possible in a safe and resonably
easy way even now?
> (The problem with SIGINT is completely different. Some library state
> needs to be reset on SIGINT. That will be fixed in the next version.)
OK, great!
Regards,
Mika
Re: compgen gets confused when trying to complete ambiguous special char
Mika Fischer wrote:
* Chet Ramey <[EMAIL PROTECTED]> [2008-03-17 18:47]:
For historical reasons, complete/compgen dequote the filename they're
passed, removing backslash escapes and interpreting embedded quoted
substrings.
Yes. I've run into this problem now several times while trying to fix
the bugs in bash_completion. As far as I can see it's impossible to do
the completion the same way as the built-in completion.
It's probably time to take the dequoting out of compgen when it's not
run from the readline completion code.
When my ${COMP_WORDS[COMP_CWORD]} is STORE\' and I have the following
files in $PWD:
STORE'N'GO
STORE\'N\'GO
Then I have a hard time getting this information to compgen. The only
way I can think of is to do the shell-quoting myself and then let
compgen strip it away again. This is obviously not very nice, certainly
error-prone and maybe even impossible. Do you agree?
It's not really possible. One of the things that's wrong with the bash
helper function that dequotes filenames for readline is that it doesn't
implement shell quoting rules.
(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
Can you elaborate on the differences in case they're the cause of other
strange behaviours?
1. Backslashes should not be stripped within single quotes.
2. Backslashes should only be stripped within double quotes if they're
followed by one of $ ` " \
Are you referring to compgen or some function in bash_completion?
The filename dequoting function that's part of the bash readline support.
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.
Yes, that would be nice. I'm willing to test it.
OK, I attached a patch.
Another possibility would be to provide means to do shell-quoting and
de-quoting from within bash. Or is this possible in a safe and resonably
easy way even now?
There's no reason to do shell quoting from within bash; the following
does the job:
quote()
{
echo \'${1//\'/\'\\\'\'}\'
}
and its inverse:
dequote()
{
eval echo "$1"
}
That handles only quote characters; I didn't test it with parameter and
variable expansion, though it should work.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
*** ../bash-3.2-patched/pcomplete.c 2006-07-27 09:39:02.0 -0400
--- pcomplete.c 2008-03-17 14:10:07.0 -0400
***
*** 689,704
FREE (dfn);
/* remove backslashes quoting special characters in filenames. */
if (rl_filename_dequoting_function)
{
- #if 0
- qc = (text[0] == '"' || text[0] == '\'') ? text[0] : 0;
- #else
/* Use rl_completion_quote_character because any single or
double quotes have been removed by the time TEXT makes it
here, and we don't want to remove backslashes inside
quoted strings. */
! qc = rl_dispatching ? rl_completion_quote_character : 0;
! #endif
! dfn = (*rl_filename_dequoting_function) ((char *)text, qc);
}
else
--- 689,703
FREE (dfn);
/* remove backslashes quoting special characters in filenames. */
+ #if 1
+ if (RL_ISSTATE (RL_STATE_COMPLETING) && rl_filename_dequoting_function)
+ #else
if (rl_filename_dequoting_function)
+ #endif
{
/* Use rl_completion_quote_character because any single or
double quotes have been removed by the time TEXT makes it
here, and we don't want to remove backslashes inside
quoted strings. */
! dfn = (*rl_filename_dequoting_function) ((char *)text, rl_completion_quote_character);
}
else
document export x=1 y=$x
On the man page at section "export", mention that the latter below will not do what one expects, as here revealed: $ set -x $ a=1 b=$a + a=1 + b=1 $ export x=1 y=$x + export x=1 y= + x=1 + y= Yes I'm sure it is mentioned elsewhere on the page but you might want to drum it home again here. Maybe also at $ help export.
Re: compgen gets confused when trying to complete ambiguous special char
* Chet Ramey <[EMAIL PROTECTED]> [2008-03-17 22:57]:
>> Can you elaborate on the differences in case they're the cause of other
>> strange behaviours?
>
> 1. Backslashes should not be stripped within single quotes.
>
> 2. Backslashes should only be stripped within double quotes if they're
> followed by one of $ ` " \
Ah, that's the reason for this behaviour then (using your quote func.):
[EMAIL PROTECTED]:~/rrr$ compgen -f $(quote "STORE")
STORE\'N\'GO
STORE'N'GO
[EMAIL PROTECTED]:~/rrr$ compgen -f $(quote "STORE'")
STORE'N'GO
[EMAIL PROTECTED]:~/rrr$ compgen -f $(quote "STORE\'")
[EMAIL PROTECTED]:~/rrr(1)$ compgen -f $(quote "STORE\\'")
[EMAIL PROTECTED]:~/rrr(1)$ compgen -f $(quote "STORE\\\'")
STORE\'N\'GO
So I guess I would not need the quote fuction but a function that quotes
the way compgen unquotes :)
I tried this and it seems to work:
quote2()
{
local t=${1//\\/}
echo \'${t//\'/\'\\\'\'}\'
}
[EMAIL PROTECTED]:~/rrr$ for i in test*; do echo -n "${i:0:5}: "; compgen -f
"$(quote2 "${i:0:5}")"; done
test`: test`test
test : test test
test': test'test
test": test"test
test$: test$test
test\: test\test
Something like this could be useful as a workaround for older versions
of bash. Comments?
> OK, I attached a patch.
On first sight this seems to work well:
[EMAIL PROTECTED]:~/rrr(1)$ compgen -f "STORE"
STORE\'N\'GO
STORE'N'GO
[EMAIL PROTECTED]:~/rrr$ compgen -f "STORE'"
STORE'N'GO
[EMAIL PROTECTED]:~/rrr$ compgen -f "STORE\'"
STORE\'N\'GO
[EMAIL PROTECTED]:~/rrr$ compgen -f "STORE\\'"
STORE\'N\'GO
[EMAIL PROTECTED]:~/rrr$ compgen -f "STORE\\\'"
[EMAIL PROTECTED]:~/rrr(1)$
[EMAIL PROTECTED]:~/rrr(1)$ for i in test*; do echo -n "${i:0:5}: "; compgen -f
"${i:0:5}"; done
test`: test`test
test : test test
test': test'test
test": test"test
test$: test$test
test\: test\test
I'll test it a bit more tomorrow.
Thanks a lot for now!
Regards,
Mika
Re: Temporarily change completion options
Mika Fischer wrote: Hi, I'm currently working on the bash-completion package for Debian/Ubuntu. I'd like to know if it is possible to change the options of the programable completion within the completion function. Not currently. I'm thinking about a new builtin that would accept the same set of -o options as complete/compgen (and probably +o to turn them off, as with the `set' builtin). There's no reason to invent a new set of special shell varaiables. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
