Re: mv w/mkdir -p of destination

[Kaz Kylheku (Coreutils)]

On 2020-07-03 14:38, Bernhard Voelker wrote:
> On 2020-05-11 05:16, Vito Caputo wrote:
> > Does this already exist?
> >
> > Was just moving a .tgz into a deep path and realized I hadn't created
> > it on that host, and lamented not knowing what convenient flag I could
> > toss on the end of the typed command to make `mv` do the mkdir -p
> > first for me.
> >
> > I was surprised to not see it in mv --help or mv(1) when I checked for
> > next time...
>
> mv(1) is ... well, for moving files and directories.

If we consider a filesystem to be a collection containing a name space
which assigns path names to objects, then mv is a tool for re-assigning
a new path name to an object.

Years ago I implemented this concept in a version control system.
It has a mv command which works regardless of whether directories
exist.

(In fact instead of using the mv command, you can edit the 
representation
of the directory structure, and then run an update command to re-shape
the workspace accordingly; mv works by doing the same thing.)

However, the tool did not store a representation of directories at all.
Just files and symbolic links.

If a directory-restructuring operation renames all the files out of
a directory, that directory is removed (unless it contains
local, untracked content). Its parent is removed if it becomes empty
and so on.

It works beautifully and is intuitive to use.

> And creating the
> destination
> directory in the same go seems to be a seldom case.  We see also from
> the missing
> answers so far, that nobody seems to be much excited about this 
> feature.
> Anyway, as it's very easy to work around it with a separate mkdir(1)

Not to mention rmdir! If you have moved all content out of a directory,
you may not want it to exist. For symmetry "mv -p" should remove all
empty directories left behind, as far up the tree as possible and
as permissions will allow.

> it's better
> to avoid adding complexity to the code.

Of course, the complexity doesn't go away; i.e. it stays with the
user to grapple with. Though forty years of Unix users don't
seem to have minded all the various inconvenience, so why bother.