Hidden CLI options

[ollehellman]

Hi,

Really nice piece of software, works great. I have been looking for something like this for quite a while.

I wonder if there is a way, ugly or pretty, to have a CLI argument not listed in the help? I use "secret" arguments for debugging/testing, and I want to keep my users from trying to use them, since it will only lead to confusion.

I added an option --print_manpage that ensures that

call cli%save_man_page('program_name.1') stop

runs. This is neat, since I can run this compile-time and keep the manpages updated. However, I don't like that it's stated as an option: there is no need for anyone but me to know that this option exist, and it's pointless for the user to run it again.

I guess my question is how difficult would this be to implement? I read through parts of the code, but I could not really figure out a good way of doing it. The way I do it right now is that I hide it in another option. i.e. I have the option --number_of_things, and if I set that to -1, it prints the manpage. This is not a pretty solution.

Regards, Olle

[szaghi]

Dear @ollehellman you are welcome.

I wonder if there is a way, ugly or pretty, to have a CLI argument not listed in the help? I use "secret" arguments for debugging/testing, and I want to keep my users from trying to use them, since it will only lead to confusion.

Sure, there is already such a (pretty) feature, see this.

You can do something like:

use Data_Type_Command_Line_Interface, only : Type_Command_Line_Interface
type(Type_Command_Line_Interface) :: cli

call cli%add(switch='--print_manpage', hidden=.true., ....)

Passing hidden=.true. will prevent --print_manpage to be listed into the help/usage.

Such a feature is already used by default, e.g. if you pass -- at the end of the named arguments they are collected, see this

Unluckily, the FLAP documentation is not up-to-the-date with the code (so wiki could not report all the current features, :cry: ).

A note of caution

I am refactoring this code right now: probably later this day I will push a new release that breaks backward compatibility, i.e. the API is changed. I have sanitized the code in order to (hopefully) make it more maintainable and easy to improve. For the user there are two important changes:

• Type_Command_Line_Interface type becomes command_line_interface;
• Data_Type_Command_Line_Interface module becomes flap;
• all the rest of the API is unchanged;

So your above example will become (with the incoming version) something like:

use flap, only : command_line_interface
type(command_line_interface) :: cli

call cli%add(switch='--print_manpage', hidden=.true., ....)

For the developers (currently I think I am alone, there are some forks, but I have not yet received any pull requests) the are other changes, e.g. the library has been subdivided into multiple modules.

Let me know if this respond to your issue.

See you soon.

[szaghi]

@ollehellman

Just another suggestion: in general, due to my laziness, wiki is not so up-to-date, however the API documentation is always up-to-date (just because I write API doc before the code...), so if you see the cli%add API documentation you will see all the current features, included the hidden option.

[szaghi]

@ollehellman

The new version v1.0.0 is out... as said it is NOT backward compatible.

See you soon.

[ollehellman]

Got the new version, everything works great. Thanks!

Cosmetic thing though, in the help output, you get a blank line for every hidden option:

--thirdorder default value .false. Use third order force constants to calculate mode Gruneisen parameters.

--help, -h Print this help message --version, -v Print version

That is, between the last "real" option and the automatically added, there are two blank lines, corresponding to my two hidden options. I fixed it by changing

if (self%cla(a)%is_required)

to

if (self%cla(a)%is_required.and..not.self%cla(a)%is_hidden)

and the same thing for the optional arguments in the 'usage' function, in 'flap_command_line_arguments_group_t.f90'. I can't tell if I broke something by doing this.

[szaghi]

@ollehellman

Oh, thank you very much fof pointing out this lack. Your solution looks good to me, tomorrow I will add this patch when fixing the other bug you found.

Thank you again!

[szaghi]

This should be fixed in the new v1.0.2, see comment in issue #58 .

See you soon.