3 ms·

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‐lik

by anjbe 4y ago

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.

littlestymaar 4y ago
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.
- anjbe 4y ago
  A far more egregious error is pretending that -h/--help is some sort of universally implemented or agreed upon practice among command‐line tools.
- kazinator 4y ago
  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/ 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.)
account42 4y ago
https://www.freebsd.org/cgi/man.cgi?getopt_long(3) 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) 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.
- anjbe 4y ago
  > 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 https://mandoc.bsd.lv/man/mandoc.1.html jail: https://www.freebsd.org/cgi/man.cgi?jail(8) https://www.freebsd.org/cgi/man.cgi?jail(8) zfs: https://www.freebsd.org/cgi/man.cgi?zfs(8) https://www.freebsd.org/cgi/man.cgi?zfs(8) acme-client: https://man.openbsd.org/acme-client.1 https://man.openbsd.org/acme-client.1 signify: https://man.openbsd.org/signify.1 https://man.openbsd.org/signify.1 doas: https://man.openbsd.org/doas.1 https://man.openbsd.org/doas.1 smtpd: https://man.openbsd.org/smtpd.8 https://man.openbsd.org/smtpd.8 And of course old classics like ssh: https://man.openbsd.org/ssh.1 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.

by anjbe 4y ago

littlestymaar 4y ago

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.

anjbe 4y ago
A far more egregious error is pretending that -h/--help is some sort of universally implemented or agreed upon practice among command‐line tools.
kazinator 4y ago
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/ 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.)

account42 4y ago

https://www.freebsd.org/cgi/man.cgi?getopt_long(3) 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) 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.

anjbe 4y ago
> 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 https://mandoc.bsd.lv/man/mandoc.1.html jail: https://www.freebsd.org/cgi/man.cgi?jail(8) https://www.freebsd.org/cgi/man.cgi?jail(8) zfs: https://www.freebsd.org/cgi/man.cgi?zfs(8) https://www.freebsd.org/cgi/man.cgi?zfs(8) acme-client: https://man.openbsd.org/acme-client.1 https://man.openbsd.org/acme-client.1 signify: https://man.openbsd.org/signify.1 https://man.openbsd.org/signify.1 doas: https://man.openbsd.org/doas.1 https://man.openbsd.org/doas.1 smtpd: https://man.openbsd.org/smtpd.8 https://man.openbsd.org/smtpd.8 And of course old classics like ssh: https://man.openbsd.org/ssh.1 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.