Ask HN: Why is there no specification for Command Line Interfaces?

1. guardrail

   1 2 534 7.8 Scala

   Principled code generation from OpenAPI specifications

   

   What's the use case? I was thinking about this exact issue because my product ships several CLI tools, but I wasn't convinced it would be worth the effort.

   An OpenAPI specification describes an HTTP interface, and I see it as useful because it makes it easier to write code in language-of-choice to generate HTTP requests (by generating client libraries from the OpenAPI spec).

   For a CLI, the interface is the command-line. Usually people type these commands, or they end up in bash scripts, or sometimes they get called from programming language of choice by shelling out to the CLI. So I could see a use case for a CLI spec, which would make it easier to generate client libraries (which would shell out to the CLI)... but it seems a little niche.

   Or maybe, as input to a documentation tool (like Swagger docs). I would imagine if you're using a CLI library like Python's Click, most of that data is already there. Click Parameters documentation: https://click.palletsprojects.com/en/8.1.x/parameters/

   Or maybe, you could start from the spec and then generate code which enforces it. So any changes pass through the spec, which would make it easy to write code (server and client-side) / documentation / changelogs. Some projects like this: Guardrail (Scala) https://github.com/guardrail-dev/guardrail , and Connexion (Python) https://github.com/spec-first/connexion .

   But without this ecosystem of tooling, documenting your CLI in a specification didn't really seem worth the effort. Of course, that's a bootstrapping problem.

2. Sevalla

   sevalla.com featured

   Deploy and host your apps and databases, now with $50 credit! Sevalla is the PaaS you have been looking for! Advanced deployment pipelines, usage-based pricing, preview apps, templates, human support by developers, and much more!

   

3. connexion

   2 24 4,564 6.2 Python

   Connexion is a modern Python web framework that makes spec-first and api-first development easy.

   

   What's the use case? I was thinking about this exact issue because my product ships several CLI tools, but I wasn't convinced it would be worth the effort.

   An OpenAPI specification describes an HTTP interface, and I see it as useful because it makes it easier to write code in language-of-choice to generate HTTP requests (by generating client libraries from the OpenAPI spec).

   For a CLI, the interface is the command-line. Usually people type these commands, or they end up in bash scripts, or sometimes they get called from programming language of choice by shelling out to the CLI. So I could see a use case for a CLI spec, which would make it easier to generate client libraries (which would shell out to the CLI)... but it seems a little niche.

   Or maybe, as input to a documentation tool (like Swagger docs). I would imagine if you're using a CLI library like Python's Click, most of that data is already there. Click Parameters documentation: https://click.palletsprojects.com/en/8.1.x/parameters/

   Or maybe, you could start from the spec and then generate code which enforces it. So any changes pass through the spec, which would make it easy to write code (server and client-side) / documentation / changelogs. Some projects like this: Guardrail (Scala) https://github.com/guardrail-dev/guardrail , and Connexion (Python) https://github.com/spec-first/connexion .

   But without this ecosystem of tooling, documenting your CLI in a specification didn't really seem worth the effort. Of course, that's a bootstrapping problem.

4. typespec

   3 22 5,341 9.9 Java

   

   You've touched on some use cases I've thought about and led me to ask the question.

   I also recently saw Microsoft take a higher level approach with CADL/Typespec: https://microsoft.github.io/typespec/ which could be cool if it reaches wide adoption.

5. cli-guidelines

   4 56 3,232 4.9 CSS

   A guide to help you write better command-line programs, taking traditional UNIX principles and updating them for the modern day.

   

   I was about to recommend https://clig.dev/, but I see you've already found it. It's a great little reference to have when building a CLI. I typically read the code for other CLIs, particularly those written with the framework I'm using. The last framework I used was Cobra [0], and I studied how others did theirs:

   - https://cs.github.com/?scopeName=All+repos&scope=&q=github.c...

   [0]: https://github.com/spf13/cobra

6. cobra

   5 147 41,667 7.6 Go

   A Commander for modern Go CLI interactions

   

   I was about to recommend https://clig.dev/, but I see you've already found it. It's a great little reference to have when building a CLI. I typically read the code for other CLIs, particularly those written with the framework I'm using. The last framework I used was Cobra [0], and I studied how others did theirs:

   - https://cs.github.com/?scopeName=All+repos&scope=&q=github.c...

   [0]: https://github.com/spf13/cobra

7. InfluxDB

   www.influxdata.com featured

   InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.

   

Suggest a related project