cli-guidelines VS warg

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/

Funcopts aren't always appropriate, but boy do they make things more readable sometimes. I use them pervasively in warg to allow declarative nested CLI commands

I wrote my own! https://github.com/bbkane/warg/

Very useful! I'll be playing with the error tree additions and studying the HTTP interface extension to see if I can replicate the pattern for https://github.com/bbkane/warg values. Id like to be able to have value-specific output for different types of --help , even ones not in warg

I'm using to allow for custom flag types in my CLI parsing library- a lot less duplicate code

One thing that I find nicer with functional options is building tree-like data structures.

My command line parsing library uses them to declaratively build CLI apps with arbitrarily nested subcommands.

Some examples at https://github.com/bbkane/warg/tree/master/examples

I'm writing a CLI parsing library, and generics have let me consolidate most of the flag value functionality for different types. So the flags for dbz --level 9000 --type superSaiyan share most of the same code even though one is an int and one is a string. So much fewer copy-paste-modify lines of code now!

This is largely what the Azure CLI does. It simplifies even further by eliminating the no-value option. Instead, you pass "true" or "false" as the value ( --example true ). It's a little more verbose but very easy to parse/write/generate. I like this convention so much I stole it for my homemade Golang CLI parsing library https://github.com/bbkane/warg/ .