[nauticacom]

The last point would be amazing, imo. It's unfortunate that, because of history, commands accept and parse arbitrary strings as input instead of formally specifying it like a function signature + docblock. If I could rewrite the universe, commands would use a central API for specifying the names, data types, descriptions, etc. for all the input they take. In our timeline, maybe some file format could be standardized that describes the particular inputs and options a command takes, and e.g. shells would hook into it. Kind of like header files, but distributed either in a community repository or by each of the tools themselves.

[useerup]

> ... commands accept and parse arbitrary strings as input instead of formally specifying it like a function signature + docblock. If I could rewrite the universe, commands would use a central API for specifying the names, data types, descriptions, etc. for all the input they take

Which is exactly what powershell does: Commands in powershell (called "cmdlets") are like functions with type hints. A command does not parse the input strings itself, rather it exposes this type information to the shell. The shell is the one responsible for discovering the parameters (and types) and parsing the command line parameters and coercing types before passing them (strongly typed) to the actual command.

This means that the information about parameter names and types is readily available for doc-generation, auto tab-completion and language servers which allow syntax highlighting, completion etc to work even inside editors such as vscode or emacs.

The point is that to specify a cmdket you must declare parameters, in much the same way that for a function in a programming language to accept parameters it must declare those as formal parameters.

[pjmlp]

And with PowerShell Crescendo, same experience can be provided for native commands, although I think it is a bit too much expecting everyone to create crescendo configuration files.

[vicda]

Despite powershell's many warts it's my goto language for writing command line scripts.

[woodruffw]

Yeah, the inertia is the real killer here. I'd love to see a fully embedded solution (particularly given that ecosystems like Go and Rust discourage sidecar files like manpages), but thus far the only one I've really seen is individual tools supporting a `--completions=SHELL` style argument that spits out an `eval`-able script for the requested shell.

The real dream would be some kind of standard way for a program to indicate that it's opting into more intelligent CLI handling without any execution. I've thought about trying to hack something like that together with a custom ELF section, but that wouldn't fly for programs written in scripting languages.

[mschrage]

> In our timeline, maybe some file format could be standardized that describes the particular inputs and options a command takes, and e.g. shells would hook into it. Kind of like header files, but distributed either in a community repository or by each of the tools themselves.

This sort of sounds like what we're working on at Fig. We've defined a declarative standard for specifying the inputs to a CLI tool and have a community repo with all supported tools: https://github.com/withfig/autocomplete

Disclosure: I'm one of the founders

[kaetemi]

Sounds a bit like PowerShell.