I hate to say it but this is the fault of the Unix philosophy, which favors power users over the novice. It dictates that applications should do exactly what yo

I hate to say it but this is the fault of the Unix philosophy, which favors power users over the novice. It dictates that applications should do exactly what you tell them to. For example, using the `install` subcommand of a package manager should not update your packages, but rather that should only be done by the `update` subcommand. Of course you could put in an `if` statement that checks if the package is already installed, and instead it will update it for you. (Not the best example but bear with me) The problem with this is that it breaks expectations; no longer do flags/commands do exactly what the name says, but each will have their own side effects; subtree of commands that are called that you might have to figure out. (Or maybe not if it is well-documented, like how `git pull` calls `git fetch` and then `git merge`) This is antithetical to scripting purposes and completely controlling your own experience. Instead you have to work around the well-meaning one size fits all experience proffered by the developer. Unix tools hate state because commands are meant to be chained together anew each time. They also hate interactive sessions for that reason since it forces people to walk through repetitive steps even when they might already know what they want. What else can you do at that point but offer configuration options? Maybe a possible solution comes from git again: architect your application as a low-level API and include a higher-level implementation. This worked out beautifully in my opinion, with anyone needing to dig into the internals using the plumbing, and the majority of the end users, the porcelain. This comes with its own drawbacks such as the oft-complaint that git uses leaky abstractions and its not always clear how a command modifies the internal state, as well as inconsistent flags. (Note: this is coming from someone who read "Do one thing and do it well" and made it his mantra, not realizing that only robots want to do one thing at a time as in an assembly line; the rest of us want a complete experience)