A pattern I like for CLIs is that by default each command runs in dry-run mode, and only with `--commit` is it allowed to do dangerous things. Kind of like `git clean` vs `git clean --force`, except that `--force` feels like bad names for the distinction. Likewise, `--dry-run` implies that the command does the dangerous thing by default, which is bad. `--commit` gets the balance right, it sounds right, and it's sufficiently self-explanatory.

(Oh, and there's no shorthand, like `-c`. It's `--commit` or bust.)

It also in the case of an LLM can bias it towards using that sort of flag more commonly, which is less than ideal when it then uses a more ordinary Unix command that uses that to mean something dangerous.

CLIs should check isatty and, if it returns false, disable any interactive functionality because it won’t work.

Please don't do that, expect has to die.

I don’t mean that expect should be used. But flags like —no-interactive are unnecessary. CLIs can just check `isatty == false` instead of requiring an explicit flag.

I'm all about the "-ForceDoTheDangerousThing" when I'm making tools (most of my shell scripting is pwsh).

The naked "-Force" has always been a mistake on even minimally complex tools.

`--non-interactive` has precedent too.