Hacker News Reader

Comment by wolttam | Hacker News Reader

Getting agents used to using `--force` to bypass prompts seems like a bad idea. `--force` is for when the action failed (or would fail) for some reason and you want it to definitely happen this time.

I think `--yes` or `--yes-do-the-dangerous-thing` is leagues better.

View on HN

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.

Reply on news.ycombinator.com