4 ms·

Anyone who designs command-line interfaces for GNU/Linux should read this: https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html https:/

by jzwinck 11y ago

Anyone who designs command-line interfaces for GNU/Linux should read this: https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html https://www.gnu.org/prep/standards/html_node/Command_002dLin... and this: https://www.gnu.org/prep/standards/html_node/Option-Table.html https://www.gnu.org/prep/standards/html_node/Option-Table.ht... If you are using C++, Boost.Program Options is a solid choice. It is one of the relatively few command line argument parsers in the world which supports close to a full set of (GNU-like) behaviors without custom workarounds. It also enables type safety in the sense of disallowing decimals where integers were expected.

gioele 11y ago
Thank you for the link. It contains this tiny gem: a glimpse into a path that CGI applications have not taken: > CGI programs should accept these as command-line options, and also if given as the PATH_INFO; for instance, visiting ‘http://example.org/p.cgi/--help’ http://example.org/p.cgi/--help’ in a browser should output the same information as invoking ‘p.cgi --help’ from the command line.
- xrstf 11y ago
  Wasn't there a massive security issue in PHP a few years back because in some CGI environments, it did in fact accept command line arguments, allowing arbitrary code execution via `php -r "<?php ...` and allowing to view sources via `php -s`?
- jzwinck 11y ago
  Regardless of CGI, I do advocate writing web services that respond to "GET /help" with a developer-facing synopsis of available routes. Pretty much the same thing.
  - LukeShu 11y ago
    I advocate using "OPTIONS /path" for that.
    - deleted 11y ago
      [deleted]
    - jzwinck 11y ago
      That prevents people from loading it with a plain-vanilla web browser. "GET /help" is more accessible, therefore more likely to be used. By humans, I mean.
revelation 11y ago
My major pain with Boost.Program Options is that it is not header-only and pretty massive.
- jzwinck 11y ago
  The shared libraries for it on my system are less than 700 KiB.
  - revelation 11y ago
    Exactly?!

by jzwinck 11y ago

gioele 11y ago

Thank you for the link. It contains this tiny gem: a glimpse into a path that CGI applications have not taken: > CGI programs should accept these as command-line options, and also if given as the PATH_INFO; for instance, visiting ‘http://example.org/p.cgi/--help’ http://example.org/p.cgi/--help’ in a browser should output the same information as invoking ‘p.cgi --help’ from the command line.

xrstf 11y ago
Wasn't there a massive security issue in PHP a few years back because in some CGI environments, it did in fact accept command line arguments, allowing arbitrary code execution via `php -r "<?php ...` and allowing to view sources via `php -s`?
jzwinck 11y ago
Regardless of CGI, I do advocate writing web services that respond to "GET /help" with a developer-facing synopsis of available routes. Pretty much the same thing.
- LukeShu 11y ago
  I advocate using "OPTIONS /path" for that.
  - deleted 11y ago
    [deleted]
  - jzwinck 11y ago
    That prevents people from loading it with a plain-vanilla web browser. "GET /help" is more accessible, therefore more likely to be used. By humans, I mean.

revelation 11y ago

My major pain with Boost.Program Options is that it is not header-only and pretty massive.

jzwinck 11y ago
The shared libraries for it on my system are less than 700 KiB.
- revelation 11y ago
  Exactly?!