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

121–130 of 222 posts

Re: Unix command line conventions over time

#121

Post by leokennis »

dredmorbius wrote: post #43
smcameron wrote: post #41

Earlier quoted context omitted.

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

I started my IT career by accident on a mainframe system: JCL, COBOL, CICS, DB2.

When I made the switch to working on a JAVA application running on Linux I had a hard time accepting how easy a lot of stuff was.

Re: Unix command line conventions over time

#122

Post by onetom »

It's interesting, that no one questioned the use of double dash itself.

It looks especially silly, when long options are used to encode some mini programming language (DSL), like in imagemagick and ffmpeg, or when they are used to represent some associative data, like in case of the AWS CLI.

If -- would be a : AFTER the option name, it would look like Objective C named arguments or set-words in REBOL and Red.

If -- would be a : BEFORE the option name, it would look like keywords in Lisps.

As a side-note, shells got quite evolved, actually, but the momentum of the mediocre bash-line prevailed, sadly.

I urge people to learn about es, the Extensible Shell: https://wryun.github.io/es-shell/

Its ancestor, the Plan 9 rc (which I think stands for Run Command) and it used "; " as a prompt, so u could combine multiple commands easier, by copy-pasting whole lines, instead of fiddling with the exclusion of the varying length prompt.

Both of these shells have a lot better string quoting rules than bash, so they play nicer with filenames containing special characters.

They also follow the unix philosophy closer, by not necessarily providing line editing capabilities, which can be added by running them thru eg. rlwrap or not really needed, when running them from Emacs or Plan 9's acme environment.

I would also highlight, that es is just 163KB, while bash is 1.3MB, yet it provides a magnitudes more powerful, dynamic, garbage collected, functional programming language!

Re: Unix command line conventions over time

#123

Post by lou1306 »

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…

The best explanation for leaving dd in its original form is that it's not really wise to alter the behaviour of a tool that has been nicknamed "destroyer of disks", regardless of that hot new CLI convention.

Re: Unix command line conventions over time

#124

Post by woodruffw »

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…

I'll add another minor reason: `--foo="bar"` (with quotes) relies on the quoting/splitting behavior of the shell, which is easy to forget.

For example, someone might write:

    args = [cmd, f'--foo="{foo}"']
and expect the surrounding quotes to be stripped off, but that'll only happen if the spawn goes through a shell first. Some argument parsers may also try to strip quotes off, but I don't believe there's any consistent behavior guaranteed around that.

Re: Unix command line conventions over time

#125

Post by daptaq »

imwillofficial wrote: post #107
Tijdreiziger wrote: post #79

Earlier quoted context omitted.

Interesting, any chance you could expand on these 'other user interfaces'? I'm not really familiar with Unix itself, but I've always considered Linux a shell-first OS (as opposed to Windows (NT), which I consider a GUI-first OS).

A shell is just how you interact with the underlying system. The gui is also a shell. Confusing I know!

I like to see it this way: A shell /wraps/ the kernel. You cannot issue system calls directly, but a program that handles user input generically (and ideally dynamically), can do this for you. A desktop environment, Emacs, and to an increasing degree web browsers are all different "shells".

Re: Unix command line conventions over time

#126

Post by edgyquant »

imwillofficial wrote: post #107
Tijdreiziger wrote: post #79

Earlier quoted context omitted.

Interesting, any chance you could expand on these 'other user interfaces'? I'm not really familiar with Unix itself, but I've always considered Linux a shell-first OS (as opposed to Windows (NT), which I consider a GUI-first OS).

A shell is just how you interact with the underlying system. The gui is also a shell. Confusing I know!

E.g. the Windows GUI is the “Windows Shell,” not be confused with the Windows Command Line which is one (well, many) application within the shell.

Re: Unix command line conventions over time

#127

Post by archduck »

blacklion wrote: post #110

Example in "Early 1970s" is notoriously bad. Text says: "it would be given some number of filenames as command line arguments, and it would read those ... Options didn’t exist". Example shows: unneeded usage of `cat` as if `wc` is non-standard utility and cannot process file names by itself, option for `wc` is used. It contradicts text in both ways!

Is there any actual, useful, worthwhile reason for avoiding useless `cat` though?

Re: Unix command line conventions over time

#128

Post by daptaq »

sph wrote: post #98
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 am annoyed go's flags package did not respect the GNU convention for options, which I agree is the best.

I am not too surprised that the confluence point between Plan 9 and Google have little interest in following the GNU way.

Re: Unix command line conventions over time

#129

Post by euroderf »

sph wrote: post #98
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 am annoyed go's flags package did not respect the GNU convention for options, which I agree is the best.

Try github.com/spf13/pflag, it handles double-dash arguments OK, and is drop-in.

Re: Unix command line conventions over time

#130

Post by butlerm »

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

The name of dd(1) may have some tenuous connection to the JCL DD statement, but otherwise any similarity seems virtually non-existent. They don't even remotely do the same thing, none of the options or parameters are the same or have similar meanings, or anything like that.

https://man7.org/linux/man-pages/man1/dd.1.html

Post reply on HN