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 of mv? Is there some fundamental reason due to which this would not be a good idea?
1 Answer
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).
answered Mar 10, 2015 at 13:17
-
The comparison to
rename(2)isn't very convincing, as (at least coreutils's version of)mvdiffers a lot—it can move files across devices, it can move multiple files, it can ask first, it can make backups, etc.– derobertMar 10, 2015 at 13:27 -
@derobert Good point. In fact there's a note about this on the POSIX man page for
mv, under RATIONALE: Mar 10, 2015 at 13:54 -
"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." Mar 10, 2015 at 13:54
-
There are plenty of non-standard extensions around. For example GNU
mvhas several backup-related options,-t,-T,-u,-n, …mvdoes quite a bit more thanrename: it does copy-and-delete whenrenameisn't possible. The only valid argument in your answer is the last paragraph. Mar 10, 2015 at 23:13 -
1@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. Mar 11, 2015 at 8:04
mkdirto create directories,rmto remove them,mvto move them.mv -dor something else to force create a directory, so the scripts with old behaviour will not be affected.