Re: mv w/mkdir -p of destination

[Bernhard Voelker]

On 2020-07-04 01:22, Vito Caputo wrote:
> Wouldn't we just make -D require -t/--target-directory when supplied to
> cp(1) or mv(1)?

Many things are possible.

The problem with adding and adding little features not belonging to a tool's 
primary
purpose would lead to tools which would become more and more complex.  For 
example,
after adding the mkdir() functionality for the destination directory to cp(1),
one might argue that one might control the permissions that directory; another 
user
might then wish to create the directory with a different group.  Etc., etc.

Like that, we'd end up with all tools being big and having the functionality of
all the other tools.  And being extremely complex. This contradicts the idea
of the UNIX toolbox [1].  There are tools which have to go a certain way in that
direction because the features somehow still belong to their domain (maybe e.g. 
rsync),
but the GNU coreutils and basic tools like mv and cp do definitely not belong to
that group.  As Kaz wrote: mv started as a wrapper for the system call rename().

[1] 
https://www.gnu.org/software/coreutils/manual/html_node/Opening-the-software-toolbox.html#Opening-the-software-toolbox

Next, adding a short option to a basic tool like cp and mv requires very strong 
arguments,
like precedence in other implementations or a requirement in POSIX.

Finally, this has already been discussed (see #1 of rejected ideas for mv(1)):
https://www.gnu.org/software/coreutils/rejected_requests.html
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=5926

I see it like this (which can also be applied to topics outside of software 
development):
while something is possible, that doesn't necessarily mean that it should be 
done.

Still, thanks for the idea and the discussion about it.

Have a nice day,
Berny