argh VS cli-guidelines

https://github.com/google/argh is another minimal library for CLI argument parsing that could be in the list

My go-to is argh[1], as it's more lightweight while still providing a nice derive-based API.

[1]: https://github.com/google/argh

It'll panic if the path contains non-UTF8-able bytes.

Yes clap needs a lot of boilerplate that small programs don't always need, but if you're going to simplify it, I don't think having a bunch of arguments given to the main function is better than having an option struct as in argh. Such an option struct can be given to other functions from the main, can have dedicated consistency check or completion methods, etc.

Typically programs are configured through a config object. People like to use things like clap, structopt, or argh for passing in arguments through the CLI https://github.com/google/argh. You can also use the env! macro for embedding values in at compile time, or by going through the std::env::var infrastructure for runtime env vars.

Until the argh crate bumps their version I cannot updater the version on crates.io so the install command currently is: cargo install --git https://github.com/mkatychev/darkroom

Ahh. The secondary reason I discounted Argh as "unsuitable for purpose" after "Doesn't support using OsString under the hood".

The Command Line Interface Guidelines [1] says:

> Do not read secrets from environment variables

> Secrets should only be accepted via credential files, pipes, `AF_UNIX` sockets, secret management services, or another IPC mechanism

Which one of these do you use? On github it seems common for projects to use environment variables for secrets.

[1] https://clig.dev/#environment-variables

Seems they took a small step back from their previous "don't bother with man pages" stance. Now it's "Consider providing man pages."

I still find it a rather shocking order of priority, honestly.

https://clig.dev/#documentation

- E. `blah project foo --edit`

Wondering if there was any guidance on this from the UNIX people. Perhaps scoping should be done using the file system. `cd path/to/project && blah edit`. Like git does with `git --cwd=path/to/project`. Maybe a virtual FS could even be used. Then you wouldn't have to continuously type in the scope with each command. Interesting thinking about how to maintain state in the terminal...thinking about how Python's virtual env bin/activate modifies the shell.

Found an interesting guide here: https://clig.dev/

Capturing these guidelines is one of the primary reasons that https://clig.dev/ exists.

You may want to take a look at various existing CLIs to get inspiration on how they operate, the user feedback loop and the ergonomics on using them. Here is a great website on some CLI structing guidance https://clig.dev/