4 ms·

The Unix shell, one of the most successful user interfaces ever developed, doesn't support undo nor does it need to. It's successful because it doesn't presume

The Unix shell, one of the most successful user interfaces ever developed, doesn't support undo nor does it need to. It's successful because it doesn't presume to know better than the user.

kalleboo 11y ago
> doesn't support undo nor does it need to 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.
reubenmorais 11y ago
> The Unix shell, one of the most successful user interfaces ever developed By what measure? Cause it sure isn't widespread end user adoption…
epidemian 11y ago
> The Unix shell doesn't support undo 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.
- gizmo686 11y ago
  You would need to implement this at the file-system level. You should be able to do this easily with any file-system that supports snapshotting, such as btrfs.
  - anon4 11y ago
    I don't think it's that easy and I do think the parent has a point. I mean, while you're busy writing a perl one-liner to munge on your file, ten daemons are writing to their log files, all on the same file system. You want to roll back the effects of your script doing an accidental rm ~/*, but not what's in the logs. Probably a better idea is to strace the shell's children and record changes, then apply or forget them.

The Unix shell, one of the most successful user interfaces ever developed, doesn't support undo nor does it need to. It's successful because it doesn't presume to know better than the user.

kalleboo 11y ago

> doesn't support undo nor does it need to 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.

reubenmorais 11y ago

> The Unix shell, one of the most successful user interfaces ever developed By what measure? Cause it sure isn't widespread end user adoption…

epidemian 11y ago

> The Unix shell doesn't support undo 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.

gizmo686 11y ago
You would need to implement this at the file-system level. You should be able to do this easily with any file-system that supports snapshotting, such as btrfs.
- anon4 11y ago
  I don't think it's that easy and I do think the parent has a point. I mean, while you're busy writing a perl one-liner to munge on your file, ten daemons are writing to their log files, all on the same file system. You want to roll back the effects of your script doing an accidental rm ~/*, but not what's in the logs. Probably a better idea is to strace the shell's children and record changes, then apply or forget them.