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

[Assaf Gordon]

severity 36901 wishlist
retitle 36901 mv: merge directories where target already exists
stop

Hello,

(for context: this is a new topic, diverged at https://bugs.gnu.org/36831#38 )

For completeness, quoting your second message ( from 
https://bugs.gnu.org/36831#50 ):

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).
> ---
>       But neither the person who posted the original bug on this
> nor I are using a GUI, we are running 'mv' GUI, we use the cmd line on
> linux, so that wouldn't
> be of any use.
> 
> 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.
> 
> 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?
>