Add argfile support #138
Comments
|
Here's a formal description for the sake of possible implementors:
|
|
So, with #1697, I rewrote how input is being parsed. That would enable us to use |
|
@pksunkara are you working on this or can I give it a go? |
|
Please go ahead. |
|
I will implement to @CreepySkeleton's spec then. |
|
If the App is taking an argfile method, then it's better if it's implemented for all subcommands instead of just at the end. |
|
How about edit: this looks different from what I thought |
|
@pickfire Well since |
|
@pksunkara Glad too see this is being worked on! I just wanted to add a comment since this is closing out #1519. I think the spec described by @CreepySkeleton is a really good step and a useful starting point. One thing that I think it lacks is the ability to have comments within your config file. This would be useful if you have a large number of options that are presented by the app, and it would allow end-users to build very readable configs. I could see it being annoying to open up a config file to slightly alter how the app is running and not remembering exactly what each option does. With the ability to comment and/or use the actual |
|
Couple of thoughts:
|
|
Agreed. Whatever we'll end up with, it must be opt-in. I have a bad feeling about comments/blank lines.
Argfiles can be used only on command line. If the user typed Encoding: UTF-8 only. If you're using something else nowadays, it's either some kind of database (argfiles aren't), or this is blasphemy. Send the possessed hard drive to Vatican, the holy priests will perform an appropriate exorcism ritual on it and erase the possessed file. Seriously, who uses non-UTF-8 encodings in files, still?
Agreed on both, an |
|
Good point on the argument values that begin with As for what value comments have in an argfile, I'd agree probably not too much but can still see the use case where a complex CLI ships a default argfile but also comments what each switch/option is doing. I know in my day job there are instances where we ship some gnarly incantations where comments would absolutely help future workers quickly understand what's there.
Again, that's just for positional values, so overriding a positional value isn't a good idea just in the general sense. I'd also fall back to, if this was truly the outcome I expected and my argfile wasn't doing what I thought it would, my initial guess would be to make the line
Windows. 😢 Dealing with UTF-16, WTF-8, and having to do things like BOM sniffing doesn't sound super appealing to an argument parser unless it's well gated and opt-in only 😜 I think @BurntSushi (sorry for the ping) has had some very strong thoughts on dealing with encodings on Windows. |
|
It sounds like the argfile support being discussed here is roughly where I landed for ripgrep's configuration file:
With respect to encoding, I wanted to treat the contents of the file as an Otherwise, I think the single biggest downside to this approach is that the file fomat does not support environment variables. This has been reported as an annoyance, but adding support for them will require a more complicated format. (You probably need some kind of escaping at that point.) |
|
Thank you!
I think this is where I'm landing too. It's also historically how some of my decisions have gone, so I'm ok with this so long as it's documented somewhere.
This might be slightly different in clap's case becase of the intrinsic support for env vars already. A hypothetical argfile (ignoring the need for some escape): Is semantically equivilant to |
|
That requires one to tell clap to allow using an env var though right? If you don't, users might still want to use their own env vars, or use them to build more values. e.g., |
|
Ah yes, you're correct. I was assuming the CLI creator added the Hmm... So my initial thought is while I can see the value in that, I also think it may lead to some gotchas when that env var is unset, etc. In bash it's easy to use a var or default to some value, but being honest I have little interest in trying to account for all those edge cases in an argfile format. I think I'm leaning towards just saying supporting env vars is something we're not doing for now, and if we find some easy way in the future all the better. Especially since if the CLI creator did use the |
|
When going through the ripgrep specs, it got me thinking; what are the thoughts on instead of dedicated CLI syntax
Partial/Pre ParsingA way to declare a subset of arguments to be parsed, then return from parsing early. With the expectation that parsing will be called again, and run to full completion. This most often comes up when you want some argument to handle some aspect of the CLI itself (such as From a user stand point, nothing changes. The run the CLI and things just work. From the a clap consumer stand point, it essentially allows you to pull out some values from the CLI (ignoring everything else), change something about the CLI and continue parsing. // .. already have some App struct
let pre_matches = app.get_partial_matches("color"); // Only parse the `--color` option, ignore all else
app = if let Some("never") = pre_matches.value_of("color") {
app.setting(AppSettings::ColorNever)
} else {
app
};
let matches = app.get_matches();Maybe it's biting off more than we want to chew for now, but this issue seems to come up time and time again where we want to parse some particular subset of arguments, and use those values to inform how the CLI itself behaves. |
Friday Feb 14, 2020 at 11:09 GMT
Originally opened as clap-rs/clap#1693
Describe your use case
I've received requests (XAMPPRocky/tokei#437) to add argfile support to
tokei, it would be nice if this was provided in clap so that it can be shared and reused by all crates.Argfiles aren't a specific standard, and there are varying levels of support. The best documentation I found on it was documentation on
javac's CLI.Describe the solution you'd like
CLI
Rust
The text was updated successfully, but these errors were encountered: