Re: strange behaviour with mv (fwd)

Thanks for the reply.  Originally, I thought it was strange
that "mv x y" and "mv x/ y" would behave differently, and
reported this as a bug to you.  Now I understand that they are
in fact supposed to behave differently.

However, it now seems to me there may be another bug.
My interpretation of what you've written is that "mv x/ y"
should move the dereferenced directory, when in fact
(as described in my original mail) it *copies* the dereferenced
directory, and all its contents, leaving the original intact.  
Isn't this wrong, given the spec you provided below ?

-mike


On Wed, 18 Sep 2002, Jim Meyering wrote:

> Michael McGuffin <[email protected]> wrote:
> > I may have found a bug with mv.  When x is a symlink to
> > a directory, the behaviour of
> >
> >    mv x y
> > and
> >    mv x/ y
> >
> > is not the same.  Please read the below description
> > I wrote, and the response I got from Derrick Moser.
> 
> Thanks for the report, but that is the documented (and required, as I
> understand the POSIX standard) behavior.  From the documentation
> (e.g., run `info mv'):
> 
>      _Warning_: If you try to move a symlink that points to a directory,
>   and you specify the symlink with a trailing slash, then `mv' doesn't
>   move the symlink but instead moves the directory referenced by the
>   symlink.  *Note Trailing slashes::.
> 
> And here's the above-referenced section on Trailing slashes:
> 
>   Trailing slashes
>   ================
> 
>      Some GNU programs (at least `cp' and `mv') allow you to remove any
>   trailing slashes from each SOURCE argument before operating on it.  The
>   `--strip-trailing-slashes' option enables this behavior.
> 
>      This is useful when a SOURCE argument may have a trailing slash and
>   specify a symbolic link to a directory.  This scenario is in fact rather
>   common because some shells can automatically append a trailing slash
>   when performing file name completion on such symbolic links.  Without
>   this option, `mv', for example, (via the system's rename function) must
>   interpret a trailing slash as a request to dereference the symbolic link
>   and so must rename the indirectly referenced _directory_ and not the
>   symbolic link.  Although it may seem surprising that such behavior be
>   the default, it is required by POSIX and is consistent with other parts
>   of that standard.
>