3

One thing that always bugged me:

touch a
rm a

ok, it works as expected

mkdir a
rm a

will require -r to work; but I don't understand what is recursive in this? if the folder is empty, there is nothing recursive about it. I would expect rm a to try to remove a, and fail if it's not empty and rm -r to recursively the contents of a.

why is is this like that?

Edit: this question has been flagged as a duplicate of a totally irrelevant question. My question can be summed as: Why do I need a recursive flag to perform a non recursive operation: mkdir a, rm -r a has nothing recursive about it. And this is not related to the other question which is about why rm is not recursive by default.

Christopher
  • 15,911
Thomas
  • 207
  • 4
    You might be looking for rmdir. – Ulrich Schwarz Nov 07 '19 at 13:42
  • 2
  • 2
    @muru: it's not the question. I am asking why we need a recursive flag to do a non recursive operation. – Thomas Nov 07 '19 at 13:55
  • Uh, you have to recurse into the directory to know that it's empty in the first place. Remember that deleting something is an operation on the parent directory, not on the thing itself. The parent directory can't tell you whether the target directory is empty. – muru Nov 07 '19 at 14:04
  • I upvoted just because I don't feel this question deserves so much hate. However this question is almost as arbitrary as "why does the universe exist?" There is no problem you are trying to solve here, and not even any real knowledge you are trying to acquire. You simply want us to speculate why someone else did something that simply seems obvious to most people. – jesse_b Nov 07 '19 at 14:04
  • @muru: that would be the first node, so no recursion would be required. – Thomas Nov 07 '19 at 14:07
  • @Jesse_b: I asked this question because I'm curious about the original logic behind it. I understand that a lot of commands' parameters arise from historical situations but since I find it a mis-use of the recursive flag to require it, I am curious if there was a specific reason why this was designed like that. – Thomas Nov 07 '19 at 14:09
  • @Thomas the action is on the 0th node, so checking the 1st node would be recursion. – muru Nov 07 '19 at 14:13
  • 1
    @Thomas rm is one of the basic commands and they usually also strive for speed. Declining removal for a directory in non-recursive mode is quicker than checking if a directory had entries for every option. Also the general behavior would be IMHO less straight forward -> rm * == removes all files and directories but only if they are empty vs. rm * == removes all files and files only – FelixJN Nov 07 '19 at 14:16
  • 1
    @Fiximan: Unless you have a file in your directory named -r :p – jesse_b Nov 07 '19 at 14:21

2 Answers2

7

This is because rm was never meant to delete directories at all.

Originally rm didn't support -r and users had only 1 option: To delete all files in a dir with rm and after that to remove (the now empty) dir with rmdir

Obviously working like this is very annoying so -r was implemented to fix this problem.

But if rm /some/empty/dir would start working than it would no longer be backwards compatible (so it could break old code that assumed that rm /some/empty/dir fails). With -r this isn't a problem because this behaviour wasn't defined yet (because the -r option didn't exist yet)

Garo
  • 2,059
  • 11
  • 16
3

From man rm:

By default, rm does not remove directories. Use the --recursive (-r or -R) option to remove each listed directory, too, along with all of its contents.

I'll take a guess here: It's a safety feature that you do not delete directories with files in there without realizing. I assume rm would not check if a directory had content in first place (in contrast to rmdir).


EDIT: I assume without recursively deleting files, there would be a problem in terms of finding a file as the names and inodes are stored in the directory. Deleting the directory would create "zombie"-files with inodes but no filename. Compare to this post on EXT structures.

FelixJN
  • 13,566