Re: compgen stops processing backslashes after any call to bind

[Chet Ramey]

On 12/14/22 7:55 PM, Fabien Orjollet wrote:

> Bash Version: 5.2
> Patch Level: 2
> Release Status: release
>
> Description:
>      compgen's behavior regarding backslash processing is altered by
>      any call to bind.
>      Therefore, file and directory names containing a backslash are
>      not completed once bind has been called.

Actually neither of these cases should work.

When compgen is called `standalone', not as part of readline completion,
it calls an application-specific filename dequoting function on its word
argument, since readline is not there to call it. Ordinarily, readline
calls any application-specific dequoting function before calling the
application-specific completion function (or performing filename
completion). This is one way bash tries to make compgen and tab completion
consistent.

Bash doesn't call its readline initialization function until it needs to,
e.g. before the first call to readline() or when `bind' is called the
first time. `set -o emacs' isn't sufficient; all that does is say to call
readline() the next time you need to read an input line (obviously not
operative in a non-interactive shell) and which keymaps to use; the actual
initialization happens when readline is called.

compgen doesn't cause readline initialization.

One aspect of bash's readline initialization is installing its specific
filename dequoting function. So the first time your script calls compgen,
no dequoting takes place, and the second time the argument gets run through
the dequoting function.

Your arguments undergo word expansion, including double-quote processing,
before compgen sees them. For instance, "/tmp/Dir\\A" ends up as /tmp/Dir\A
when compgen sees it. Add compgen dequoting the string and you see what
happens.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/