Re: fileutils: inconsistent behaviour stripping / from end of filenames

[Paul Eggert]

> From: Jim Meyering <address@hidden>
> Date: Wed, 12 Sep 2001 12:27:36 +0200
> 
> I've requested twice that such a feature be added to bash.  Initially,
> I intended to wait at least until a test release of bash had the new
> option, but without assurance that it'll even happen, I'm not going
> to wait any longer.  Personally, I've nearly converted to using zsh.

The latest test version of Bash (2.05a, issued late last month)
doesn't append the / to a symlink to a directory, unless you type TAB
twice.  For example, given:

  $ mkdir /tmp/d
  $ cd /tmp/d
  $ mkdir fie
  $ ln -s fie foo

Then:

  "ls f<TAB>" completes to itself, with a beep, as both "foo" and "fie" exist.
  "ls fo<TAB>" completes to "ls foo".
  "ls foo<TAB>" completes to "ls foo/".
  "ls fi<TAB>" completes to "ls fie/".

This is perhaps not quite as nice as zsh in all cases, but it is good
enough for me in practice.

I vaguely recall having a similar discussion with Jim Meyering in May,
and he indicated that the Bash 2.05a behavior wasn't quite good
enough, but I forgot exactly what behavior he wanted instead.  If he
can suggest something perhaps we can add it to Bash as well, as an
option.


> Date: Wed, 12 Sep 2001 12:15:17 +0100 (BST)
> From: Edward Avis <address@hidden>
> 
> I just feel that the trailing slashes shouldn't be accepted on
> something that isn't a directory.

I tend to agree.

> If POSIX mandates that rm should choke on trailing slashes after a
> directory name, then POSIX is stupid and this behaviour should be
> reserved for when POSIXLY_CORRECT is set.

In POSIX's defense, POSIX is attempting to be consistent.

If FOO is a symbolic link to a directory, then "ls -l FOO" talks about
the symbolic link, but "ls -l FOO/" talks about the directory, i.e. it
is roughly equivalent to "ls -l FOO/.".  This is longstanding tradition.

For consistency, then, POSIX says that "rm FOO" should remove the
symbolic link, and that "rm FOO/" should attempt to remove "FOO/."
(unsuccessfully, of course).

This behavior may not be what you want in that particular case, but it
does have the advantage of consistency for all utilities.  So it is
not entirely stupid (though it may be mistaken for "rm" :-).


> It would be very disconcerting for bash to complete characters and
> then remove them again without asking.

I also am leery of this part of zsh's behavior.  But if it is useful and
if some people like it, I see no harm in adding it to Bash as an option.

> There is an established convention that shell completion adds the slash,
> and that programs do not complain about it:

Unfortunately this collides with POSIX's desire for consistency, which
is where the problem arises.