As cool as this is, it shouldn’t be necessary. A proper undo turns every command into the equivalent of a “try”, allowing users to experiment without fear of data loss. Everything in a computer user interface should be undoable.
This has been known for over 40 years, but the industry has been very slow to get the memo. The undo implementation on the iPhone is a weird joke. CLIs have barely even tried (with a few exceptions like Jef Raskin’s Canon Cat, a textual UI completely different from anything else I’ve ever seen).
To quote Tom Lehrer, "I am never forget the day..." [1]
I was working with WinXP, trying to reconfigure a machine's network for something abstruse. I was making changes in the network configuration dialog, and kept tentatively moving forward because there was always the "CANCEL" button available to revert my changes.
I made one last change, and suddenly the "CANCEL" button dimmed. It was as if you were creeping into the entranceway of a haunted castle, and after one more step the door slams shut behind you.
DO NOT RUN THAT or risk breaking Computer Fraud and Abuse Act! It sends a 'reverse ping' from Google to you, and it effectively hacks their server to initiate it.
Hah, clearly you have no idea of what you are talking! In order to ascertain the general level of humor of a programmer, you would have to assume all programmers are equivalent! Furthermore you would be assuming that there is one kind of humor, which is clearly a fallacy. Finally, the amount of "terribleness" you allude to cannot be quantified in such a way as to distinguish an objective level of quality. Therefore you are clearly wrong! Try doing some research before you share such a naive opinion in the future.
Agree in principle, but I'm not sure if it's possible to implement Undo for all shell operations. But there's a lot of existing systems out there, and anything which can be adopted incrementally is a big win.
Another shell variation I like is using trash rather than rm.
I agree that there should be universal undo, but I think by contrast the (informally) transactionality of the "try" model can be a big deal if your system is concurrent.
If you do a thing, find out it isn't what you wanted, and then undo it, while at the same some other process is observing the mutated state, that's potentially a much trickier mental model. If you undo a configuration change and in the meantime a background process has acted on the new configuration, how do you roll that back? Rewinding the timeline is one thing, but maybe throwing out all the work that happened with the wrong configuration is even worse than the status quo.
From the top of my head I am thinking about accidentally changing retention windows or bash history max size where the data loss is super indirect and you'd have to hunt down the undo button for a completely different process, or changing a log format so you end up with a file that's mixed json and plain text logs.
(Of course, "try" presumably applying the changes in a completely synthetic way after the fact could be its entire own can of worms in a very dynamic system if there's a risk changes are applied in the wrong order or skipping some atomicity dance.)
Fully agreed on this. The simple, default way of doing anything should be able to be undone. Hell, years ago Google even figured out how to give people an undo button on email! Yes, it's just a simple time delay but it makes such a huge difference because of how your state of mind changes between typing an email and hitting send. Or hell, maybe you just accidentally hit the send button.
Undo allows you to make the default behavior for every operation to be to just go and do it (or queue it up to be done). No need to have a confirmation that the user is going to quickly become conditioned to pressing yes on while also being just an annoyance 99% of the time.
We should also build a space elevator and figure out nuclear fusion. Unfortunately, many good ideas are easy to describe but difficult/impossible to do.
Sorry, I don't want a transactional layer to accompany every interaction I have with my Linux system (or most other systems, for that matter).
I want to choose when I need undo/redo and when I don't; a perpetually present transactional layer is just cruft for most of the time.
Furthermore, it opens up basic system interaction to the same fundamental questions that in-app undo systems have: do you branch? how deep is the history? how persistent is the history? etc.
a journaling file system is not the same as creating rollback points for every shell command prompt + enter.
also, if you're going to be strict about it, a true undo would need to handle modifications to anything in the /proc or /sys or /dev "filesystems", which are not covered by journaling-anything.
You can implement such a system-wide undo with filesystem snapshots using LVM2 or btrfs (or with backup/restore).
However, you also need to properly isolate software in containers or VMs since of course doing a system-wide undo on a system that is running a server will also revert the server state, which is usually disastrous.
This has been known for over 40 years, but the industry has been very slow to get the memo. The undo implementation on the iPhone is a weird joke. CLIs have barely even tried (with a few exceptions like Jef Raskin’s Canon Cat, a textual UI completely different from anything else I’ve ever seen).
Maybe one day…