bug#5926: feature request: mv -p to create missing target dir

[Bob Proulx]

Rodolfo Borges wrote:
> Bob Proulx wrote:
> > Rodolfo Borges wrote:
> >> $ :(
> >> bash: syntax error near unexpected token `newline'
> >> ...
> >> $ :)
> >> bash: syntax error near unexpected token `)'
> >
> > Using this format to tell us what you are thinking is very confusing!
> 
> It seems you haven't got the writing style.

No.  When reading through reported bugs one is naturally looking for
error messages.  By including error messages in your report that are
unrelated to the topic you are reporting it actively distracts from
it.  It makes the job of reading your report much harder.

> I know the cause of the error in the first `mv` and, sheesh!, I
> frigging know bash doesn't understand emoticons.

Including smileys or frownies is just fine.  It was only the bash
error message that you included along with them that I found difficult.

> Better to fallback to plain boring English, then.

Please do.  Thank you.

> >> $ mv -vp foo ~/some/path/
> >> mv: created directory `/home/bart9h/some'
> >> mv: created directory `/home/bart9h/some/path/'
> >> `foo' -> `/home/bart9h/some/path/foo'
> >
> > I don't think this is a good idea.  It could be added.  But does it
> > really gain you anything over calling mkdir -p?
> > I don't think so.
> > It would simply add code bloat to the program.
> 
> You don't have to type the path twice, and more importantly, you don't

True.  But the same could be said for any complex command that could
be written to do any ten or twenty things all in one command.  You
want one thing, I want a different thing, ten other people want ten
other different things.  Creating such complex commands is not a good
thing and violates the Unix Philosophy as I explained.

> have to know beforehand that the path doesn't exist yet.

That is also true of calling 'mkdir -p DIR' on the path beforehand.
You don't have to know if it exists or not.

> The use case if fairly common: you start typing `mv
> my-first-salsa-album/ ~/music/sal<tab><tab>` ops!, I have no salsa
> subdir yet in my music collection: I have to cancel the command,
> create the directory, then type it again.

For someone who always used the proposed 'mv -p' option it would mean
that a typo would accidentally create a new and differently named
directory by mistake.  Your typing and spelling would need to be
consistent and accurate because the risk from a mistake would be
increased.

> > Plus it wouldn't be portable.  Other implementations wouldn't have it.
> > It is only of marginal benefit if at all and so other implementations
> > might never have it.  In any case you would need to wait years before
> > the feature trickled down to where you could use it reliably.
> 
> The GNU utilities already have a bunch of features that other
> implementations don't have.

True.

> > Also you can always accomplish this yourself with a shell script.  In
> > general things that can be easily encapsulated in a shell script are
> > not good additions to the utilities.
> 
> cat <<EOF >> ~/.bashrc
> function mv() {
>     local target="${!#}"
>     local dir
>     if [[ "$target" =~ '/$' ]]; then
>         dir="$target"
>     else
>         dir="$(dirname "$target")"
>     fi
>     test -d "$dir" || mkdir -vp "$dir"
>     $(which mv) "$@"
> }
> EOF

Very good!  I see that you have a solution to your problem.

As a side comment I don't see the point of:

>     $(which mv) "$@"

The 'which' command is another one of those simple but not very
portable commands that does different things on different systems.  In
the simple case of reporting where the command is found on PATH the
use here is redundant since the command would otherwise simply be
found on PATH.

  mv "$@"

> > Adding that option is counter to The Unix Philosophy.  Small is
> > beautiful.  Make each program do one thing well.  Choose portability
> > over efficiency.  Use shell scripts to increase leverage and
> > portability.
> 
> `cp` does create directories, shouldn't it restrict itself to copying
> files then?

The -R, -r, --recursive option does copy directories recursively.  It
is a copy of the input directory hierarchy and therefore cp copies it.
But is that the same thing as making arbitrary directories down the
destination path?  I don't think so.

Since you have a simple resolution to your issue by using your small
shell script and no one else has joined into the discussion and
sufficient time has passed to allow everyone to have read it then I
will assume that there isn't any motivation from others to make this
change.  Therefore I am going to close this bug.  It will remain in
the archive and will be available for further discussion.  If the
opinion changes then the issue may be reopened.

Bob