Re: mv trailing slash warning

[Jim Meyering]

Paul Eggert <address@hidden> wrote:

> Jim Meyering <address@hidden> writes:
>
>> As you can imagine, I find the POSIX-required behavior to be senseless.
>
> Two things.
>
> First, I recall that you preferred the non-POSIX behavior because of
> file name completion issues.  But because we agitated about this a

That was indeed a motivator, since it made the commands
with ambiguous syntax more likely.

> while ago, Bash now does a better job with file name completion.  For
> example, given this:
...
> and so there was more of an argument that "mv symlink/ target" should
> ignore the slash.  Nowadays, though, isn't that argument weaker?

Even if bash fixes things to make this less likely, there's still plenty
of room for user error and confusion, especially since less-seasoned
users still use shells that cannot -- or are not configured to -- clean
up the syntax of their commands.

Personally, this hasn't affected me for some time (since I
switched to zsh).  zsh can be configured so that it completes
the trailing slash in

I type
  mv symli<TAB>
zsh does this:
  mv symlink/

But the moment I type the space after the zsh-added `/',
zsh removes that slash.  If I type the slash, zsh leaves it.

That said, I looked in some old command history logs and see hundreds
of commands I typed (back before using zsh) including trailing slashes
like this:

  mv dir/ new-name

I know lots of people who would be very annoyed if they
had to change habits or even just add an option via an alias
to avoid failure in cases like those.

> Second, I just read the POSIX spec and it seems to be a bit buggy
> <http://www.opengroup.org/onlinepubs/009695399/functions/rename.html>.
> The rationale says "Renaming dot or dot-dot is prohibited" but I can't
> see anything to that effect in the text itself.
>
> Furthermore, POSIX says that a pathname like "abc/" must be resolved
> as if it were "abc/." (see
> <http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11>)
> so arguably rename("abc/", "def") must be handled like rename("abc/.",
> "def") and if renaming dot or dot-dot is prohibited (which I think it
> must be, even if it's omitted inadvertently from the standard) then
> this must fail.
>
> There's a similar issue with "rmdir symlink/".  It's not clear that
> rmdir ("symlink/") should succeed, because pathname resolution
> indicates that it should be treated like rmdir ("symlink/.") and this
> clearly must fail.
>
>
> Clearly it's a messy area.
>
> My kneejerk reaction is that I might prefer it if "mv symlink/ foo"
> and "rmdir symlink/" always failed, if only because in a confusing
> situation like this it's often better to use the Hippocratic rule:
> first, do no harm.  It would be easy to implement that rule: it
> wouldn't require any system calls at all, since we could simply reject
> all file names with trailing slashes.

IMHO, such a move [making mv fail for any source argument specified
with a trailing slash] would `do harm' :-) albeit to people's
sensibilities when GNU mv starts griping, not to their files.

I think the wrapper-induced overhead of an extra lstat imposed on losing
systems, but only for operands with a trailing slash, is bearable.
This is one of those `would be nice' things.
But I'm not in any big hurry, since Linux 2.6.x does it right.