Why do tools like cp and rm treat directories separately from regular files? They both require the user to explicitly specify she wants a recursive behavior, or else they won't deal with directories at all.
My first interaction (a while back) with computers was on a Windows/GUI/point-and-click/drag-and-drop environment, it always seemed natural that these operations would behave the same, regardless of the target.
This behavior particularly frustrates me when I give commands with wildcards. What if I want to remove everything in a directory (*) except for non-empty subdirs?
I can only imagine that this is some sort of security feature to prevent the user from shooting herself in the foot, but this contradicts my understanding of a few Unix principles:
- Unix doesn't usually protect the user from herself. It has always assumed the user knows what she's doing.
- For Unix everything is a file. Isn't a directory just another file? Why are they treated differently?
My questions:
- Is this behavior stemming from a technical limitation or is it a deliberate choice?
And in case of the latter,
- are there any historical accounts of the reasons which motivated this choice?
Best Answer
Derobert's Why unix mv program doesn't need -R (recursive) option for directories but cp does need it? basically answers your question: copying or removing a regular file is different from doing the same operation with a directory, because for a directory you have to process all the files contained therein. Hence the operation is fundamentally different.
Also worth noting is that there is a special utility
rmdirwhich can only act on empty directories. Without checking the facts this leads one to conclude that maybe originallyrmwas only able to remove non-directories and deep remove had to be achieved by recursively usingrmto empty directories and thenrmdirto remove those.