Oh but i would like it so much if it did. There would be no need for --dry-run options on commands, and it would be much easier to test command-line software and do exploratory learning.
I think it would be a great usability improvement. Even if it were "only" on a file-system change level. And even if weren't always enabled, like, maybe make it so you have to first "begin" a file-system transaction to be able to roll it back if you don't like the changes you did. Imagine something like:
$ begin-tx
tx$ ./some-script-i-am-not-sure-works-properly
tx$ # Check if everything looks good.
tx$ # In case everything went good:
tx$ Ctrl+D # ...or "commit" to end the transaction.
tx$ # Or, in case i see something went wrong:
tx$ Ctrl+X # ...or "abort" to roll back the changes.
$
(Disclaimer: maybe something like this already exists, is widely supported, and i've just been doing it wrong the whole time.)Strangely, the only command-line software where i feel i can do exploratory learning, instead of always having to resort to the man pages, is git. With git, even if i'm making the most destructive history rewriting with `git filter-branch`, i know that if i screw up i can always run `git reflog` and checkout some ref that i know was OK.
Anyone who's ever fat-fingered an rm command will disagree with you there.
Your comment reeks of some kind of "brogrammer" machismo and it makes me irrationally angry.
By what measure? Cause it sure isn't widespread end user adoption…