On Sat, Jul 04, 2020 at 12:50:15AM +0200, Bernhard Voelker wrote: > 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. >
Wouldn't we just make -D require -t/--target-directory when supplied to cp(1) or mv(1)? The idiomatic usage could be `mv src [src...] -Dt dest`. That strikes me as more consistent than having --target-directory but entirely omitting any way to augment its behavior for creating parents. At least offer it in the unambiguous scenario. Regards, Vito Caputo
