I would speculate that it is a historical reason. It's no secret that the Unix environment was not designed for personal use in homes, but on mainframe time shared computers inside universities and businesses. Space was limited, and just moving files to another location to deal with later added unnecessary steps to a process that didn't have much of a benefit, at the time.

As space has become less valuable on computers, and they have become less of a specialized tool, it may be wise to add one, but most of the desktop environments already implement it already so there is no need to recreate the functionality at a lower level.

> Once in a while when the recycling bin gets too big, the user can empty it.

Many Linux systems don't even have a regular "user". They just sit in a corner and serve webpages, or do other tasks silently.

> Or you can have a scheduled operation that deletes stuff after 30 days.

Why not just keep backups for 30 days?

You're operating at a layer below where a trash can makes sense. Pretend that this command had moved everything to a trash can. The command to move the files out of the trash can now resides in the trash can, where it isn't being very useful. It's still possible to recover the files, but then again, it's also still possible to recover the files you deleted with rm.

rm is on the same layer as the DOS del command. Neither goes to the trash can, because they operate on a lower level.

If you want a recycling bin don't use rm, use mv.

Because that's not what rm does. Changing it would be breaking all sorts of standards. Many, many things depend on rm simply unlinking files. Why don't you use a different program if you would like to have some sort of trashbin behavior?

Good question. Here's my 60 second solution. <:)

  alias rmmmmmmmmmmmmmmmmmmmmmm='rm -i'
  rm() { D="~/.Trash/`date +%s.%N`"; mkdir -p $D; mv "$@" $D; }