bug#36901: Enhance directory and file moves where target already exists

[Assaf Gordon]

Hello,

On Fri, Aug 02, 2019 at 10:47:18PM -0700, L A Walsh wrote:
> It's not a wish list that 'mv' doesn't work as documented.

The "wishlist" refers to the topic:
You are asking to add new funtionality to 'mv'.
That is a "wishlist" item.


(answering out of order:)

> > On 2019-08-02 9:56 p.m., L A Walsh wrote:
> >> But you say posix wants it to perform as a rename?
[...]
> >>
> >> So if I have:
> >> mkdir A B
> >> touch A/foo B/fee
> >> So when I look at the system call on linux for rename:
> >>         oldpath can specify a directory.  In this case, newpath must
> >>         either not
> >>         exist, or it must specify an empty directory.
> >>          (complying with POSIX_C_SOURCE >= 200809L)
> >>
> >> So move should give an error: Nope:
> >>
> >> mv A B
> >>> tree B
> >> B
> >> ├── A
> >> │   └── foo
> >> └── fee
> >>
> >> 1 directory, 2 files
> >>
> >> So mv is violating POSIX - it didn't do the rename, but moved
> >> A under B and neither dir had to be empty.
> >>
> >> Saying it has to follow POSIX when it doesn't appear to, seems
> >> a bit contradictory?

I previously quoted one small part of the entire "mv" POSIX specification
(item #3, regarding using the 'rename(2)' function).

It would be wise to read the entire specification before making claims
about violating POSIX.
Specifically, at the top of the page:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html
   SYNOPSIS
      mv [-if] source_file target_file
      mv [-if] source_file... target_dir
   DESCRIPTION
      [...]
      In the second synopsis form, mv shall move each file named by a
      source_file operand to a destination file in the existing directory
      named by the target_dir operand [...] This second form is assumed
      when the final operand names an existing directory

In this regard GNU 'mv' is compliant with POSIX.


> > On 2019-08-02 9:56 p.m., L A Walsh wrote:
> >> On 2019/08/02 19:47, Assaf Gordon wrote:
> >>> Can new merging features be added to 'mv'? yes.
> >>> But it seems to me these would be better suited for 'higher level'
> >>> programs (e.g. a GUI file manager).
> >> ---
> >> If the command was named 'ren', then I'd expect it to be dummer,
> >> but 'mv'/move seem like it should be able to move files from
> >> one dir into another.
> >>
> >> But you say posix wants it to perform as a rename?
> >> I know, create a 're' command (or 'rn') for rename, and have
> >> it do what 'mv' would do.  Maybe posix would realize it would
> >> be better to have re/rn behave like rename, and 'mv' to
> >> behave it was moving something.

The Austin group (https://www.opengroup.org/austin/) who is in charge
of developing and maintaining the POSIX standard is the place
to go when wanting to change things in POSIX (or add new things).

You can write to them, suggest a modification,
and if they change the standard, GNU coreutils will surely follow.

As for renaming 'mv' or creating new 'rn' command -
part of POSIX is to codify existing behavior (that is - programs which
were in common use *before* POSIX).  It's not always logic, it's not always
ideal, but that's what has been in use for many years.

Based on mv's wiki page (https://en.wikipedia.org/wiki/Mv), 'mv' was
first introduced in 1971, 47 years ago.
With hindsight of nearly 5 decades it's easy to point to faults in a
program. If we were designing 'mv' today from scratch, I'm sure we would
improve many of its aspects.

But given that it is a long-standing program and its usage and quirks
are well established, I'm inclined to say it is highly unlikely
we will change mv's default behaviour or replace it with a different
name.

Adding new functionality (e.g. a new '--merge-directory' option)
is possible, and concrete patches are always welcomed.
However, given all the above, there is no guarentee that such new option
will be accepted.
I still think that such specific features are better suited for more
sophisticated programs (whether GUI or command line).

regards,
 - assaf