-
Notifications
You must be signed in to change notification settings - Fork 19
Interactive flag should be present for options too #55
Whether a command is interactive is currently modelled at the OpenCLI document and Command (also subcommand) levels. It is worth noting that there are examples where options can set interactive mode too, such as docker:
docker run -it <image>
Note the -I here represents interactive mode for docker, which might not be entirely mappable to the same concept in OpenCLI. There is also -t that requests that a (pseudo) tty is allocated, which could be a better fit.
There's also the -t and -T options to turn on/off interactive tty for ssh: https://man7.org/linux/man-pages/man1/ssh.1.html
Claude has a -p to force interactivity off and into a "prompt" mode.
In either case, it's possible that the interactivity of a command line should flow down into options like these to flip in/out of interactive mode.
All reactions
Replies: 1 comment 4 replies
Would it suffice with Option Object having an interactive flag?
All reactions
Yes, I think that should work.
I would change the interactive flags on Command and Option into three states instead of having a default value for them. The document-level one can still have the default set to false as it is now. I think that this might be truly the default for most commands out there.
Then the interactivity flows from left-to right through a command-line. The document sets the initial value (default is false), and then commands can override the initial value.
[docker] [run] [-I] [-t int:true] -> interactive is ON
[ssh int:true] [-T int:false] [user@example.com] -> interactive is OFF
[claude int:true] [-p int:false] -> interactive is OFF
There might be an argument for having a fourth state for the document's interactive property, which is whether or not the command is invoked in an interactive terminal session to start. But, I wonder if simpler and more explicit is better for now and the added state can be added in the future.
All reactions
Ah, I understand. That means we need to define this as an enum (with three values) instead of a boolean option. I hadn't thought of that scenario.
The big question is what those three values should be called. Any suggestions?
All reactions
I feel that JSON has a natural unset state represented in JSON schema as a property that isn't in the list of required properties. This can be used to represent the three states: interactive true, interactive false, and unset (no effect).
All reactions
Yeah, but that would clash with other values that we have default values for if missing. Would prefer to be explicit here.