Re: mv trailing slash warning

[Eric Blake]

[cc-ing bash-completion maintainer]

> First, I recall that you preferred the non-POSIX behavior because of
> file name completion issues.  But because we agitated about this a
> while ago, Bash now does a better job with file name completion.  For
> example, given this:
> 
>      mkdir dir
>      ln -s dir symlink
> 
> If I type "mv sym[TAB]", where [TAB] stands for a tab character, the
> screen then looks like this:
> 
>     mv symlink
> 
> If I type another [TAB] it then looks like this:
> 
>     mv symlink/

This assumes, of course, that you don't have
'set mark-symlinked-directories on' in your ~/.inputrc, at which point
a single [TAB] completes the trailing slash.

On the other hand, with the bash-completion package, it might make
sense for programmable completion for mv, cp, and rm to omit the
trailing slash in spite of the mark-symlinked-directories setting.  The
only argument against this is that there is no way to know whether
the user really meant to move (or copy or delete) the symlink to a
directory, vs. a file located in the directory, until they move on to the
next word or hit Enter.  This was the entire reason that
mark-symlinked-directories exists in readline, and --strip-trailing-slashes
exists as an option to mv and cp.

On a related note, why don't rm and rmdir have a --strip-trailing-slashes
option?

> 
> so I'm given a signal from Bash that I have a symlink to a directory,
> and that it matters whether there's a trailing slash.
> 
> 
> 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.

Agreed - we should bring this up with the austin group.  Something
along the lines of this statement from rmdir():

"If the path argument refers to a path whose final component is either
dot or dot-dot, rmdir() shall fail."
...
"[EINVAL] 
The path argument contains a last component that is dot."

> 
> 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_1
> 1>)
> 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.

I agree with your logic here on rename(2) needing to fail on a trailing
slash if it is also supposed to fail on a trailing dot.  But that doesn't
necessarily mean that mv(1) need to fail on a trailing slash or dot.

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

Oops - cygwin has a bug in this regards:
$ mkdir dir
$ rmdir dir/.
$ echo $?
0
$ ls dir
ls: dir: No such file or directory

Is it worth patching coreutils rm and rmdir to work around buggy
systems that don't follow this POSIX restriction on rmdir()?  (Meanwhile,
I will try to get cygwin fixed.)  Should we update the coreutils testsuite?

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

You could probably convince me that your proposed approach of
always rejecting an operation with a trailing slash is valid, as long
as the error message gives a hint to the user on how to do what
they wanted, and as long as --strip-trailing-slashes still worked.
 
On the other hand, since 'mv symlink/ foo' invokes underspecified
behavior in rename(2), maybe we can get away with deciding that
mv(1) always behaves as --strip-trailing-slashes - is there anything
in POSIX that would prohibit us from always stripping the trailing
slash and acting on the symlink without an explicit option requesting
that behavior?

--
Eric Blake