Hacker News Reader

Comment by rocky_raccoon | Hacker News Reader

Would there be any usefulness in some sort of a "CLI standard" that defines certain behaviors and provides useful recommendations?

e.g.,

- Apps must always have a --help/-h argument

- Apps that require subcommands or arguments must display "Usage" or "Help" when no subcommand or argument is specified

- When an invalid subcommand or argument is inputted, apps must display "Usage" or "Help"

- Arguments that require a file/resource as a parameter SHOULD use the --file/-f flag where possible (and other standardizing best practices)

Most of this stuff is already built into clap etc. If nothing else, it could remove some of the initial cognitive load.

View on HN

Always requiring "-f" for files is over the top. Think about commands like "mv", "cp" or even "less".

Also that already means "force" for a lot of commands, including two of the ones you mentioned.

Or the many cases where you want to specify an input file and an output file.

https://github.com/Textualize/trogon

> Ultimately we would like to formalize this schema and a protocol to extract or expose it from apps. This which would allow Trogon to build TUIs for any CLI app, regardless of how it was built. If you are familiar with Swagger, think Swagger for CLIs.

it's not complete, but I've been thinking about this problem for years and have been thinking about how to solve it.

I am working on it here: https://github.com/jdx/usage

It's mostly just a README right now, and I'm still iterating on it, talking to friends, but I think I'm getting close. It's definitely not yet written for the average developer to consume yet either. My hope is within the next month or two I might have a usable alpha release of it. I have a use-case for it now so I think it’s finally ready to happen.

If you have any thoughts on my design lmk.

You probably already know, but just in case you don't, you might read about http://docopt.org/ It seems to me a lot of your usage ideas could be refinements of / tooling around docopt-style interfaces.

Yeah I investigated. I don’t think it works well that direction. It is appealing and you can see some elements of it in my current design, though that’s a particular part I’m still unsure of.

It gets way too complicated real quick and a lot of things you _dont_ want to expose in documentation. It’s better to generate docs from a spec than the other way around, I’m pretty sure of this now.

There is also generating the whole thing from a function signature (e.g. https://github.com/c-blake/cligen ) since then CLauthors need not learn a new spec language, but then CLauthors must add back in helpful usage metadata/semantics and still need to learn a library API (but I like how those latter two things can be "gradual"). It's a hard space in which to find perfection, but I wish you luck in your attempt!

My goal is that one day framework authors will adopt this (they might do it quickly since it’s a hell of a lot easier to dump a usage spec and generate completions than it is figuring out how to write completions for each shell).

At that point it would make sense for them to also make scaffolding generators, meaning the cli author only has to write one spec and don’t have to repeat the effort for their code so much.

I think there are 2 ways usage will be used, either as an under the hood format used by frameworks to make frameworks better, or directly by users to scaffold framework code

Ah sweet, I have been wanting to do pretty much the same thing, have found one or two bits of prior art but nothing that has caught on. Very interested.

Ive sort of managed to implement something to this effect in python, and from another comment made me consider yanking it out to its own library.

I made a process where args are now in a toml file, with some various data for different operations, like whether its available in the CLI or API library, its arg flags, help text required value type, etc. From that, i can generate argparse args, documentation, code for other things, etc. Right now im generating args, docs, and a js code block from the same structure.

Heres the toml file: https://gitlab.com/accidentallythecable-public/prover-suite/...

And some docs that were generated from that: https://gitlab.com/accidentallythecable-public/prover-suite/...

Maybe it will give you some ideas on yours

I ended up breaking that functionality away from the originally linked project. Its now in two parts (in case you go to look for it later)

Specification: https://gitlab.com/accidentallythecable-public/argstruct-spe...

Python module implementing specification: https://gitlab.com/accidentallythecable-public/python-module...

There's also: - Treating '-' as STDIN file - Allowing users to get more output using -v - Skipping certain "write" actions by using --dry-run

Then there's dd...

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

Reply on news.ycombinator.com