Why Do Long Options Start with Two Dashes?

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Access the most powerful time series database as a service
  • SaaSHub - Software Alternatives and Reviews
  • cobra

    A Commander for modern Go CLI interactions

    Cobra (https://github.com/spf13/cobra), which is a pretty popular library for Go CLI applications, behaves more like classical GNU tools. It also offers usage/help autogeneration and autocompletion for popular shells.

    Not sure about the relevant point on compact short options syntax as in `tar -xvzf archive.tgz` though...

  • tldr

    📚 Collaborative cheatsheets for console commands

    I guess you could consider https://github.com/tldr-pages/tldr.

    I personally wouldn't touch that, but that's related to my allergies to JS ecosystem and predisposition to panic attacks when I see stuff like that https://github.com/tldr-pages/tldr/blob/master/package-lock.....

  • InfluxDB

    Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.

  • gflags

    The gflags package contains a C++ library that implements commandline flags processing. It includes built-in support for standard types such as string and the ability to define flags in the source file in which they are used. Online documentation available at:

    Google's command line flags library, known to the public as absl::Flags and formerly gflags, does not distinguish between --foo and -foo, these are both the flag "foo". Each flag has a unique name so there is never a short -f equivalent to --foo, and -foo can never mean -f -o -o.

    The main design motivation of absl::Flags is that the flag definitions can appear in any module, not just main. Go inherits this. A quirk that Go did not inherit is gflags --nofoo alternate form of --foo=false.

    This is all documented at https://gflags.github.io/gflags/#commandline, which is pretty much a literal export of the flags package documentation that a Google engineer would see internally.

  • fd

    A simple, fast and user-friendly alternative to 'find'

    If anyone is looking for alternatives, try fd


  • tealdeer

    A very fast implementation of tldr in Rust.

    I've switched to tealdeer: same database, rust implementation.


  • freebsd-src

    The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests....

    It's saying that because it's using getopt to parse any initial option arguments. That diagnostic message you see printed the standard default message printed out by the getopt function whenever encountering invalid option flag.

    Judging by the usage message you printed, it's almost certainly the BSD implementation, probably macOS, which in turn probably syncs to the FreeBSD version. `find -name something` will failure early in main. See https://github.com/freebsd/freebsd-src/blob/b422540/usr.bin/... When processing the 'n' in '-name' getopt() will return '?', which will end up calling usage().

    The GNU implementation of find is completely different, though I'm not sure it does what you expect:

      $ find -name something

  • typer

    Typer, build great CLIs. Easy to code. Based on Python type hints.

    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/ ) 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.

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

  • rust

    Empowering everyone to build reliable and efficient software.

  • nushell

    A new type of shell

    To be fair, there is one shell that I think someday we could rely on. https://www.nushell.sh/ Besides that, my answer is "any programming language," since at the core, dealing properly with system calls and their outputs is the whole reason PL's exist. In practice, I've been using Rust lately which makes a nice systems language, but JS and Python are always options for shell-like scripts that don't suffer from quite the level of degeneracy when encountering weird filenames or unexpected input in general.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts