Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
