10 ms·

It is sad that many new command-line parsing libraries don't follow the GNU rules anymore. They more often use "-long". Then users have to figure out whether th

It is sad that many new command-line parsing libraries don't follow the GNU rules anymore. They more often use "-long". Then users have to figure out whether this means "--long" or "-l -o -n -g". To make command line even more confusing, multiple tools I have used allow spaces in optional arguments (e.g. "-opt1 arg1 arg2 -opt2", where arg1 and arg2 set two values for -opt1). Every time I see this, I worry if I could be misusing these tools. I wish everyone could just follow getopt_long() and stop inventing their own weird syntax.

echlebek 6y ago
They are just respecting older, more venerable tools, like find.
- antihero 6y ago
  Find's syntax is really annoying and clashy too. It makes sense. -- for extended syntax and - for shorthand. Why can't it follow this. Also fuck dd
  - antegamisou 6y ago
    Same with ffmpeg
  - j-james 6y ago
    dd I really don't mind, because it makes me think and double-check that I'm flashing the right device every time. find is annoying, though. I'd encourage you to check out fd. https://github.com/sharkdp/fd https://github.com/sharkdp/fd
    - antihero 6y ago
      Ah, thank you very much!
  - kazinator 6y ago
    I'd like a word with the person who thought that regular ( ) parentheses for grouping were a good idea in the find syntax, requiring them to be backslash-escaped in shell scripts. The obviously right choice would have been [ ]. You know, like in if [ $foo ... ]
    - spc476 6y ago
      That won't work because '[' is an alias for test.
      - jlokier 6y ago
        "[" as an argument to another command is fine. "[" is just another name for the "test" command. It isn't special syntax.
      - deleted 6y ago
        [deleted]
  - scbrg 6y ago
    It's pretty silly to ask a command written in the seventies(?) to follow a convention (for another operating system) presented in the nineties.
ben0x539 6y ago
Yet another tragedy broughtabout by golang (at least in part)! :) (https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax) Edit: To be clear, I'm mostly "blaming" Go for re-popularizing this style by a) putting it in the standard library and b) being a widely used programming language; I'm not saying Go came up with this or anything. (idk about the space separated args tho that's even worse)
- ericbarrett 6y ago
  It's really a Googleism that was inherited by Go. I remember their open source C++ command-line library did the same thing.
  - kevinmgranger 6y ago
    It's originally from Plan9, which predates Google.
    - naikrovek 6y ago
      too few people understand this. Go was designed by former Bell Labs people who worked on Unix, Plan9, or both. many things about Go that people attribute to "googlism" is really attributable to work done at Bell Labs.
      - QuercusMax 6y ago
        In my experience at Google, only Go does flags like this. Everything else (python, java, c++, blaze) all use the same flag syntax, which is all via long args with two dashes.
        ben0x539 6y ago
        This seems pretty "standard": https://fuchsia.googlesource.com/fuchsia/+/master/docs/concepts/api/cli.md#command-line-arguments https://fuchsia.googlesource.com/fuchsia/+/master/docs/conce... Is it based on Google's internal preferences?
k__ 6y ago
Really? I had the impression only CLI tools from the Java world are that strange.
- mrits 6y ago
  Yes, I messed up -Xmx1024m a million times in my career. We used GNU for in-house stuff so sometimes I'd have --Xmx and -Xmx on the same line
deleted 6y ago
[deleted]
bastawhiz 6y ago
GCC does this pretty heavily, no? https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html If it mattered much, I'd expect GNU to be internally consistent.
- avar 6y ago
  GCC or anyone else's C compiler doesn't really count as far as this convention goes. GCC's flag parsing is aiming to be compatible with conventions that preceded GNU, other vendor's compilers break their own conventions to be compatible with GCC or whatever else cc(1) is etc. GNU's conventions are generally complimentary, but not incompatible with POSIX. And POSIX specifies the behavior of the sort of flags cc(1) should understand[1]. There are many POSIX and other traditional *nix tools that are a convention unto themselves for historical reasons. E.g. notice how GNU "dd" doesn't follow normal GNU command-line conventions either. 1. https://pubs.opengroup.org/onlinepubs/7908799/xcu/cc.html https://pubs.opengroup.org/onlinepubs/7908799/xcu/cc.html
bcrl 6y ago
The Amiga had a pretty cool feature where CLI argument parsing and help was provided via a library. This made things nicely consistent across almost all of the CLI tools.
- asveikau 6y ago
  Suddenly I'm reminded of how Windows represents the command line as a single string (PWSTR), and how entry points that expect argv-style are parsed by the CRT at startup. vs. Unix where char *argv[] is what makes it to the syscall layer. The result there is that command line processing is more consistent program-to-program on Unix. On Windows, every program could decide to tokenize the arguments differently.
  - account42 6y ago
    > On Windows, every program could decide to tokenize the arguments differently. Worse, even Microsofts two implementations (CRT and WINAPI) disagree: https://github.com/rust-lang/rust/issues/44650 https://github.com/rust-lang/rust/issues/44650
    - asveikau 6y ago
      I feel like there are a few interesting Microsoft phenomena that contrast with Unix thinking in both of these examples. CommandLineToArgvW - You called that "WINAPI", but it's worth mentioning the more specific provenance of shlwapi.dll. This is not a core, foundational part of Windows that is used in core, foundational things. It's a helper function from the shell (explorer, not shell in the Unix sense). So, while it has a look and function that seems pretty foundational, it really isn't. It's there because somebody working on Explorer long ago found that useful to have and decided to export their helper function in the DLL. CRT - A CRT binary ships with Windows, but really, that code is maintained and distributed by the compiler guys and DevDiv. So theoretically, the argv parser could change at those people's whim alongside a new Visual Studio release. And it seems from squinting at that github issue like that might have happened here. So really ... there are more artifacts here attesting to the fact that the command line arg parser is not part of the operating system. People find that functionality useful, so they look for things that "look like" the operating system official method, and maybe they find stuff that does "look like it" -- but such a thing isn't really there.
chrisweekly 6y ago
yeah; long w --, short w - is intuitive and annoyingly close to universal...
sillysaurusx 6y ago
-long = -l -o -n -g was probably a mistake. But then again, tar xvzf should have been called untar, so it’s not like there are a shortage of opinions and historical mistakes.
- necovek 6y ago
  How would one call tar `xvjf` then?
  - lightbulbjim 6y ago
    You can just call ‘tar xvf’ and it will detect the compression format.
    - necovek 6y ago
      My question was about how "tar xvzf" should be called "untar". Your reply might still make sense (i.e. untar could automagically figure it out), but I was highlighting how tar/untar today also means (de)compressing that tar archive using many different compression formats.
      - nicoburns 6y ago
        It should probably be `untar --format gzip`
hzhou321 6y ago
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.
        6y ago
KronisLV 6y ago
In my experience, i had never actually stumbled upon a formal list of these "GNU rules", the closest thing i can find is this: https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html https://www.gnu.org/software/libc/manual/html_node/Argument-... However, even those seem to raise some questions, for example: > To make command line even more confusing, multiple tools I have used allow spaces in optional arguments (e.g. "-opt1 arg1 arg2 -opt2", where arg1 and arg2 set two values for -opt1). Is described as something that's permissible: > An option and its argument may or may not appear as separate tokens. (In other words, the whitespace separating them is optional.) Thus, ‘-o foo’ and ‘-ofoo’ are equivalent. Therefore the below would be considered equivalent: -opt1 arg1 arg2 -opt2 -opt1arg1arg2 -opt2 Were your expectations different? Are there any good articles on the benefits of following such rules (any fungible improvements to legibility or usability, as opposed to just "consistency amongst different tools")? Are there any tools which can validate whether any piece of software conforms to this standard (either by scanning the man pages, or the code, or a formalized format of parameters the app supports)? Personally, the closest i've found is Typer ( https://typer.tiangolo.com/ https://typer.tiangolo.com/ ) but without anything that can automatically reject non-conformant code as a part of a CI process, i think enforcing such formats would be a non-starter for me.

echlebek 6y ago

They are just respecting older, more venerable tools, like find.

antihero 6y ago
Find's syntax is really annoying and clashy too. It makes sense. -- for extended syntax and - for shorthand. Why can't it follow this. Also fuck dd
- antegamisou 6y ago
  Same with ffmpeg
- j-james 6y ago
  dd I really don't mind, because it makes me think and double-check that I'm flashing the right device every time. find is annoying, though. I'd encourage you to check out fd. https://github.com/sharkdp/fd https://github.com/sharkdp/fd
  - antihero 6y ago
    Ah, thank you very much!
- kazinator 6y ago
  I'd like a word with the person who thought that regular ( ) parentheses for grouping were a good idea in the find syntax, requiring them to be backslash-escaped in shell scripts. The obviously right choice would have been [ ]. You know, like in if [ $foo ... ]
  - spc476 6y ago
    That won't work because '[' is an alias for test.
    - jlokier 6y ago
      "[" as an argument to another command is fine. "[" is just another name for the "test" command. It isn't special syntax.
    - deleted 6y ago
      [deleted]
- scbrg 6y ago
  It's pretty silly to ask a command written in the seventies(?) to follow a convention (for another operating system) presented in the nineties.

ben0x539 6y ago

Yet another tragedy broughtabout by golang (at least in part)! :) (https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax https://golang.org/pkg/flag/#hdr-Command_line_flag_syntax) Edit: To be clear, I'm mostly "blaming" Go for re-popularizing this style by a) putting it in the standard library and b) being a widely used programming language; I'm not saying Go came up with this or anything. (idk about the space separated args tho that's even worse)

ericbarrett 6y ago
It's really a Googleism that was inherited by Go. I remember their open source C++ command-line library did the same thing.
- kevinmgranger 6y ago
  It's originally from Plan9, which predates Google.
  - naikrovek 6y ago
    too few people understand this. Go was designed by former Bell Labs people who worked on Unix, Plan9, or both. many things about Go that people attribute to "googlism" is really attributable to work done at Bell Labs.
    - QuercusMax 6y ago
      In my experience at Google, only Go does flags like this. Everything else (python, java, c++, blaze) all use the same flag syntax, which is all via long args with two dashes.
      - ben0x539 6y ago
        This seems pretty "standard": https://fuchsia.googlesource.com/fuchsia/+/master/docs/concepts/api/cli.md#command-line-arguments https://fuchsia.googlesource.com/fuchsia/+/master/docs/conce... Is it based on Google's internal preferences?

k__ 6y ago

Really? I had the impression only CLI tools from the Java world are that strange.

mrits 6y ago
Yes, I messed up -Xmx1024m a million times in my career. We used GNU for in-house stuff so sometimes I'd have --Xmx and -Xmx on the same line

deleted 6y ago

[deleted]

bastawhiz 6y ago

GCC does this pretty heavily, no? https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html If it mattered much, I'd expect GNU to be internally consistent.

avar 6y ago
GCC or anyone else's C compiler doesn't really count as far as this convention goes. GCC's flag parsing is aiming to be compatible with conventions that preceded GNU, other vendor's compilers break their own conventions to be compatible with GCC or whatever else cc(1) is etc. GNU's conventions are generally complimentary, but not incompatible with POSIX. And POSIX specifies the behavior of the sort of flags cc(1) should understand[1]. There are many POSIX and other traditional *nix tools that are a convention unto themselves for historical reasons. E.g. notice how GNU "dd" doesn't follow normal GNU command-line conventions either. 1. https://pubs.opengroup.org/onlinepubs/7908799/xcu/cc.html https://pubs.opengroup.org/onlinepubs/7908799/xcu/cc.html

bcrl 6y ago

The Amiga had a pretty cool feature where CLI argument parsing and help was provided via a library. This made things nicely consistent across almost all of the CLI tools.

asveikau 6y ago
Suddenly I'm reminded of how Windows represents the command line as a single string (PWSTR), and how entry points that expect argv-style are parsed by the CRT at startup. vs. Unix where char *argv[] is what makes it to the syscall layer. The result there is that command line processing is more consistent program-to-program on Unix. On Windows, every program could decide to tokenize the arguments differently.
- account42 6y ago
  > On Windows, every program could decide to tokenize the arguments differently. Worse, even Microsofts two implementations (CRT and WINAPI) disagree: https://github.com/rust-lang/rust/issues/44650 https://github.com/rust-lang/rust/issues/44650
  - asveikau 6y ago
    I feel like there are a few interesting Microsoft phenomena that contrast with Unix thinking in both of these examples. CommandLineToArgvW - You called that "WINAPI", but it's worth mentioning the more specific provenance of shlwapi.dll. This is not a core, foundational part of Windows that is used in core, foundational things. It's a helper function from the shell (explorer, not shell in the Unix sense). So, while it has a look and function that seems pretty foundational, it really isn't. It's there because somebody working on Explorer long ago found that useful to have and decided to export their helper function in the DLL. CRT - A CRT binary ships with Windows, but really, that code is maintained and distributed by the compiler guys and DevDiv. So theoretically, the argv parser could change at those people's whim alongside a new Visual Studio release. And it seems from squinting at that github issue like that might have happened here. So really ... there are more artifacts here attesting to the fact that the command line arg parser is not part of the operating system. People find that functionality useful, so they look for things that "look like" the operating system official method, and maybe they find stuff that does "look like it" -- but such a thing isn't really there.

chrisweekly 6y ago

yeah; long w --, short w - is intuitive and annoyingly close to universal...

sillysaurusx 6y ago

-long = -l -o -n -g was probably a mistake. But then again, tar xvzf should have been called untar, so it’s not like there are a shortage of opinions and historical mistakes.

necovek 6y ago
How would one call tar `xvjf` then?
- lightbulbjim 6y ago
  You can just call ‘tar xvf’ and it will detect the compression format.
  - necovek 6y ago
    My question was about how "tar xvzf" should be called "untar". Your reply might still make sense (i.e. untar could automagically figure it out), but I was highlighting how tar/untar today also means (de)compressing that tar archive using many different compression formats.
    - nicoburns 6y ago
      It should probably be `untar --format gzip`

hzhou321 6y ago

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.
      - 6y ago

KronisLV 6y ago

In my experience, i had never actually stumbled upon a formal list of these "GNU rules", the closest thing i can find is this: https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html https://www.gnu.org/software/libc/manual/html_node/Argument-... However, even those seem to raise some questions, for example: > To make command line even more confusing, multiple tools I have used allow spaces in optional arguments (e.g. "-opt1 arg1 arg2 -opt2", where arg1 and arg2 set two values for -opt1). Is described as something that's permissible: > An option and its argument may or may not appear as separate tokens. (In other words, the whitespace separating them is optional.) Thus, ‘-o foo’ and ‘-ofoo’ are equivalent. Therefore the below would be considered equivalent: -opt1 arg1 arg2 -opt2 -opt1arg1arg2 -opt2 Were your expectations different? Are there any good articles on the benefits of following such rules (any fungible improvements to legibility or usability, as opposed to just "consistency amongst different tools")? Are there any tools which can validate whether any piece of software conforms to this standard (either by scanning the man pages, or the code, or a formalized format of parameters the app supports)? Personally, the closest i've found is Typer ( https://typer.tiangolo.com/ https://typer.tiangolo.com/ ) but without anything that can automatically reject non-conformant code as a part of a CI process, i think enforcing such formats would be a non-starter for me.