Comment by kazinator | Hacker News Reader

Comment by kazinator | Hacker News Reader

Watch out for bloggers: they tend to make stuff up.

There are no "Posix long options" and therefore a "Posix-compliant" argument parser will not handle them just fine.

Long options set off using two dashes were popularized by the GNU utilities.

POSIX describes a getopt C library function and a getopts utility command. Neither of them specify any requirements for long options. They will not parse long options "just fine"; not without extensions for it.

In the GNU C library (and compatibles), there is a getopt_long function that supports long options; there is no attempt made to extend the POSIX getopt to handle long options.

POSIX does not have a help option convention: -h is not consistently a help option. The "Utility Syntax Guidelines" makes numerous recommendations about options; no mention is made of anything resembling long options, or that if there is a help option, it should have such and such name.

I don't know of any utility for which POSIX requires some kind of help option; it describes only the man command.

I usually refer to these as "GNU-style arguments", whether or not that's the correct terminology. The fact that Go-based utilities tend to use the `-option` style (with a single hyphen) still bothers me.

This is overly pedantic. The point is that people using POSIX (i.e. Unix-like) systems expect -h or --help to work, as a matter of convention. What the letter of POSIX-the-standard says doesn't really matter to most people.

But it’s not overly pedantic. POSIX is literally a formal standard, and that standard does not provide a mechanism for long options. Other “POSIX (i.e. Unix‐like) systems” like the BSDs do not generally use long options, nor do they generally support -h as a “help” flag.

What you’re describing as a POSIX convention is really a GNU convention. But the world of POSIX consists of more than just GNU. So the grandparent post is correct.

POSIX is a legacy “formal standard”. The two biggest players by far of the Unix branch (Linux and MacOS) both implement it losely.

The POSIX strictness battle have been lost more than two decades ago. Behaving as if it did not, is overly pedantic.

A far more egregious error is pretending that -h/--help is some sort of universally implemented or agreed upon practice among command‐line tools.

Large, complex code written in C that has a wide API footprint will work with little or no modification among systems like GNU/Linux, Solaris and Mac OS.

The specification is online and people use it when coding, refer to it it in discussions and when filing bug reports.

2018 edition: https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...

It's been my experience that the maintainers of major FOSS projects take it seriously when something is reported as being at odds with POSIX.

I don't remember any recent "POSIX strictness battle"; you didn't just make that up, did you?

There was as struggle starting in the 1980's to deal with incompatibilities among large numbers of vendor-specific derivatives of Unix that were cropping up everywhere. Unix brand incompatibilities negatively affected the users, who wanted their programs (and skills) to transfer. That is more ancient history. In retrospect, it looks like the standardization effort was broadly successful.

POSIX is not exactly standing still; it has been amassing new interfaces, and vendors adapt them as specified.

When I started coding in Unix, gethostbyname was the way to resolve DNS; now you have getaddrinfo, which is more generic and can give you IPv6 and IPv4 results in the same call. Even in basic Unix functionality, there are new features: for instance, various "at" functions, like openat: open a file relative to a specified directory descriptor, rather than the current working directory. POSIX specified threads that work everywhere, shared memory that works everywhere and other things.

There is rather a struggle between "use latest stuff in POSIX" versus "have code work on older systems".

But, overall, POSIX is a huge relief.

POSIX is a big reason why you can take code written using Glibc and get it running on Musl. Or on Cygwin.

An alternative C library that has Glibc compatibility as its goal would be a lot more difficult to develop if it had to be based entirely on reverse engineering Glibc. The Glibc documentation isn't complete enough. (And, doh, that's because it expects you to refer to POSIX for the details.)

https://www.freebsd.org/cgi/man.cgi?getopt_long(3)

> HISTORY

> The getopt_long() and getopt_long_only() functions first appeared in the GNU libiberty library. The first BSD implementation of getopt_long() appeared in NetBSD 1.5, the first BSD implementation of getopt_long_only() in OpenBSD 3.3. FreeBSD first included getopt_long() in FreeBSD 5.0, getopt_long_only() in FreeBSD 5.2.

So the parsing support is there. And it is used, e.g. tar aka bsdtar:

https://www.freebsd.org/cgi/man.cgi?tar(1)

So long options were popularized by GNU but have since become common across different POSIX operating systems.

> So the parsing support is there. And it is used, e.g. tar

Yes, the parsing support is there, so software written in the GNU style does build and run correctly on BSD systems. But although you bring up tar (a command that is well known for its unusual and unconventional flag handling), it is generally the case that commands on BSD operating systems do not use long options.

Representative examples of prominent 21st century BSD software that do not use long options:

mandoc: https://mandoc.bsd.lv/man/mandoc.1.html

jail: https://www.freebsd.org/cgi/man.cgi?jail(8)

zfs: https://www.freebsd.org/cgi/man.cgi?zfs(8)

acme-client: https://man.openbsd.org/acme-client.1

signify: https://man.openbsd.org/signify.1

doas: https://man.openbsd.org/doas.1

smtpd: https://man.openbsd.org/smtpd.8

And of course old classics like ssh: https://man.openbsd.org/ssh.1

kazinator’s point, that there is no POSIX convention of using -h for help, is correct. That convention came from GNU, and while the idea has spread due to GNU’s influence, there are other prominent schools of thought in the POSIX or Unix‐like ecosystem. I would certainly not agree that long options are the common case on BSD systems.

I feel the same when they talk about UNIX, but are actually describing GNU/Linux.

GNU/Linux == GNU is not Unix (even) over Linux.

:)

And since the article is using podman as an example: podman does have a manpage. The actual standard way of getting documentation on utilities, man podman, works just fine.

I think man pages tend to be more heavyweight than people sometimes; if I just want to see a few of the most common options to copy, it's a lot easier to have a few lines just printed out rather than having to crawl through potentially dozens of pages being piped to `less` and then open a second terminal pane if I want to look at it while I'm typing my command.

Put another way, I think `--help` is basically the CLI equivalent of generated API docs, whereas manpages are like long-form prose documentation. While you can get by with just one of them, the experience is going to be worse for certain use cases, and generally for anything beyond a certain level of complexity, your users will be better off if you provide both.

Downvoted because You can correct the article without making it personal

Reply on news.ycombinator.com