Hacker News Reader

Comment by woodruffw | Hacker News Reader

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.

View on HN

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.

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.

Sounds a bit like PowerShell.

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

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

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.

> 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

> Using short options in scripts

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.

For completions, as part of the Oil shell design space exploration, Andy C. (https://news.ycombinator.com/user?id=chubot) proposed a protocol he called Shellac, see: https://github.com/oilshell/oil/wiki/Shellac-Protocol-Propos...

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.

Or tool authors could write useful man-pages. See OpenBSD for fantastic examples.

On the latter, an example that comes to mind is how to specify field numbers: -f in cut, -k in sort, -j for the most common option in join.

And specifying field delimiters: -d in cut, -t in sort, -F in awk.

Ach, those always get me. Thankfully most (all?) of those also respect the `$IFS` variable, which is what I tend to use.

None of them should respect IFS — that’s only for the shell.

Huh. I could have sworn that GNU Awk respects IFS, but I can't find that in the manual now. Maybe I dreamed it up.

For tab completion the fish shell just parses the man pages, which are fairly standard, to figure out what tab completions are available.

I also used to think that, but it seems like the advanced parsing is done manually[0]

0: https://news.ycombinator.com/item?id=29343053

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.

https://github.com/aclough/dotfiles/blob/master/mupdate.sh

Except that long options are unportable. And they don't really help that much, unless your man pages suck.

As for discoverability: again, that's what man pages are for.

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.

All of those systems have a way to install the GNU utils and I have seen that they all do so when compatibility is important.

https://pkgs.alpinelinux.org/package/edge/main/x86_64/coreut...

https://formulae.brew.sh/formula/coreutils

https://cgit.freebsd.org/ports/tree/sysutils/coreutils

Reply on news.ycombinator.com