Re: mv w/mkdir -p of destination

[Vito Caputo]

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