On 2020-07-04 00:08, Vito Caputo wrote:
> Considering install(1) already establishes precedent -D as a means of
> augmenting --target-directory to create parents, and both cp(1) and
> mv(1) provide --target-directory, it strikes me as an existing
> inconsistency to be arguably fixed on those grounds alone.
I disagree: IMO there's nothing to fix in mv(1) and cp(1) because it's
not their job to create a destination directory.
The install(1) tool has -D because that has a different scope (and can
not operate recursively).
Furthermore, adding a -D option would make the synopsis of mv(1)
and cp(1) (when called without -t) ambiguous:
Usage: cp [OPTION]... [-T] SOURCE DEST
or: cp [OPTION]... SOURCE... DIRECTORY
Usage: mv [OPTION]... [-T] SOURCE DEST
or: mv [OPTION]... SOURCE... DIRECTORY
How could the tool differentiate whether the last argument is a non-existing
destination directory (to be created) or the name of the destination file?
$ touch afile
$ mv -D afile dir2create
vs.
$ mv -D afile afile.renamed
This simple example already demonstrates that it is not easy at all to
add the feature in a consistent way ... leaving the added code complexity
and the maintenance burden for it aside.
Finally, the bar is very high to add options like this to basic command
like mv and cp, especially if the functionality can easily be achieved
with a separate command like mkdir(1).
Have a nice day,
Berny
