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

41–50 of 222 posts

Re: Unix command line conventions over time

#41

Post by smcameron »

dredmorbius wrote: post #31
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-...

Huh. I'd always kind of guessed that dd used if=input-file of=output-file as a way to sort of prevent the use of shell globbing and to not rely on the order of arguments (as cp does) since dd as it is often used can be a bit dangerous (I often found myself using it with disk device files) and you want to be extra careful in specifying the input and especially the output files.

Edit: wikipedia agrees with your IBM origin story https://en.wikipedia.org/wiki/Dd_(Unix)#History

Re: Unix command line conventions over time

#43

Post by dredmorbius »

smcameron wrote: post #41
dredmorbius wrote: post #31

Earlier quoted context omitted.

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

Huh. I'd always kind of guessed that dd used if=input-file of=output-file as a way to sort of prevent the use of shell globbing and to not rely on the order of arguments (as cp does) since dd as it is often used can be a bit dangerous (I often found myself using it with disk device files) and you want to be extra careful in specifying the input and especially the output files. Edit: wikipedia agrees with your IBM ori…

The syntax is common to most JCL ("job control language") commands. I'd say "all", though there are probably exceptions.

For some reason, this seems to be vanishingly scarce knowledge in Linux / Unix circles.

There was a time in my life I knew how to spell JCL....

Re: Unix command line conventions over time

#44

Post by smcameron »

frederikvs wrote: post #28
bluenose69 wrote: post #14

> 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 inte…

I don't think remembering rm is the issue. It's remembering all the options in all their variations. Take the ps command. I tend to use it as "ps aux" - but I have no idea what the a, the u, or the x stand for individually. I know other people who use "ps -ef". (Also note the difference : the aux doesn't require a dash, and if you accidentally put it in, it doesn't do what you want it to do.) As another example : the…

The "aux" vs "ef" thing is a Berkeley vs. System V unix thing. SunOS wanted "aux", while Solaris wanted "-ef", iirc. Linux ps will do either. From the man page:

       This version of ps accepts several kinds of options:

       1   UNIX options, which may be grouped and must be preceded by a dash.

       2   BSD options, which may be grouped and must not be used with a dash.

       3   GNU long options, which are preceded by two dashes.
And:

Note that "ps -aux" is distinct from "ps aux". The POSIX and UNIX standards require that "ps -aux" print all processes owned by a user named "x", as well as printing all processes that would be selected by the -a option. If the user named "x" does not exist, this ps may interpret the command as "ps aux" instead and print a warning.

Edit: On my system, "ps -aux" does the same thing as "ps aux" and no warning is printed, despite the what the man page says. I'm not going to try to create a user named 'x' though.

Re: Unix command line conventions over time

#47

Post by nsajko »

LeoPanthera wrote: post #22
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)

> One oddity not explained is tar allowing multi options crammed together without any dash, that nobody can ever remember (eg. tar xvf archive.tar) This is a BSDism, and it's deprecated even there. bsdtar allows it for compatibility with old scripts. GNUtar has long-switches for all options, which makes it considerably easier to use and understand, for example: gtar --create --file etc.tar --verbose /etc

> This is a BSDism

No, it was like that when Tar was first introduced, as part of Seventh Edition Unix:

https://man.cat-v.org/unix_7th/1/tar

https://en.wikipedia.org/wiki/Tar_(computing)

Re: Unix command line conventions over time

#49

Post by jbverschoor »

mort96 wrote: post #29
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.

I disagree with getting rid of `--long x`. It's really common to build command argvs programmatically, where you have a string representing some option (such as a file path), and you need to pass that as a long option. With `--long x`, you can do like: char *argv[] = {"my-program", "--config-file", config_file, NULL}; run_command(argv); With only `--config-file=x`, you would have to allocate memory for the option: ch…

If all of this matters so much, don’t use an (interactive) shell.
Post reply on HN