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
