Post History

I largely agree with existing answers, but wanted to add this:

In many cases, there is no clear answer one way or the other. Take the program `wc` which counts characters and lines. Should the interface be `wc file.txt` or `cat file.txt | wc`? Compelling arguments can be made for the value of either. Yet we have to pick one.

Actually we don't. `wc` supports both. More complex programs support the well known `-` parameter, so `cat file.txt | some_program --file -` as a way of making it a bit more coherent.

Interactive input falls under this as well. `ssh-keygen` will interactively ask for the key type. But with `ssh-keygen -t ed25519` it will not ask.

CLI arguments, standard input (from pipe) and interactive input form the three pillars of Unix-style human-computer interaction. All programs should aspire to provide first-class support for all three *eventually*, even if they won't, just like "all kids" aspire to be astronauts. Imagine a stool with two legs. You can make it work, and it's certainly better than a stool with one leg, and way better than none, but once you get to three legs it gets really good.

Of course you have to start somewhere. For your first leg, just pick one. Whatever you feel is **a** likely use case for your script, and let users rely on Unix to "improvise" the missing legs:

* `cat` if they want to use args but you support stdin
* Shell redirection if they want stdin but you want args
* `expect` if you support interactive but they want scriptable

As your program matures, you can use the experience gained from maintaining it to decide which next method of input you should add support for.