[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 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
