bug-bash
[Top][All Lists]
Advanced

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

Re: New feature of command name completion?


From: Chet Ramey
Subject: Re: New feature of command name completion?
Date: Thu, 29 Jul 2004 11:59:43 -0400

> Machine Type: i386-pc-linux-gnu
> 
> Bash Version: 2.05b
> Patch Level: 0
> Release Status: release
> 
> Description:
>         I had just upgraded Debian sarge yesterday from woody, but I
> realised only now, that the command name complete function (TAB) of bash
> doesn't work "correctly", when I want to run a program in an other
> directory.
>       After it I have found that there is a change in command name
> completion in bash (slash is no longer appended in some cases...)
> that I don't believe a good idea.

The `mark-symlinked-directories' readline variable, introduced in bash-2.05b,
controls this behavior.

Here's the text of an old message I sent out in May, 2003 explaining
the rationale for the change:


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

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
                                                Live...Laugh...Love
Chet Ramey, ITS, CWRU    chet@po.cwru.edu    http://tiswww.tis.cwru.edu/~chet/




reply via email to

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