3 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 th
by 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 agoThanks for the reply! There is a bit to dig in here. Mind reposting this on a discussion so i get notifications and it easier to find again in the future?
- Arch-TK 2y agoI'm sorry, I'm not sure what you mean by "reposting this on a discussion". I've had plans for a while to put together a more complete blog post attempting to characterise the Unix command-line UX from my perspective and what deviations I find annoying in both command line tools and then also delving into annoyances I've had with things like clap specifically. That being said, my blog is about as active as a senior year of '49 school reunion party so who knows when that will be. And not sure if that helps with the notification issue.