4 ms·

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 ha

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.

thomasahle 3y ago
Always requiring "-f" for files is over the top. Think about commands like "mv", "cp" or even "less".
- Izkata 3y ago
  Also that already means "force" for a lot of commands, including two of the ones you mentioned.
- floren 3y ago
  Or the many cases where you want to specify an input file and an output file.
CubsFan1060 3y ago
https://github.com/Textualize/trogon 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.
- jdxcode 3y ago
  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 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.
  - cb321 3y ago
    You probably already know, but just in case you don't, you might read about http://docopt.org/ http://docopt.org/ It seems to me a lot of your usage ideas could be refinements of / tooling around docopt-style interfaces.
    - jdxcode 3y ago
      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.
      - cb321 3y ago
        There is also generating the whole thing from a function signature (e.g. https://github.com/c-blake/cligen 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!
        jdxcode 3y ago
        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.
        jdxcode 3y ago
        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
eddd-ddde 3y ago
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...
chusk3 3y ago
Capturing these guidelines is one of the primary reasons that https://clig.dev/ https://clig.dev/ exists.

thomasahle 3y ago

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

Izkata 3y ago
Also that already means "force" for a lot of commands, including two of the ones you mentioned.
floren 3y ago
Or the many cases where you want to specify an input file and an output file.

CubsFan1060 3y ago

https://github.com/Textualize/trogon 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.

jdxcode 3y ago
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 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.
- cb321 3y ago
  You probably already know, but just in case you don't, you might read about http://docopt.org/ http://docopt.org/ It seems to me a lot of your usage ideas could be refinements of / tooling around docopt-style interfaces.
  - jdxcode 3y ago
    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.
    - cb321 3y ago
      There is also generating the whole thing from a function signature (e.g. https://github.com/c-blake/cligen 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!
      - jdxcode 3y ago
        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.
        jdxcode 3y ago
        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

eddd-ddde 3y ago

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...

chusk3 3y ago

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