attribute to require interactive terminal

[robjtede]

I've made a PoC for configurations attributes: [interactive] and [not-interactive] which can enable/disable recipes based on the equivalent of [ -t 1 ] in bash.

I've come across a sitation where I want to run slightly different commands in either situation but switching the recipe to use bash makes it kinda ugly. This may also help in a situation where an agent is selecting a recipe to not getting stuck in a TUI, for example.

Here's the diff: master...robjtede:just:interactive-attribute

Not sure what you think about adding this as a configuation attribute, given the only others of those are the OS selection ones. Didn't take much time to write up so if you're opposed in general no harm done. Otherwise, I can get that diff in a better state and submit a PR.

[casey]

Thanks for the issue! I don't hate this, although it seems very niche. Can I ask what the different commands are you're running in both cases?

[hrumhurum]

My 2 cents: the proposed functionality is not so niche as it might look from the first sight.

A use case I've encountered in real projects: performing a potentially dangerous operation that requires a user confirmation. However, if the recipe runs in a non-interactive mode then the confirmation breaks the script.

[robjtede]

Much the same here w.r.t. requiring certain inputs (useful to change required arguments on the recipe itself) when in non-interactive mode. It's true some scripts do already detect [-t 1] and prompt for input for missing args, but some other prebuilt CLI tools and scripts do not, and this proposed selection method gives us control of both.

My other one which was a bit ugly to work around was doing a clipboard copy (macOS cmd | pbcopy) for reducing output in interactive mode vs just printing the output.