GNU fileutils v3.2.3 alter pathnames by removing trailing slashes

Thread View: gnu.utils.bug

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by gnu Fri, 14 Aug 1992 05:45

#653

Author: gnu
Date: Fri, 14 Aug 1992 05:45

34 lines
1960 bytes

The file utilities (cp, mv, etc) eliminate some errors by always removing
trailing slashes from file names.  However, these errors should be caught,`
not ignored.  For example, in the command:

	cp foo bar/

the intention of the user is that if "bar" is a directory, the file
bar/foo is created.  But if "bar" is not a directory, rather than
producing a copy of foo called "bar", an error should be produced.
This is a simple way to protect yourself against typos in copying
files into directories.

Instead, the GNU fileutils produce a file called "bar", without any warning
or error.

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.  (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.  The Unix file utilities also handle
these pathnames.  We pride ourselves on doing better in the GNU system
than in the Unix system -- removing limitations, and doing better
error checking.  If a user specifies a pathname which cannot be
resolved, an error should be reported.

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.

	John Gilmore

Re: GNU fileutils v3.2.3 alter pathnames by removing trailing slashes

#699

Author: David J. MacKenzie
Date: Fri, 21 Aug 1992 17:55

40 lines
2399 bytes

> 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.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads