>Windows gets this right: By default, files are not deleted, but moved to trash.

The del or Remove-Item commands also permanently delete the file, just like rm. The "Windows" behavior you're talking about is the behavior of the graphical shell Explorer, which is also present in Gnome and KDE. There's nothing specific to Windows here.

  apt install trash-cli
  alias rm=trash

Done? This implements the Freedesktop specification, so is compatible with what KDE and Gnome do.

https://github.com/andreafrancia/trash-cli

You are right, I forgot about Gnome and KDE. I tend to use classic shells on Linux, and the graphical shell on Windows, so I made a wrong generalization. It's probably more accurate to say that "undo" of simple operations (rm, mv) is something graphical shells get right.

But why are classic shells shipped without even the simplest "undo" features? We can probably all tell stories-from-the-trenches of how we accidentally did something aweful by typing the wrong command. Sometimes, it's hosing the network configuration of a remote machine, which is not something where "undo" would help you. However, in my experience, most cases involve doing something foolish with rm or mv, where "undo" would be tremendously helpful. I guess the main reason why I don't use the text shells of Windows is that Windows explorer gives me Ctrl+Z, which is saving my behind approximately once per year.

As a final thought, all shells (graphical or not) should expand the undo-features beyond rm and mv. For example, if I change system settings (or even Application settings?) and am not happy, I would love to be able to simply "undo" them, without trying to remember what the previous setting was. I realize that this is an incredibly hard problem, and that it is unlikely to be solved in an evolutionary step of the existing shells. That's why hearing about NGS got me so excited.

> But why are classic shells shipped without even the simplest "undo" features?

This question is assuming an untrue premise. There are Windows command interpreters that integrate DEL and RD with the Recycle Bin.

* https://jpsoft.com./help/del.htm#r

* https://jpsoft.com./help/del.htm#k

* https://jpsoft.com./help/rd.htm#r

* https://jpsoft.com./help/rd.htm#k

That said, i'd like a "del to recycle bin" in Windows too.

Then get yourself off to https://jpsoft.com/ , set the Delete To Recycle Bin option on in the configuration tool (https://jpsoft.com./help/inistartupdlg.htm), and enjoy exactly that. (-:

Back in the 90s (IIRC) someone wrote a kernel module for linux that provided the equivalent of a GUI "trash can/recycling bin" but at the filesystem level, where a specific directory (folder for you young 'uns) was set aside for the deleted files. Because it was a kernel module (filesystem driver) it was transparent to applications, including the shell.

lost+found? it's still there in each file system but i never see a real usage for it.

I believe that's less an everyday-use "trashcan" and more of an ext* feature for recovering from filesystem corruption; "Something broke and I think I've recovered all the files, but I've forgotten where some of them were supposed to go".

Although I kind of agree with you, I'll play the devil's-advocate: If you actually care about the file, it should have a backup that you can restore from anyway. And, depending on the file, that backup should be source-control.

If the solution to the problem relies on human beings being fully-informed, entirely competent, and never making mistakes-- it's not a very good solution, IMO.

Yes, people should maintain backups. But if people don't, for whatever reason (maybe they've never heard the word "backup" before; maybe they typed the wrong command and thought they had backups all along, etc.) shouldn't be screwed if something goes wrong.

Backups are good. More frequent backups are even better.

I have btrfs snapshots run on the fileservers at 10 minute intervals. Which, of course, captures the entire filesystem state, not just files that you have deleted by accident.

I know you're playing devil's advocate, but that attitude is making the perfect the enemy of the good. Backups are non-trivial enough that many people don't set them up correctly if at all; and even if they do, a restore can take some work. I think it's perfectly reasonable to have relatively painless alternative (e.g. "undo_rm") as an extra layer of safety.

I bet you could solve this with ZFS and automatic snapshot creation for each new command. Want to undo the past N commands? Roll back to a previous snapshot!

And a policy mechanism that lets you define how important a directory (or file) is and how hard the system will work (eg removing less-important data to free up space) to save this.

This idea falls over if the amount of data you create (which the shell can't know in advance) is too big to contain in a snapshot. All that would be possible is an automatic notification that the operations in XYZ directory are no longer undoable due to its size.

On the flip side, you can have multiple filesystem entries (via hard links) to the same set of files and set up your own playground directory while keeping a mirror view of the same directory. Remove a file from dir A, and it's still in dir B. Once you're satisfied with the result, you can delete the entire dir B. Accidentally removed a file from A? Restore it from B by making another hard link. (Caveat: hard links don't work with directories unless you're Apple TimeMachine)

It would require the programs to explicitly describe their actions to the shell and by default behaving in a reversible manner. That would allow you to single out effects you dislike, and tell it to undo it.

Kind of like making the shell behave in relation to your OS as an editor/IDE + version control system, rather than just as an editor/IDE. Old versions are preserved until you purge them.

Or perhaps it would just simulate state changing actions by default, waiting to be told to execute them.

If I haven't misread, you're proposing a replacement to rm that has support for undo? Why not just make a shell script that uses mv to place the item in, say, ~/.deleted and drop it in your PATH?