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? >> > >
