Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix command line conventions over time

blog.liw.fi

Post reply on HN
Print view View original

31–40 of 222 posts

Re: Unix command line conventions over time

#31

Post by dredmorbius »

pseudostem wrote: post #4

Unix history is always fascinating. >None of this explains dd. This one really made me think. I have never thought about dd before. Although I have wondered about other commands. Perhaps the author should also have added some command options not requiring a minus prefix, e.g. tar, ps. The manpage [0] reads: In the first (legacy) form, all option flags except for -C and -I must be contained within the first argument t…

dd is a mainframe command, and its syntax follows the JCL conventions used there.

https://www.ibm.com/docs/en/zos-basic-skills?topic=concepts-...

Re: Unix command line conventions over time

#32

Post by lifthrasiir »

teddyh wrote: post #21

> Initially, GNU used the plus (+) to indicate a long option Some tools still use +options, like dig(1).

Also in some cases both -options and +options exist, where +options do the inverse of -options (e.g. dash; I think the old Perl 6 also did the same thing for sub MAIN, though it's now -/options) or a subtle but useful variation of -options (e.g. ImageMagick).

Re: Unix command line conventions over time

#33

Post by jolmg »

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

It also has the advantage that it works with brace expansion to specify multiple values.

--long={foo,bar}

becomes

--long=foo --long=bar

Re: Unix command line conventions over time

#34

Post by inopinatus »

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.

Still waiting for su —-with-wheel-group

Re: Unix command line conventions over time

#35

Post by kzrdude »

jolmg wrote: post #33
conaclos wrote: post #16

Earlier quoted context omitted.

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

It also has the advantage that it works with brace expansion to specify multiple values. --long={foo,bar} becomes --long=foo --long=bar

Thanks for teaching something useful!

Re: Unix command line conventions over time

#36

Post by jolmg »

teddyh wrote: post #11

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

I like the use of + to mean the opposite of single dash short options, like with shell options, e.g. `set -e` vs `set +e`.

For long options, there's the convention of `--no-foo` meaning the opposite of `--foo`, but `+e` hasn't really caught on for short options besides the shell ones.

Being able to negate options, letting the last one win, is useful to be able to define default options in aliases. For example, it might be useful to be able to do this:

  $ alias less='less -X'
  $ less +X foo.txt
or

  $ alias grep='grep -n'
  $ grep +nH -r foo *

Re: Unix command line conventions over time

#37

Post by ducktective »

Speaking of CLI option/argument handling for shell scripts, I use getopts for simple scripts which have few switches and manual loop when I want to support long options.

1- short: http://mywiki.wooledge.org/BashFAQ/035#getopts

2- long: http://mywiki.wooledge.org/BashFAQ/035#Manual_loop

I don't support `--option=` mode. I don't support giving options after arguments. I prepend info and errors with braces like : `[TAG] message` and print them to STDERR.

Opinions?

Re: Unix command line conventions over time

#38

Post by conaclos »

jolmg wrote: post #33
conaclos wrote: post #16

Earlier quoted context omitted.

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

It also has the advantage that it works with brace expansion to specify multiple values. --long={foo,bar} becomes --long=foo --long=bar

With bash/zsh the auto-completion seems missing for unknown options. While `--key file` supports auto-completion since file is just another parameter.

Re: Unix command line conventions over time

#39

Post by jolmg »

conaclos wrote: post #38
jolmg wrote: post #33

Earlier quoted context omitted.

It also has the advantage that it works with brace expansion to specify multiple values. --long={foo,bar} becomes --long=foo --long=bar

With bash/zsh the auto-completion seems missing for unknown options. While `--key file` supports auto-completion since file is just another parameter.

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.

Post reply on HN