Please don't. There is nothing wrong with interactive tools, but by default, they should not be. So instead of making non-interactive session possible via flags, the default should be to be non-interactive. If there is an option to start an interactive session, everything is fine.
Otherwise, you would never know when your script could run into some kind of interactive session (and therefore break; possibly after an update).
My interpretation was that the prompt is for required information. In the example graphic, "run demo" really does require that "stage" be specified. This is considered more user-friendly than simply crashing. If you don't want to see the prompt, provide that information as a flag or in a config file or whatever.
> This is considered more user-friendly than simply crashing
(I'm going to assume the passive voice means "the article considers this more user-friendly" rather than some sort of commonly accepted fact).
I disagree with this strongly and agree with the GP -- I would much rather have the command exit with a message saying that a required parameter is missing. For example, if I have a script using a command and the command becomes interactive, then my script is dead; but if it simply exits then my script has failed at a repeatable point.
You could say that I should pass a "--noninteractive" flag into everything just in case, but sometimes these things aren't supported. I would much rather have an application support a "--interactive" flag to support those who want to be able to interact with the tool.
I think the two sides of this are unlikely to be able to convince each other. At least the article presents a reasonable-ish middle ground of always offering help as to the way to circumvent the interaction at the point where interaction is required.
So you want the script to [EDIT:] exit with an error code rather than hanging around waiting for input? That seems possible, with some sort of generous (e.g. 5 minutes) exit timer on the prompt. Would that satisfy your concerns? If not, what else is needed here?
ps. the verb "considered" is a good sign that this is an opinion, and would be even in a more "active" sentence.
First of all I think "crash" is the wrong word here. Unix tools commonly exit gracefully with an error code when the argument requirements are not met. Often with an informative error message.
A five minute pause sounds ridiculous to me, absolutely not user friendly from either end. It's jus unpredictable and time wasting. If you absolutely must, you can use 'isatty' to check whether stdin/stdout/stderr are connected to a terminal and act accordingly.
There is some merit to having consistent and predictable behavior regardless of where and by whom the tool is invoked, though.
This is how Powershell treats mandatory arguments. Provide args via flag/position or be prompted for input. You can always break out with Ctrl+C if you'd rather modify the command.
The one thing missing from the example is a little more contextual help. Not only should it prompt you for the stage, it should say “use --stage [development|staging|production] on the command line to skip this prompt” or some such. (Could be as terse as the prompt reading “please specify --stage”.)
Like for the confirmation example? I agree. It would help clear this up. The points people are raising here with prompting are definitely not issues, they're just misunderstanding my point.
Well, this is not a cronjob that failed, it's just waiting for input.
Let's say that I did test the cronjob but that it starts "failing" after an update to the tool. My fault, I know, but at least I get mail when it fails while I won't if it's just waiting for input.
This scenario would only happen if a flag became required. Prompting or not it would still be an issue. (And it wouldn't prompt as this is a non-tty environment)
Yes, but in one case the issue would result in a mail because the cron job failed, and in the other case the issue would just cause the the process to hang indefinitely without notice
I think detecting whether stdin is a TTY is a huge antipattern. Most of the time, it works, but now and then, you either want to run an interactive session in a situation where stdin appears not to be a TTY, or a batch session in a situation where it appears to be. Plus, it means there's twice as much surface area to learn.
> you either want to run an interactive session in a situation where stdin appears not to be a TTY
Um... why? That is literally the situation for which the pseudotty device was created.
There is a spectrum between "interactive" and "scripted" utilities, and the command line interfaces we're talking about sit balanced on the interface. There's no way to make everyone happy, more or less by definition. So I think "huge antipattern" is maybe spinning a bit too hard.
You get false positives sometimes (where it claims to not be a tty but is going to the screen), but because the fall back is just reduced functionality it never causes any issues. We make hundreds of checks like this for tty in the CLI
Please don't. There is nothing wrong with interactive tools, but by default, they should not be. So instead of making non-interactive session possible via flags, the default should be to be non-interactive. If there is an option to start an interactive session, everything is fine.
Otherwise, you would never know when your script could run into some kind of interactive session (and therefore break; possibly after an update).