4 ms·

What does posix compliant mean in this context?

by zokier 4y ago

klyrs 4y ago
It (edit: claims to) conforms to the POSIX spec for command line arguments https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
- planede 4y ago
  That document does not describe long options. I guess that can be treated as a conforming extension. The C implementation does not seem to have support for optional option arguments. The C implementation also does not seem to support "--" as a delimiter for option arguments, although that's only a guideline. So I guess it can be used to implement POSIX compliant interfaces that don't use optional option arguments. edit: supporting "--" as delimiter might not be a guideline: The utilities in the Shell and Utilities volume of POSIX.1-2017 that claim conformance to these guidelines shall conform completely to these guidelines as if these guidelines contained the term "shall" instead of "should". edit2: Seems like I was completely wrong about supporting "--", when tried out it does seem to support it. One weird corner cases is the call `<prog> -- -`, where "-" isn't interpreted as enabling stdin, but treated as a regular positional argument. `echo asd | cat -- -` reads from stdin with GNU cat.
  - klyrs 4y ago
    On a closer read, the comment mentions plan9's arg(3): https://9fans.github.io/plan9port/man/man3/arg.html https://9fans.github.io/plan9port/man/man3/arg.html Generally, I think it's pretty normal to interpret "POSIX compliant" as a minimum requirement, and then extend that to your own whims as long as you don't break the POSIX part.
  - mtlmtlmtlmtl 4y ago
    "--" is a GNU originated thing afaik.
    - planede 4y ago
      Maybe, but it's part of POSIX now. Anyway, I misread the code, and it's actually supported.
  - camel-cdr 4y ago
    > So I guess it can be used to implement POSIX compliant interfaces that don't use optional option arguments. Yes, that was my intention.
- wahern 4y ago
  In the context of option parsing, "POSIX compliant" makes me think of the semantics of getopt(3): https://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/g... Notably, the utility conventions and even the guidelines (guideline 14 presumes non-compliance with guideline 7) support optional option-arguments, while the bundling semantics of getopt preclude optional option-arguments. Utilities, including POSIX-defined utilities, which have optional option-arguments cannot use getopt.

What does posix compliant mean in this context?

by zokier 4y ago

What does posix compliant mean in this context?

It (edit: claims to) conforms to the POSIX spec for command line arguments https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

planede 4y ago
That document does not describe long options. I guess that can be treated as a conforming extension. The C implementation does not seem to have support for optional option arguments. The C implementation also does not seem to support "--" as a delimiter for option arguments, although that's only a guideline. So I guess it can be used to implement POSIX compliant interfaces that don't use optional option arguments. edit: supporting "--" as delimiter might not be a guideline: The utilities in the Shell and Utilities volume of POSIX.1-2017 that claim conformance to these guidelines shall conform completely to these guidelines as if these guidelines contained the term "shall" instead of "should". edit2: Seems like I was completely wrong about supporting "--", when tried out it does seem to support it. One weird corner cases is the call `<prog> -- -`, where "-" isn't interpreted as enabling stdin, but treated as a regular positional argument. `echo asd | cat -- -` reads from stdin with GNU cat.
- klyrs 4y ago
  On a closer read, the comment mentions plan9's arg(3): https://9fans.github.io/plan9port/man/man3/arg.html https://9fans.github.io/plan9port/man/man3/arg.html Generally, I think it's pretty normal to interpret "POSIX compliant" as a minimum requirement, and then extend that to your own whims as long as you don't break the POSIX part.
- mtlmtlmtlmtl 4y ago
  "--" is a GNU originated thing afaik.
  - planede 4y ago
    Maybe, but it's part of POSIX now. Anyway, I misread the code, and it's actually supported.
- camel-cdr 4y ago
  > So I guess it can be used to implement POSIX compliant interfaces that don't use optional option arguments. Yes, that was my intention.
wahern 4y ago
In the context of option parsing, "POSIX compliant" makes me think of the semantics of getopt(3): https://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/g... Notably, the utility conventions and even the guidelines (guideline 14 presumes non-compliance with guideline 7) support optional option-arguments, while the bundling semantics of getopt preclude optional option-arguments. Utilities, including POSIX-defined utilities, which have optional option-arguments cannot use getopt.