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
