[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: forwarded: annoying change in completion behaviour with no way to re
Re: forwarded: annoying change in completion behaviour with no way to revert
Mon, 10 Dec 2001 12:51:14 -0500
> From: James Troup <address@hidden>
> Sender: James Troup (laptop) <address@hidden>
> To: address@hidden
> Subject: Bug#120854: readline: annoying change in completion behaviour with
> no way to revert
> Date: 24 Nov 2001 02:18:14 +0000
> Package: libreadline4
> Version: 4.2a-2
> Severity: important
> [Well.. perhaps not, but it's annoying the heck out of me :/]
> In what was advertised as a 'mainly bugfix and code cleanup release',
> this little gem slipped in:
> | 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.
> Err, ARGH! my / is populated by symlinks so almost every time I go to
> complete a full path I get bitten by this new behaviour and fluff up
> the filename. _Pretty Please_ (with a cherry on top) can this
> behaviour be made optional?
The bash/readline behavior through bash-2.05/readline-4.2 was first
reported as a bug in January, 2000 by Jim Meyering
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.
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 problem 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
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
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 I think 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 at least five complaints about this since
bash-2.05a was released, so I will make it a settable readline option
for the next release.
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet)
Chet Ramey, CWRU address@hidden http://cnswww.cns.cwru.edu/~chet/
- Re: forwarded: annoying change in completion behaviour with no way to revert,
Chet Ramey <=