Will `mv` ever have the ability to create directories?
Keep in mind that there is more than one implementation of mv
. The mv
you use on linux is not from the exact same source as the one on OSX or Solaris, etc. But it is desirable for them all to behave in the same way -- this is the point of standards. It's conceivable that a mv
implementation could add an option for this purpose, although since it is so simple to deal with, it would probably not be worthwhile because the very minor benefit is outwayed by a more significant negative consequence: Code written which exploited such a non-standard option of an implementation would not be portable to/behave constantly on another system using a standard implementation.
mv
is standardized by POSIX and this explicitly ties its behavior to the rename()
system call. In ISO C the behavior of rename()
is not very specific and much is left up to the implementation, but under POSIX you'll note the potential ENOENT
error, indicating "a component of the path prefix of new does not exist", describing the behavior to be expected in explicit terms. This is better than ambiguity and leaving such details up to the implementation, because doing the latter hurts the portability.
In defense of the design, in a scripting context it's probably better to by default fail on an invalid target path than assume it just needs to be created. This is because the path itself may often come from user input or configuration and may include a typo; in this case the script should fail at that point and indicate to the user that they've entered an invalid path. There is of course the option for the person who wrote the code to implement different behavior and create directories that don't exist, but it is better that you are responsible for doing that than the opposite (being responsible for ensuring a mv
call won't create previously non-existent directories).
Related videos on Youtube
texasflood
Updated on September 18, 2022Comments
-
texasflood almost 2 years
This question asks for the best way to create a directory when using
mv
if it doesn't exist. My question is why isn't this an inbuilt feature ofmv
? Is there some fundamental reason due to which this would not be a good idea?-
Arkadiusz Drabczyk over 9 yearsI think there is no fundamental reason for it. It is just the design - do one thing and do it well. It's on old Unix school. Use
mkdir
to create directories,rm
to remove them,mv
to move them. -
YoloTats.com over 9 yearsIt could be just an old Unix convention, which was then standardized by the POSIX standard. Changing it would create incompatibilities in scripts where the old behaviour (fail if target directory does not exists) is expected.
-
ReneFroger almost 6 years@Jofel, it could be alleviated with a flag, like
mv -d
or something else to force create a directory, so the scripts with old behaviour will not be affected.
-
-
derobert over 9 yearsThe comparison to
rename(2)
isn't very convincing, as (at least coreutils's version of)mv
differs a lot—it can move files across devices, it can move multiple files, it can ask first, it can make backups, etc. -
goldilocks over 9 years@derobert Good point. In fact there's a note about this on the POSIX man page for
mv
, under RATIONALE: -
goldilocks over 9 years"The rename() function is able to move directories within the same file system. Some historical versions of mv have been able to move directories, but not to a different file system. The standard developers considered that this was an annoying inconsistency, so this volume of POSIX.1-2008 requires directories to be able to be moved even across file systems. There is no -R option to confirm that moving a directory is actually intended, since such an option was not required for moving directories in historical practice."
-
Gilles 'SO- stop being evil' over 9 yearsThere are plenty of non-standard extensions around. For example GNU
mv
has several backup-related options,-t
,-T
,-u
,-n
, …mv
does quite a bit more thanrename
: it does copy-and-delete whenrename
isn't possible. The only valid argument in your answer is the last paragraph. -
goldilocks over 9 years@Gilles There's only 2 "arguments" in it: The last paragraph, and the one in the first regarding why such an option wouldn't be worthwhile. The rest is just explication of the POSIX man page, which literally and explicitly maps behaviour to rename(). That's not my interpretation, some kind of argument, etc.