compgen -d odd symlink behavior

[Chet Ramey]

On 4/21/19 6:39 AM, Ville Skyttä wrote:

> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
> 
> Description:
> 
> Originally reported in https://github.com/scop/bash-completion/issues/118
> This is on Ubuntu's 4.4.19, but reproducible with Fedora development's
> 5.0.2 as well.
> 
> Repeat-By:
> 
> $ ( mkdir -p 1/11 1/x 2/22; ln -sf ../1/x 2/x; cd 2/x; compgen -d ../ )
> ../x
> 
> Only ../x is output, but depending on interpretation, in my opinion either
> ../22 or ../11 should have been there. Note that this occurs only if I'm in
> the "x" dir that is a symlink. If I'm in the "real x", i.e. 1/x, the
> problem does not occur, "../11" is in the output as expected:
> 
> $ ( mkdir -p 1/11 1/x 2/22; ln -sf ../1/x 2/x; cd 1/x; compgen -d ../ )
> ../11
> ../x

Here's what happens. The shell canonicalizes the directory pathname, since
it's running in logical mode (the default). This results in /.../2/x/..,
which canonicalizes to /.../2/. Readline reads this directory, which
returns `x' (which is rewritten to ../x) and `22' (../22). That's the match
list.

The list then gets sent through a function that discards non-directories,
but that function doesn't canonicalize the directory pathname. Since it's
in the `real' x (1/x), it tests 1/x/../x (which succeeds -- it's a
directory) and 1/x/../22 (which does not).

The obvious change to make is to have the programmable completion code use
a function that canonicalizes the names in the same way used when
generating the list of completions before testing whether or not the name
is a directory.

The results should be consistent from the same interactive shell, whether
you're executing tab completion or compgen.

Chet
-- 
``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/