Optional interactive

[Zethson]

Hi,

I'm having the following issue:
I have a password CommandLine.Option, which is currently interactive -> thus it asks the user for his password.
However, I would like to skip the interactive question, if a password was already provided.

Is it possible to consume the interactive request?

[remkop]

@Zethson At the moment picocli does not support this. There is a section in the manual about combining interactive use with non-interactive use.

Basically, if you need this, one idea is to have separate options, like --password:hidden for the interactive option, and --password:clear that accepts the password in cleartext as an option parameter on the command line. For batch scripts it may be more secure to ask the user to specify a file or environment variable that holds the password.

[Zethson]

I see, thanks!
I still would like to kindly request this feature.

It's more or less the only thing that I miss from Click .

[remkop]

Understood. Not sure when I'll get to it.
I'm a bit worried about introducing ambiguity, for example:

class App {
    @Option(names = "--password", interactive = true)
    String password;

    @Parameters
    String[] otherParams;
}

Now, if the end user specifies some input:

<command> --password aaa bbb ccc

Currently picocli will interactively ask for a password and put aaa, bbb and ccc in the otherParameters array.

This will change after this feature request is implemented: for the same input, the aaa parameter will now be interpreted as a password parameter value. Not sure yet how to deal with this...

[Zethson]

What Click does is that every parameter that was not passed and labeled as interactive is prompted. Everything that was passed is not going to be prompted.
--password aaa bbb ccc
is going to set aaa as value for password

aaa bbb ccc
will open the interactive prompt and ask for the password, since no value for password was passed.

[remkop]

I guess I will either have to live with potentially breaking existing applications, or introduce some extra flag that needs to be set for picocli to accept values following --password as the password value.

[Zethson]

I'm afraid yes.

I prefer the potentially breaking change, but this is of course up to you.

Thanks!

[remkop]

JCommander actually implemented this feature request:

• Password option behaviour is unintuitive and inflexible cbeust/jcommander#70
• Don't prompt for password if it was passed as argument cbeust/jcommander#195
• Password read from standard input only when not already provided cbeust/jcommander#333

But that caused an issue in certain use cases (application did not want to allow users to specify the password in plain text as an option parameter):

• Add option for not allowing password to be entered on command line  cbeust/jcommander#452

One possible solution for this last use case is to use arity to control whether option parameters are allowed: by default the arity for an interactive = true argument would be 0..1, meaning end user may specify it as an option parameter, or may omit it and get prompted on the command line.

If the application author defines the option with arity = "0", picocli would not allow end users to specify it as an option parameter and always prompt for a value on the console.

[remkop]

@Zethson, it took a while, but this has finally been implemented. By default, interactive options now have arity = "0" (meaning they won’t consume any command line arguments but prompt the user for input instead), but if the option is defined with arity = "0..1", it may optionally consume a parameter from the command line arguments.

I’ll release 3.9.6 with this change soon.

[Zethson]

Amazing. Thank you for your hard work.