4 ms·

I dislike clap too, it requires too much work to configure it in a sensible way (sensible being defined as working like most unix utilities have worked for the

I dislike clap too, it requires too much work to configure it in a sensible way (sensible being defined as working like most unix utilities have worked for the entire time I've used them), it comes with very "modern" defaults which while I appreciate are aiming to improve the situation, when I'm writing an utility in rust, it's usually a port of something I wrote in another language and I don't want to deviate unnecessarily. There's also the aspect of just how many dependencies it pulls in. But, there are a few issues with this argument parser. First and foremost, while there's no problem with forcing your option names to be str/String, you should still process OsStr/OsString unless none of your arguments are ever planning to be OS paths. The reason for this is that making your programs accept all the valid unix path names (which might not be valid UTF-8) is just the right thing to do, the alternative is an arbitrary restriction on your end users. It's about as annoying to run into these kinds of issues as it is to run into applications which don't handle spaces in filenames. Next, there's the inability to handle multiple short options combined. Also there's the lack of proper handling for options which require arguments vs options with optional arguments (-ovalue, -o value, --opt=value and --opt value should all work for the former case, but for the latter case it only makes sense to accept -ovalue and --opt=value due to the implications in the alternative case). Although this isn't that important and generally confuses people anyway so maybe it should be avoided. Last (in this list, but no guarantee it's exhaustive), there's no handling for `--` to end passing options. This can have security implications. It's a bit of a shame there isn't a zero dependency direct clone of python's argparse. Or something like that even in the standard library. argparse is relatively easy to use, not necessarily designed to be low overhead or fast (god help you if you're in a situation where option parsing is your bottleneck, but I can also appreciate the desire for not wasting cycles where there's no reason to waste them). I think it's a good idea that people are writing their own low-dependency programs. But it's important that you understand the subject matter in detail if you plan on doing something like this for anything you're hoping to be used by anyone other than yourself. While clap deviates a lot from the expectations of an option parser (I think part of the deviation is that the people behind clap want to do things "better" than they've been done in the past, but the problem with this motivation is that at some point better isn't important if it is at odds with interface design which has been around for a long time), it does for the most part handle most of these things in the expected way. For me personally, I would reach for getargs (specifically, my own fork of getargs which does the handling of ArgsOs in a way I find to be optimal) can handle all of the above outline things correctly. There's also lexopt which looked promising when I last looked at it.

epage 2y ago
> I dislike clap too, it requires too much work to configure it in a sensible way (sensible being defined as working like most unix utilities have worked for the entire time I've used them), it comes with very "modern" defaults which while I appreciate are aiming to improve the situation, when I'm writing an utility in rust, it's usually a port of something I wrote in another language and I don't want to deviate unnecessarily. There's also the aspect of just how many dependencies it pulls in. Which deviations are you concerned about? > It's a bit of a shame there isn't a zero dependency direct clone of python's argparse. Or something like that even in the standard library. argparse is relatively easy to use, not necessarily designed to be low overhead or fast (god help you if you're in a situation where option parsing is your bottleneck, but I can also appreciate the desire for not wasting cycles where there's no reason to waste them). As a maintainer of a CLI parser, I think there is too much policy to put in the standard library. If you go for something much simpler, like lexopt, I think its more doable but then again, I'm finding I'm writing y own lexopt-like library because it has too much policy in it.
- Arch-TK 2y ago
  > Which deviations are you concerned about? This is the list I came up with the last time I looked at clap: * Colours - But can be turned off by removing the color feature. * Plain weird help formatting...: Example: $ clap-brightness --help Adjust sysfs backlight with a log scale Usage: clap-brightness [OPTIONS] <BACKLIGHT> <ADJUSTMENT> Arguments: <BACKLIGHT> Path to sysfs backlight (e.g. /sys/class/backlight/amdgpu_bl0) <ADJUSTMENT> Percentage adjustment; relative (e.g. +10 or -6.25) or absolute (e.g. 50) Options: -m, --min <MIN> Artificially limit maximum brightness (percentage 'n%' or raw value 'n') [default: 0] -M, --max <MAX> Artificially limit minimum brightness (percentage 'n%' or raw value 'n') -h, --help Print help $ argparse-brightness usage: argparse-brightness [-h] [-m MIN] [-M MAX] backlight adjustment Adjust sysfs backlight with a log scale positional arguments: backlight path to sysfs backlight (e.g. /sys/class/backlight/amdgpu_bl0) adjustment percentage adjustment (e.g. +10 or -6.25) or absolute value (e.g. 50) options: -h, --help show this help message and exit -m MIN, --min MIN artificially limit minimum brightness (percentage 'n%' or raw value 'n') [default: 0] -M MAX, --max MAX artificially limit maximum brightness (percentage 'n%' or raw value 'n') * Why is the description printed before the usage? * Why are positional arguments screamed at me? I've genuinely never seen this choice of full caps for positional arguments. I would have been happy with lowercase or <lowercase>. * Likewise option placeholders are screamed and angle bracketed. I've only ever seen one or the other. * It refuses to show you what the options are even if there's only 3 of them. * And then there's the weird error handling decisions: Example: $ clap-brightness error: the following required arguments were not provided: <BACKLIGHT> <ADJUSTMENT> Usage: clap-brightness <BACKLIGHT> <ADJUSTMENT> For more information, try '--help'. $ argparse-brightness usage: argparse-brightness [-h] [-m MIN] [-M MAX] backlight adjustment argparse-brightness: error: the following arguments are required: backlight, adjustment * Redacted usage line (why?). * Instruction to tell me to try '--help'. Maybe useful if it's your first day in a unix environment, a waste of screen space otherwise. * 2 lines of unnecessary whitespace. * A newline separated list of required arguments when there are two of them? (If someone's tool takes 20 required arguments they should be punished by having unreadable automatically generated error messages.) * Error line is formatted as "error: ..." and not "argv[0]: error: ..." which is pretty standard and very useful if you call your program from within a shell script and it dumps an error. * Usage line isn't printed first, or last, but randomly in the middle (It should be first). * But it gets worse: Example: $ clap-brightness /path a10 error: invalid value 'a10' for '<ADJUSTMENT>': invalid float literal For more information, try '--help'. * Usage disappeared entirely? Why? * And then: Example: $ clap-brightness /path -a error: unexpected argument '-a' found tip: to pass '-a' as a value, use '-- -a' Usage: clap-brightness [OPTIONS] <BACKLIGHT> <ADJUSTMENT> For more information, try '--help'. * Back to the full usage statement again, but now aside from suggestions to refer to --help, I also get taught how to use --. From what I can tell, a lot of these things can be cleaned up and changed. But figuring out how to do that and actually doing it seemed like more work than just picking a different option parser. And yes, a lot of this is nitpicking, but I spend a lot of time in a terminal, I have certain expectations of how things should look and behave, and a lot of these issues are just plain deal breakers.

epage 2y ago

> I dislike clap too, it requires too much work to configure it in a sensible way (sensible being defined as working like most unix utilities have worked for the entire time I've used them), it comes with very "modern" defaults which while I appreciate are aiming to improve the situation, when I'm writing an utility in rust, it's usually a port of something I wrote in another language and I don't want to deviate unnecessarily. There's also the aspect of just how many dependencies it pulls in. Which deviations are you concerned about? > It's a bit of a shame there isn't a zero dependency direct clone of python's argparse. Or something like that even in the standard library. argparse is relatively easy to use, not necessarily designed to be low overhead or fast (god help you if you're in a situation where option parsing is your bottleneck, but I can also appreciate the desire for not wasting cycles where there's no reason to waste them). As a maintainer of a CLI parser, I think there is too much policy to put in the standard library. If you go for something much simpler, like lexopt, I think its more doable but then again, I'm finding I'm writing y own lexopt-like library because it has too much policy in it.

Arch-TK 2y ago
> Which deviations are you concerned about? This is the list I came up with the last time I looked at clap: * Colours - But can be turned off by removing the color feature. * Plain weird help formatting...: Example: $ clap-brightness --help Adjust sysfs backlight with a log scale Usage: clap-brightness [OPTIONS] <BACKLIGHT> <ADJUSTMENT> Arguments: <BACKLIGHT> Path to sysfs backlight (e.g. /sys/class/backlight/amdgpu_bl0) <ADJUSTMENT> Percentage adjustment; relative (e.g. +10 or -6.25) or absolute (e.g. 50) Options: -m, --min <MIN> Artificially limit maximum brightness (percentage 'n%' or raw value 'n') [default: 0] -M, --max <MAX> Artificially limit minimum brightness (percentage 'n%' or raw value 'n') -h, --help Print help $ argparse-brightness usage: argparse-brightness [-h] [-m MIN] [-M MAX] backlight adjustment Adjust sysfs backlight with a log scale positional arguments: backlight path to sysfs backlight (e.g. /sys/class/backlight/amdgpu_bl0) adjustment percentage adjustment (e.g. +10 or -6.25) or absolute value (e.g. 50) options: -h, --help show this help message and exit -m MIN, --min MIN artificially limit minimum brightness (percentage 'n%' or raw value 'n') [default: 0] -M MAX, --max MAX artificially limit maximum brightness (percentage 'n%' or raw value 'n') * Why is the description printed before the usage? * Why are positional arguments screamed at me? I've genuinely never seen this choice of full caps for positional arguments. I would have been happy with lowercase or <lowercase>. * Likewise option placeholders are screamed and angle bracketed. I've only ever seen one or the other. * It refuses to show you what the options are even if there's only 3 of them. * And then there's the weird error handling decisions: Example: $ clap-brightness error: the following required arguments were not provided: <BACKLIGHT> <ADJUSTMENT> Usage: clap-brightness <BACKLIGHT> <ADJUSTMENT> For more information, try '--help'. $ argparse-brightness usage: argparse-brightness [-h] [-m MIN] [-M MAX] backlight adjustment argparse-brightness: error: the following arguments are required: backlight, adjustment * Redacted usage line (why?). * Instruction to tell me to try '--help'. Maybe useful if it's your first day in a unix environment, a waste of screen space otherwise. * 2 lines of unnecessary whitespace. * A newline separated list of required arguments when there are two of them? (If someone's tool takes 20 required arguments they should be punished by having unreadable automatically generated error messages.) * Error line is formatted as "error: ..." and not "argv[0]: error: ..." which is pretty standard and very useful if you call your program from within a shell script and it dumps an error. * Usage line isn't printed first, or last, but randomly in the middle (It should be first). * But it gets worse: Example: $ clap-brightness /path a10 error: invalid value 'a10' for '<ADJUSTMENT>': invalid float literal For more information, try '--help'. * Usage disappeared entirely? Why? * And then: Example: $ clap-brightness /path -a error: unexpected argument '-a' found tip: to pass '-a' as a value, use '-- -a' Usage: clap-brightness [OPTIONS] <BACKLIGHT> <ADJUSTMENT> For more information, try '--help'. * Back to the full usage statement again, but now aside from suggestions to refer to --help, I also get taught how to use --. From what I can tell, a lot of these things can be cleaned up and changed. But figuring out how to do that and actually doing it seemed like more work than just picking a different option parser. And yes, a lot of this is nitpicking, but I spend a lot of time in a terminal, I have certain expectations of how things should look and behave, and a lot of these issues are just plain deal breakers.