There are a few utilities even on the command-line side that will require confirmation (or passing --force or something like that) but it tends to be in cases where you almost certainly don’t want to do what you’re doing.
And there are a very few that just don’t let you do so at all.
rm won’t normally remove a file if you don’t have permissions to do so, though if passed -f, will give you the permissions if you have the authority to do so.
mkfs utilities (“create a new filesystem”) typically require a force flag to overwrite a filesystem that’s in use; normally when that happens, it means that someone’s typed the wrong device file name and is about to blow away the contents of their drive.
fsck, the filesystem checking and repair utility, will refuse to modify a mounted filesystem at all (which normally could be expected to corrupt a filesystem).
That being said, I think that there’s a serious problem on Windows dating back many years where programs throw way too many warnings up, where users constantly encounter confirmation prompts even when they are doing a pretty normal operation and in fact do want to do something. That’s not just annoying. It also trains users to just whack “confirm” anytime something comes up, which makes it impossible for software to meaningfully warn when there is a serious problem.
I’d also add that I kind of think that GUI software would benefit from a standard “confirmation API”. It used to be the norm for software to throw a dialog box up for confirmation. Linux and Adnroid – and I assume Windows and MacOS, but I’m out of date there – have a notification API, where software can tell a notification manager that the user needs to see a message. That’s nice, because then the notification manager can handle the notification in sophisticated ways; do things like text the user the notification, auto-dismiss notifications, filter some out, play a sound, refrain from playing sounds, etc. But AFAIK – and I don’t use a lot of GUI software these days – they still use confirmation dialogs. I’d kind of prefer that they use something like the notification manager, so that one could set up the notification manager to auto-accept certain notifications, log notifications, and so forth. Another annoyance is that most dialog boxes are set up to have Enter and sometimes Space auto-accept. This is obnoxious, because one might be in the process of hitting Enter or Space when interacting with another window; if a confirmation dialog comes up, one can simply immediately inadvertently accept the confirmation. Having the notification manager handle confirmations would help avoid this. I’d personally rather have a dedicated key or key combination to confirm something that’s used only for confirming things, and I’d rather have such confirmations processed in first-in-first-out order. With software throwing dialog boxes up, a confirmation can “jump in front” of another, using last-in-first-out order. Plus, it’d let me have the confirmations auto-accepted.
There are a few utilities even on the command-line side that will require confirmation (or passing
--forceor something like that) but it tends to be in cases where you almost certainly don’t want to do what you’re doing.And there are a very few that just don’t let you do so at all.
rmwon’t normally remove a file if you don’t have permissions to do so, though if passed-f, will give you the permissions if you have the authority to do so.mkfsutilities (“create a new filesystem”) typically require a force flag to overwrite a filesystem that’s in use; normally when that happens, it means that someone’s typed the wrong device file name and is about to blow away the contents of their drive.fsck, the filesystem checking and repair utility, will refuse to modify a mounted filesystem at all (which normally could be expected to corrupt a filesystem).That being said, I think that there’s a serious problem on Windows dating back many years where programs throw way too many warnings up, where users constantly encounter confirmation prompts even when they are doing a pretty normal operation and in fact do want to do something. That’s not just annoying. It also trains users to just whack “confirm” anytime something comes up, which makes it impossible for software to meaningfully warn when there is a serious problem.
I’d also add that I kind of think that GUI software would benefit from a standard “confirmation API”. It used to be the norm for software to throw a dialog box up for confirmation. Linux and Adnroid – and I assume Windows and MacOS, but I’m out of date there – have a notification API, where software can tell a notification manager that the user needs to see a message. That’s nice, because then the notification manager can handle the notification in sophisticated ways; do things like text the user the notification, auto-dismiss notifications, filter some out, play a sound, refrain from playing sounds, etc. But AFAIK – and I don’t use a lot of GUI software these days – they still use confirmation dialogs. I’d kind of prefer that they use something like the notification manager, so that one could set up the notification manager to auto-accept certain notifications, log notifications, and so forth. Another annoyance is that most dialog boxes are set up to have Enter and sometimes Space auto-accept. This is obnoxious, because one might be in the process of hitting Enter or Space when interacting with another window; if a confirmation dialog comes up, one can simply immediately inadvertently accept the confirmation. Having the notification manager handle confirmations would help avoid this. I’d personally rather have a dedicated key or key combination to confirm something that’s used only for confirming things, and I’d rather have such confirmations processed in first-in-first-out order. With software throwing dialog boxes up, a confirmation can “jump in front” of another, using last-in-first-out order. Plus, it’d let me have the confirmations auto-accepted.
You are fucking awesome.