Caveat: Accept STDIN somewhat counter to Empathetic CLI

[jasonkarns]

As a counterpoint to the suggestion with 'empathetic CLIs', having a CLI that may suddenly block for STDIN is not friendly or empathetic. It does not account for an invocation that be run un-attended (ie on a build server, or scheduled cron job). Indeed, I would go so far as to say that any single CLI command should always be interactive or never be interactive; not sometimes.

It's also worth noting that an invocation that has STDOUT piped to its STDIN will start consuming that STDIN as if from the user if it attempts to switch to interactive mode based on some ambiguity. That is almost certainly not what the author nor user wants.

[lirantal]

@jasonkarns agree that we need more clarity there.
How about that we add a new item in the Interoperability section about detecting whether an interactive session is relevant or not and disabling interaction otherwise? for example when it is running inside a CI. Would you like to take that one to add?

Good points and description for that exist here https://clig.dev/#interactivity that we can borrow and embed in the guidelines here.

P.S. I also like the password no-reveal rule there that we should add as probably a new section of Security. Another item that can go into that security section is the following Allow sensitive argument values to be passed in via files. from the Arguments clause on clig.dev with regards to accepting STDIN to not reveal a password in the process list from flags.