Unix command line conventions over time • Hacker News Board

Re: Unix command line conventions over time

#11

Post by teddyh » Sat, May 07, 2022, 9:44 AM UTC

> Initially, GNU used the plus (+) to indicate a long option, but quickly changed to a double dash (--).

IIRC, they liked the plus, but changed to use the double dash to be POSIX compatible (which presumably requires options to be preceded by a dash).

Re: Unix command line conventions over time

#12

Post by theden » Sat, May 07, 2022, 9:45 AM UTC

There are alternatives to dd like ddrescue (https://wiki.archlinux.org/title/disk_cloning#Block-level_cl...), but given it's standard on all *nix machines it's hard to avoid, just need to be extra careful before executing. There are also wrappers for dd, like ddi (https://github.com/tralph3/ddi) for extra safety

Re: Unix command line conventions over time

#13

Post by conaclos » Sat, May 07, 2022, 9:49 AM UTC

I pretty like the consistency of esbuild CLI [1]. It has three kinds of options:

1. no-valued option: --example 2. single-valued option: --key=value 3. multi-valued option: --elements:1st --elements:2nd

Short options are ruled out, although it accepts the short option -h for discoverability.

I particularly like the repeated option pattern for multi-valued options. This avoids ambiguities such as:

  cli --elements 1st 2nd arg

Yes, the ambiguity may be removed by using doubled dashes. However, this is error-prone.

I often wondering whether a more familiar syntax for the second and third kinds could be adopted. For instance:

  --key value
  --elements 1st --elements 2nd

[1] https://github.com/evanw/esbuild

Re: Unix command line conventions over time

#14

Post by bluenose69 » Sat, May 07, 2022, 9:50 AM UTC

> we could introduce a completely new syntax that is systematic, easy to remember

Is it really difficult to learn that e.g. "rm" stands for "remove"? I've known very few people who found it difficult to learn the key things very quickly.

And not having to type (and spell) full words is a relief. (I know a shell can take care of spelling, but not all unix commands are entered interactively.)

Still, the article is interesting, and worth reading.

Re: Unix command line conventions over time

#15

Post by teddyh » Sat, May 07, 2022, 9:51 AM UTC

jiehong wrote: post #6

And then there is also the case of CLIs that aren’t written in C: they don’t get the benefits of a unified getopts lib. One oddity not explained is tar allowing multi options crammed together without any dash, that nobody can ever remember (eg. tar xvf archive.tar)

Or ps, with its BSD and SysV variants. On Linux, the most widely used version of ps uses BSD semantics when using options without a dash, and SysV semantics for dashed options. Thus, both BSD “ps aux” and SysV “ps -fel” work.

Re: Unix command line conventions over time

#16

Post by conaclos » Sat, May 07, 2022, 9:52 AM UTC

kzrdude wrote: post #9

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. One of --long x and --long=x have to go, and that means we only can keep --long=x. And so on.

> that means we only can keep --long=x

Just wondering: why `--long=x` over `--long x`?

Re: Unix command line conventions over time

#17

Post by teddyh » Sat, May 07, 2022, 9:54 AM UTC

> GNU also added standard options: almost every GNU program supports the options --help, --version

GNU keeps a list of them, so that anyone implementing a similar functionality should use the same option if it already exists:

https://www.gnu.org/prep/standards/standards.html#Option-Tab...

Re: Unix command line conventions over time

#18

Post by grose » Sat, May 07, 2022, 9:55 AM UTC

conaclos wrote: post #16

kzrdude wrote: post #9

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. One of --long x and --long=x have to go, and that means we only can keep --long=x. And so on.

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

`--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.

Re: Unix command line conventions over time

#19

Post by kzrdude » Sat, May 07, 2022, 9:55 AM UTC

conaclos wrote: post #16

kzrdude wrote: post #9

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. One of --long x and --long=x have to go, and that means we only can keep --long=x. And so on.

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

--long=x supports the simultaneous --color and --color=auto usecase, i.e the value is optional. Without = it's ambiguous.

Re: Unix command line conventions over time

#20

Post by [deleted] » Sat, May 07, 2022, 9:58 AM UTC

conaclos wrote: post #16

kzrdude wrote: post #9

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. One of --long x and --long=x have to go, and that means we only can keep --long=x. And so on.

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

[deleted]