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

[L A Walsh]

It's not a wish list that 'mv' doesn't work as documented.


On 2019/08/02 22:45, Assaf Gordon wrote:
> 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?
>>
> 
>