Maybe it's because I'm not the biggest Unix purist, but I don't really mind the proliferation of command line options. The two things that do irk me are:
* Using short options in scripts. Scripts should almost always use long options. As a corollary, tools should always provide long options unless the tool isn't intended for scripting.
* Lack of discoverability. We still don't have a standard way to ask an arbitrary tool which flags it supports, or for a rough semantic mapping of those flags (e.g. the classic -v/-V verbose and version confusion). Developing a standard here would go a long way towards automating things like tab completion without each tool needing to maintain N scripts for N shells or having its own slightly-different `--completions=SHELL` generator.
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.
> ... 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.
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.
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.
> 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
And documentation, or when answering questions. SE answers are often like "just type `blah -jraiorjg` and you're done", which means having to look up all these options in the manual. Short options should be the exception, when working in the shell mostly, not the rule.
Re-typing commands from SE answers without consulting a man is a bad idea even with long options. SE is a good place when you don't know where to start or which man to read, but once you see an answer it is better to check in mans/docs how suggested command would work and what it will do. But I agree that if you want to help someone who doesn't know particular command it is better to use long options.
It would be nice to have a uniform standardized basic command lines on all platform to get the information of the command like 'help'. Annoyingly when I tried to find the command options in the terminal like help, h, -help, --help, -h, and it variants. Can we just have a standardized basic command to make it easier for everyone to expect certain things than making the users to check the manual or the documentations (sometime they don't even list it in there). Don't make it a pain for the end-users.
Yes, there's stuff that you can't get just from parsing the man page too, but it's a huge help. I know it's not done every startup, I have running that as part of my "update everything" script.
Unportability is, for better or worse, a moot point when the GNU coreutils form the de facto standard for most actual shell scripting.
It's also not relevant in the context of shell scripting with tools that aren't intended to be part of POSIX or any other standard. Plenty of ecosystems and workflows are built on proprietary, internal, or just not standardized tools.
For most linux distributions sure, GNU might be considered a standard. But if you want your script to work on macOS or BSD, or even for example Alpine linux, then you can't just treat GNU as standard.
* Using short options in scripts. Scripts should almost always use long options. As a corollary, tools should always provide long options unless the tool isn't intended for scripting.
* Lack of discoverability. We still don't have a standard way to ask an arbitrary tool which flags it supports, or for a rough semantic mapping of those flags (e.g. the classic -v/-V verbose and version confusion). Developing a standard here would go a long way towards automating things like tab completion without each tool needing to maintain N scripts for N shells or having its own slightly-different `--completions=SHELL` generator.