🚀 go-pugleaf

> The file utilities (cp, mv, etc) eliminate some errors by always removing
> trailing slashes from file names.

> My guess is that somebody tried using the GNU fileutils under "bash"
> with filename completion, and had some minor problem because bash
> inserts a / at the end of a path if the last part of the name is a
> directory.

As you guessed, the behavior is intentional.  The problem is that the
Unix rename system call -- and maybe others, I don't remember anymore
-- returns an "Invalid argument" error if an argument ends in "/",
presumably because that really means "/.", which you're not allowed to
rename.

Not just bash -- filename completion in tcsh, ksh, bash, and zsh adds
a "/" after directory names.  I and many others use filename
completion quite often and it got to be very annoying to have to
remember to constantly back up and delete the slashes.

So I made mv ignore slashes; then I made the other utilities do so
also, for consistency (and because the output, for example of du, or
cp, mv, or ln -v, looks nicer without the excess slashes).  I've never
encountered problems from the slightly reduced error checking.  Maybe
I don't make the right kind of typos.

>  (Some part of the fileutils probably assumed that there
> would be no trailing slashes in names.)
> The Unix kernel properly handles names containing multiple leading,
> internal, and trailing slashes.

As noted above, this is not quite the case, at least in the DWIM sense.

> The fix is not indiscriminate bashing of trailing slashes, as
> currently implemented.  The fix is to remove the generic truncation of
> trailing slashes, then to fix whatever minor bugs prevent the use of
> pathnames containing trailing slashes.

Fix everyone's shells, or everyone's kernels?  I don't offhand see a
better solution than what the GNU utilities currently do.  But
specific suggestions are welcome.