[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mv w/mkdir -p of destination

From: Kaz Kylheku (Coreutils)
Subject: Re: mv w/mkdir -p of destination
Date: Fri, 03 Jul 2020 16:18:00 -0700
User-agent: Roundcube Webmail/0.9.2

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

(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
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]