Setting or function to prohibit process termination

[Drakulix]

I would like to use clap's easy syntax for different stages in my program then just command line argument parsing. E.g. to parse remote commands with arguments read from sockets. I can already utilize clap using get_matches_from. But even get_matches_from_safe terminates my program when --help or --version gets passed to. I would like to have either an even safer _safe method or an app-setting, that completely blocks any terminate inside the clap crate and some kind of indication, if parsing did succeed or it should have terminated.

Would that be possible?

Best regards,
Drakulix

[kbknapp]

This is possible, we'll have to look at the best naming and such in order to implement. The work-around is simple, but somewhat hacky at the moment.

Simply define your own --help and --version flags as part of your valid arguments. If you provide a flag with the long of help or version then clap will not auto-generate those and leave the implementation up to you (i.e. you decide whether to terminate or not, and what should be done).

The same applies to subcommands with the name of help.

Hope this answers your question. We'll update this issue as decisions are made and discussed about adding a "safer" safe 😄

[Drakulix]

Thanks for looking into this. That workaround will probably be enough for the moment.

[kbknapp]

One other thing to note (although I haven't tested it) is also setting the help and version flags to hidden (if you'd rather not see them, or they aren't applicable to your program).

[sru]

How about having an option for default help or version?

[kbknapp]

Or the opposite of having an option to disable default help and version?
Since I'd assume most would want it.

On Thu, Sep 17, 2015, 8:37 PM SungRim Huh notifications@github.com wrote:

How about having an option for default help or version?

—
Reply to this email directly or view it on GitHub
#256 (comment).

[sru]

That works too. I took a brief look at the app/app.rs file, but I couldn't find where the code is adding the help and version, and where the code is terminating.

[WildCryptoFox]

@sru Also a brief look at the same file. Grep style.

Instances of 'exit' in src/app.rs

• https://github.com/kbknapp/clap-rs/blob/master/src/app/app.rs#L1949 << "get_matches_from"
• https://github.com/kbknapp/clap-rs/blob/master/src/app/app.rs#L2324
• https://github.com/kbknapp/clap-rs/blob/master/src/app/app.rs#L2753
• https://github.com/kbknapp/clap-rs/blob/master/src/app/app.rs#L2761
• https://github.com/kbknapp/clap-rs/blob/master/src/app/app.rs#L2783
• https://github.com/kbknapp/clap-rs/blob/master/src/app/app.rs#L2795

~kbknapp/clap-rs $ grep -in exit src/app/app.rs                                                                                                                                               
346:    /// Allows specifying that if no subcommand is present at runtime, error and exit gracefully
505:    /// Specifies that the help text sould be displayed (and then exit gracefully), if no
630:    /// exiting
659:    /// Specifies that the help text sould be displayed (and then exit gracefully), if no
669:    /// still be displayed and exit. If this is *not* the desired result, consider using
1146:    /// failure (graceful exit).
1210:    /// failure (graceful exit).
1842:    // Prints the version to the user and exits if quit=true
1949:                process::exit(1);
2324:                            process::exit(0);
2575:                    e.exit();
2753:                process::exit(0);
2761:                process::exit(0);
2783:            process::exit(0);
2795:            process::exit(0);

Source of help and version

• https://github.com/kbknapp/clap-rs/blob/master/src/app/app.rs#L2747 "check_for_help_and_version" and callees.

---

The help and version do not appear to be added to the App. Instead, just assumed in the runtime.

---

Spelling mistakes detected at 505, 659. 😉 Also. Wow this file is large 👻

[sru]

@james-darkfox Wow. I didn't think of using grep. I should try to actually use these things.

@kbknapp I have several other ideas as well concerning the general process termination (not the help and version specific).

Just like the title of this issue, we could have a setting to prohibit process termination and wrap every process::exit(...) with ifs.

I am a bit wary with the process::exit() because the documentation says:

Note that because this function never returns, and that it terminates the process, no destructors on the current stack or any other thread's stack will be run.

So, another idea is that let the user handle the error entirely. In this case, we could delegate the error message to ClapError or add helper methods in ClapError to simulate same functionality.

[WildCryptoFox]

@sru I also vote towards ClapError. +1

[Drakulix]

I also vote for ClapError. I do not need to disable the help and version flags and returning a ClapError instead of Process-Termination is just what I need to handle that special case.

[kbknapp]

We could move it to ClapError, the only downside I see is if the user uses ClapError::exit() it will get printed to stderr. Perhaps using a private bool ClapError::is_fatal() to determine if it shoudl go to stderr or stdout similiar to what I've seen in some of BurntSushi's projects?

Thoughts?

[sru]

@kbknapp Is there an example in clap on non-fatal errors?

[kbknapp]

is_fatal() is from the BurntSushi examples, we'd probably adopt it to something like use_stderr()

[sru]

@kbknapp I meant to say how does clap determine if the error should go to stderr or stdout. Or is it like user chooses where the error output should go?

[WildCryptoFox]

@sru One fatal context I've noticed is SubcommandRequiredElseHelp. I'm pretty sure the usage here goes to stderr. However fake --help should go to stdout.

[kbknapp]

@james-darkfox yep that's the intention I had.

[kbknapp]

@Drakulix sorry this has taken literally forever - #326 implements this. See the PR for details 😉

[Drakulix]

Thanks. This is exactly the behavior I expected at first, when using the safe-function. Hopefully this will be also more intuitive and useful to other users as well. Looking forward to the actual merge!