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

81–90 of 222 posts

Re: Unix command line conventions over time

#81

Post by MontyCarloHall »

bfrankline wrote: post #74

I was at Bell during the options “debate.” I think something that this otherwise wonderful article misses is that some believed that commands were never intended to be the only way to use the system as the shell was intended to be just one of the many user interfaces that Research Unix would provide. From that perspective, it was entirely reasonable to believe that if a command was so complex that it needed options t…

>From that perspective, it was entirely reasonable to believe that if a command was so complex that it needed options than it was likely more appropriate for one of the other user interfaces

What would the non-shell interface to commands for text processing pipelining (e.g. sort, cut, grep, etc., all of which absolutely need options to function) have looked like? Some people to this day believe that any text processing more complicated than a simple grep or cut should be done in a stand-alone script written in a domain-specific language (e.g. Perl or awk), rather than piping shell commands to each other.

Personally, I’m glad we got the best of both worlds—having command line tools with a dizzying array of options doesn’t preclude being able to accomplish the same tasks with a more verbose stand-alone script. It is often far faster to write shell pipelines to accomplish fairly involved tasks than to write a stand-alone script. The classic example is the (in)famous McIlroy vs. Knuth: six lines of McIlroy’s shell pipeline accomplished the same thing as dozens of lines of Knuth’s “literate program,” while being equally as understandable [0].

>It’s a shame because McIlroy had a lot of interesting ideas around pipelining audio and graphics that, as far as I know, never materialized.

I would love to hear more about this. The UNIX shell is amazing for pipelining (most) things that are easily represented as text but really falls flat for pipelining everything else.

[0] https://leancrew.com/all-this/2011/12/more-shell-less-egg/

Re: Unix command line conventions over time

#82

Post by mort96 »

kevin_thibedeau wrote: post #78

GCC doesn't actually follow GNU conventions since it has both single hyphen and double hyphen long options.

I suspect GCC thinks of its options as mainly single-option short options and double-hyphen long options. It's reasonable to interpret things like `-funsafe-math-optimizations` to mean option `-f` with argument `unsafe-math-optimizations`, just like how `-Dfoo` means option `-D` with argument `foo`.

Unless you were thinking about something else.

Re: Unix command line conventions over time

#83

Post by mort96 »

protomikron wrote: post #66

Interesting is also find. It took me some time to accept that the directory must come first. E.g. find /path/to/dir -type f works, while find -type f /path/to/dir does not.

Probably helps to think of find as its own weird pipeline rather than a command with options. The first element of the pipeline is the directory(/directories), then `-type f` filters out all the non-files, then `-name '*.txt'` filters out everything which doesn't end in ".txt", etc. That also helps to remember why `-maxdepth` has to be right after the directory; it affects which files even become part of the pipeline, it doesn't make sense as a pipeline element.

The clearest proof that it's a pipeline is probably how it interacts with `-exec`: `find . -type d -exec echo {} \;` will print only directories, while `find . -exec echo {} \; -type d` will print both files and directories.

Regardless though, I sure wish they would let you specify the directories at the end.

Re: Unix command line conventions over time

#84

Post by spijdar »

sph wrote: post #58
nohackeratall wrote: post #45

And then you have ImageMagick where the order of flags and options is a science by itself.

Also ps. Everyone uses their own incantation and never strays from it. I use `ps aux` and used to use `ps -def` on Solaris. Some options require a dash, some don’t, it’s such a confusing CLI I never bothered to learn more. EDIT: also why is `ps` default output so useless? With no arguments it only prints a couple processes and that's it. I have no idea what it's supposed to show me. Talk about bad UX.

In case you're curious, the differences basically stem from BSD and Solaris/POSIX having different command syntaxes, and GNU/Linux's ps command trying to implement both. `ps -ef` is the Solaris syntax, while `ps aux` is from BSD.

Re: Unix command line conventions over time

#85

Post by elvis70 »

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 parameter names don't seem to match those of dd.

If you type man dd, the function of the tool will be described as "copy and convert". I can't find the video but there is an interview in which Kernighan, I think, explains that the tool should have been named cc but it was not possible because it was already taken by the c compiler.

Re: Unix command line conventions over time

#86

Post by megous »

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.

Sometimes I'm glad for public interface ossification. :)

Re: Unix command line conventions over time

#87

Post by mort96 »

mike_hock wrote: post #73
mort96 wrote: post #29

Earlier quoted context omitted.

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…

You're about to spawn a new process, you can't honestly be worried about a string allocation. The fact that this is cumbersome in C is fixed by fixing C, not by forcing a pattern onto the ecosystem that only makes sense to work around C's deficiencies.

I don't think C makes this especially cumbersome, most languages make it somewhat complicated to do format-printing (or string concatenation) into a stack-allocated buffer if it's big enough or fall back to heap-allocating a buffer if the stack buffer is too small.

The argument that you should just heap-allocate because it usually doesn't matter in contexts where you'd spawn a process anyways is a much better argument though. Still, I find the `{"whatever", "--config-file", config_file}` approach much more elegant.

Re: Unix command line conventions over time

#88

Post by mort96 »

jolmg wrote: post #36
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 mig…

I find it really confusing when `+x` is used to mean the opposite of `-x`. Usually, the `-x` option means "enable something", which is fine when you think of the "-" as a dash, but introducing `+x` encourages you to think of them as minus and plus; suddenly, in your command's language, "minus x" means "enable x" and "plus x" means "disable x", which makes very little sense.

The set command is a great example, "minus e" means "enable error checking" and "plus e" means "disable error checking". That doesn't make sense, that's not what minus and plus means.

Re: Unix command line conventions over time

#89

Post by mort96 »

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…

My favorite example: `cp -r` is recursive. `scp -r` is recursive. `chmod -r` removes read permissions; `chmod -R` is recursive.

Re: Unix command line conventions over time

#90

Post by tambourine_man »

bfrankline wrote: post #74

I was at Bell during the options “debate.” I think something that this otherwise wonderful article misses is that some believed that commands were never intended to be the only way to use the system as the shell was intended to be just one of the many user interfaces that Research Unix would provide. From that perspective, it was entirely reasonable to believe that if a command was so complex that it needed options t…

Very interesting. We’d love to read more on other media pipelining and alternatives to the shell.
Post reply on HN