5 ms·

I think disallowing short option altogether is not a bad convention. With only `-long` and `-long=xxx`, my command line parsing is simply foreach a in argl

I think disallowing short option altogether is not a bad convention. With only `-long` and `-long=xxx`, my command line parsing is simply foreach a in arglist if a=~/^-(\w+)(?:=(.+))?/ $opts{$1} = $2; else push @pos_list, $a There is no need for the dependency and complexity of `getopt` library. And for the user side, no more cryptic ninja arts. The only trick user need to learn is the shell alias and functions.

orev 6y ago
The point isn’t to use getopt with all its complexity, the point is that two dashes for long options is already extremely well established and Go popularizing long options with a single dash is very much a regression. It creates a lot of unnecessary confusion when they really should have known better and just stuck with the conventions. In your regex at least, removing the confusion is simple as adding another ‘-‘, and now you’re in compliance with the expectations of almost every IT person in the world who uses Unix command lines.
- bdhess 6y ago
  Go's flag parser treats two leading minus signs the same as one. https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax
  - d21d3q 6y ago
    Sure, but convention is to treat `-long` as `-l -o -n -g'.
    - tsimionescu 6y ago
      But that is a bad convention, it prioritizes typing speed over readability, and it only works in certain cases (for flag-only parameters). I'd say good riddance to it.
      - lifthrasiir 6y ago
        That doesn't justify long options starting with a single dash, as one could have made every option start with two dashes. Sure, `--` is longer than `-`, but typing speed shouldn't matter right?
        tsimionescu 6y ago
        Sure, but the only reason to add an extra dash is to differentiate --long from -l -o -n -g. No reason to just add extra characters if ypu don't need this differentiation. Not to mention, Go cmd line parsing actually accepts both -long and --long, if you find the -- version more aesthetically pleasing.
    - cowl 6y ago
      If we only did "the accepted convention" indefinitely there would be no going forward. I see this change(of being explicit) as a win. The situation was already confusing before with different tools using different conventions. This way of being explicit allows you to be consistent across OS-s too. The world is not only GNU, fortunately.
- GoblinSlayer 6y ago
  Buffer overflows are well established too, not all traditions are good.

orev 6y ago

The point isn’t to use getopt with all its complexity, the point is that two dashes for long options is already extremely well established and Go popularizing long options with a single dash is very much a regression. It creates a lot of unnecessary confusion when they really should have known better and just stuck with the conventions. In your regex at least, removing the confusion is simple as adding another ‘-‘, and now you’re in compliance with the expectations of almost every IT person in the world who uses Unix command lines.

bdhess 6y ago
Go's flag parser treats two leading minus signs the same as one. https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax
- d21d3q 6y ago
  Sure, but convention is to treat `-long` as `-l -o -n -g'.
  - tsimionescu 6y ago
    But that is a bad convention, it prioritizes typing speed over readability, and it only works in certain cases (for flag-only parameters). I'd say good riddance to it.
    - lifthrasiir 6y ago
      That doesn't justify long options starting with a single dash, as one could have made every option start with two dashes. Sure, `--` is longer than `-`, but typing speed shouldn't matter right?
      - tsimionescu 6y ago
        Sure, but the only reason to add an extra dash is to differentiate --long from -l -o -n -g. No reason to just add extra characters if ypu don't need this differentiation. Not to mention, Go cmd line parsing actually accepts both -long and --long, if you find the -- version more aesthetically pleasing.
  - cowl 6y ago
    If we only did "the accepted convention" indefinitely there would be no going forward. I see this change(of being explicit) as a win. The situation was already confusing before with different tools using different conventions. This way of being explicit allows you to be consistent across OS-s too. The world is not only GNU, fortunately.
GoblinSlayer 6y ago
Buffer overflows are well established too, not all traditions are good.