fileutils: inconsistent behaviour stripping / from end of filenames

[Jim Meyering]

Thanks for the report.

Fixing this is on my short list -- and I even have a patch from
Paul Eggert that makes everything more consistent (and in this case,
more POSIX compliant).  The problem is that the changes will have some
undesirable side effects:  if you use a shell with file name completion
that appends trailing slashes (and doesn't later remove them), you will
find that commands like this one will fail:

  rm -r /some/long-directory-name-obtained-via-completion/

The same applies to rmdir.

If you're lucky enough to use zsh, you don't have to worry about that,
since its AUTO_REMOVE_SLASH option arranges to remove a completion-added
trailing slash when necessary.  But users of other shells (notably,
bash) don't have such an option.

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.
Once I'm ok with that, I'll probably apply Paul's patch, make a test
release, and see what happens.

Edward Avis <address@hidden> wrote:
> % mkdir test
> % cd test
> % touch a
> % cp a/ b
> cp: cannot stat `a/': Not a directory
> % rm -v a/
> removing `a'
>
> It seems that rm strips the trailing slashes off a filename, even when
> the file is not a directory.  But cp does not.  To me it seems kinda
> wrong to accept the trailing slashes for a regular file, but anyway,
> all the fileutils ought to have the same policy on this.
>
> I went through all the programs of fileutils and found that chmod,
> chown, rm and du will accept trailing slashes on regular file names.
> All the others will (correctly, IMHO) give an error, usually 'Not a
> directory'.  I didn't test mkdir, mknod, sync, dircolors or mkfifo.
>
> The error message from touch is interesting:
>
> % touch a
> % touch a/
> touch: creating `a/': Is a directory