4 ms·

The GNU conventions are terribly convenient. If we were redesigning it from scratch, I'd like to keep all of them except for removing duplicated functionality.

• conaclos 5y ago
  > that means we only can keep --long=x Just wondering: why `--long=x` over `--long x`?
  • grose 5y ago
    `--long x` is potentially ambiguous. `x` could be referring to a file if `--long` doesn't take any options, so parsing it correctly depends on this knowledge. The equals sign removes this ambiguity.
    • twic 5y ago
      If we were starting from scratch, we could require some marker on flags which take values. Perhaps it would have to be `--long: x`. `--verbose x` would be read as a flag with no argument, followed by a positional argument.
      • Karellen 5y ago
        Isn’t that just replacing “=“ with “:”?
        • twic 5y ago
          No, there's a space in there too!
          • jolmg 5y ago
            This works to allow values to be optional while not requiring concatenation of strings in languages where that's troublesome like C. It only lacks in being able to work with brace expansion to facilitate specifying multiple values.
  • kzrdude 5y ago
    --long=x supports the simultaneous --color and --color=auto usecase, i.e the value is optional. Without = it's ambiguous.
  • deleted 5y ago
    [deleted]
  • jolmg 5y ago
    It also has the advantage that it works with brace expansion to specify multiple values. --long={foo,bar} becomes --long=foo --long=bar
    • conaclos 5y ago
      With bash/zsh the auto-completion seems missing for unknown options. While `--key file` supports auto-completion since file is just another parameter.
      • jolmg 5y ago
        Yup. Both styles have their advantages, which is why they're both common. For the problem you mention, I normally have them separate while I use completions, then add the = sign after.
      • kzrdude 5y ago
        that's a tool issue that should be fixed
    • kzrdude 5y ago
      Thanks for teaching something useful!
      • conaclos 5y ago
        Actually you can expand any pattern: --option{X,Y} -> --optionX --optionY --option:{X,Y} -> --option:X --option:Y ...
• mort96 5y ago
  I disagree with getting rid of `--long x`. It's really common to build command argvs programmatically, where you have a string representing some option (such as a file path), and you need to pass that as a long option. With `--long x`, you can do like: char *argv[] = {"my-program", "--config-file", config_file, NULL}; run_command(argv); With only `--config-file=x`, you would have to allocate memory for the option: char *config_file_opt = asprintf("--config-file=%s", config_file); char *argv[] = {"my-program", config_file_opt, NULL}; run_command(argv); free(config_file_opt); And it becomes even more hairy if you A) want to avoid heap allocation in most cases or B) want to use standard functions rather than asprintf. You'd have to do something like this: char config_file_opt_buf[1024]; char *config_file_opt; size_t config_file_opt_len = snprintf(config_file_opt_buf, sizeof(config_file_opt_buf), "--config-file=%s", config_file); if (config_file_opt_len >= sizeof(config_file_opt_buf)) { config_file_opt = malloc(config_file_opt_len); snprintf(config_file_opt, config_file_opt_len, "--config-file=%s", config_file); } else { config_file_opt = config_file_opt_buf; } char *argv[] = {"my-program", config_file_opt, NULL}; run_command(argv); if (config_file_opt != config_file_opt_buf) { free(config_file_opt); } And even that ignores any kind of error checking of snprintf or malloc which may fail. I also wouldn't even be comfortable assuming the code I just wrote is correct, without thinking long and hard about it and reading standards/documentation thoroughly. Whereas the first example is so simple it's obviously correct. I think we should keep `--long x`. If anything, `--long=x` is the one which should go. There will always be ambiguity; the meaning of something like `-ab` also depends on whether `-a` takes an argument or not. Really though, I think there are enough situations where `--long=x` is useful that I think keeping both versions makes sense.
  • jbverschoor 5y ago
    If all of this matters so much, don’t use an (interactive) shell.
    • mort96 5y ago
      We're not talking about the shell, we're talking about the options parser. Nothing in my examples invokes any shell.
• inopinatus 5y ago
  Still waiting for su —-with-wheel-group
  • euroderf 5y ago
    I come not to bury wheel, but to praise it.
    • Maursault 5y ago
      An industry big wheel, a wheel man with nice wheels, put shoulder to the wheel to put wheels in motion spinning wheels to reinvent the wheel before the wheels came off the wagon and squeaky wheel gets the grease. My name is Jonas. I'm carrying the wheel.
      • euroderf 5y ago
        I confess that back in the day, whenever I tried to grok a man page or manual page about wheel, it was basically incomprehensible.
    • deleted 5y ago
      [deleted]
• megous 5y ago
  Sometimes I'm glad for public interface ossification. :)
• sph 5y ago
  I am annoyed go's flags package did not respect the GNU convention for options, which I agree is the best.
  • daptaq 5y ago
    I am not too surprised that the confluence point between Plan 9 and Google have little interest in following the GNU way.
    • 0des 5y ago
      Plan 9 did nothing wrong.
  • euroderf 5y ago
    Try github.com/spf13/pflag, it handles double-dash arguments OK, and is drop-in.
• layer8 5y ago
  I’m curious why they introduced the ‘=‘ variant at all. Maybe they thought it would be clearer for human readers?