4 ms·

> that means we only can keep --long=x Just wondering: why `--long=x` over `--long x`?

• grose 4y 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 4y 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 4y ago
      Isn’t that just replacing “=“ with “:”?
      • twic 4y ago
        No, there's a space in there too!
        • jolmg 4y 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 4y ago
  --long=x supports the simultaneous --color and --color=auto usecase, i.e the value is optional. Without = it's ambiguous.
• deleted 4y ago
  [deleted]
• jolmg 4y 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 4y 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 4y 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 4y ago
      that's a tool issue that should be fixed
  • kzrdude 4y ago
    Thanks for teaching something useful!
    • conaclos 4y ago
      Actually you can expand any pattern: --option{X,Y} -> --optionX --optionY --option:{X,Y} -> --option:X --option:Y ...