Path completion and soft links

[Chet Ramey]

>There is one thing that annoys me extremely in late version of Bash:
>when there is a soft link in the path that points to a directory, it takes
>one more <TAB> to proceed. E.g.
>
>cd /tmp;ln -s /bin .
>
>Now, `ls /tmp/bi<TAB>' results in "ls /tmp/bin" (no trailing '/'), and I
>have to press the <TAB> one more time (or press '/') in order to
>proceed typing the path.
>
>This didn't happen earlier (2.01 at least works correctly). Is there a
>setting that alters this behaviour?

The bash/readline behavior through bash-2.05/readline-4.2 was first
reported as a bug in January, 2000 by Jim Meyering
(http://mail.gnu.org/pipermail/bug-bash/2000-January/000220.html).  It
came up again in May, 2001, when Paul Eggert proposed the current
behavior as a solution.  Another discussion took place on bug-bash
in September, 2001.

So, we find the following in the CHANGES file for bash-2.05a:

c.  The completion code no longer appends a `/' or ` ' to a match when
    completing a symbolic link that resolves to a directory name, unless
    the match does not add anything to the word being completed.  This
    means that a tab will complete the word up to the full name, but not
    add anything, and a subsequent tab will add a slash.

The idea is that bash, when asked to complete a symbolic link to a
directory, shouldn't append either a `/' or a ` ' unless the user
makes his intention clear.

The basic concept is that symbolic links to directories are special.
Adding a slash to a symbolic link changes the object from the symlink
to its target.  That is, if FOO is a symlink to a directory, FOO refers
to the symlink itself, and FOO/ refers to the directory (something
roughly equivalent to `FOO/.').

Sometimes you want the symbolic link:

                 mv symlink-to-dir new-name
or
                rm -r symlink-to-dir

and sometimes you don't.  If you issued that `rm' command with a trailing
slash on a POSIX system, you'd find that you've just removed a possibly
valuable directory and its contents.

Completion shouldn't make any guesses about what you want if there's
more than one possibility, so it's up to the user to choose.

You'll run into the previous scenario a lot on POSIX.2 systems.  POSIX
requires that
                        mv symlink-to-dir/ new-name

(which is what you'd get in previous versions if you completed the
first argument), act on the target of the symlink, not the link.  The
GNU fileutils had a `--strip-trailing-slashes' option to programs
like `mv' to deal with the problem, but POSIX forbids that behavior,
and Jim has since removed it.

Jim originally proposed a solution like zsh's AUTO_REMOVE_SLASH option,
but I don't like the idea of readline removing characters from the
input line without the user doing it, since it will have to be wrong
at least some of the time.  The bash-2.05a/readline-4.2a implementation
requires that the user disambiguate.

That said, there have been a number of complaints about this since
bash-2.05a was released, and I have made it a settable readline option
for the next release.

Chet