Live data from Hacker News

Unix command line conventions over time

blog.liw.fi

111–120 of 222 posts

Re: Unix command line conventions over time

#111

If Apple made the transition to OS X in a position of strength, like the one it enjoys today, I think it may had imposed a pattern and rewritten tar, ps, dd, etc. However, the way history has unfolded, I think we’re stuck with this mess for good.

I mean, you really think its "position of strength" didn't come from it embracing Unix compatibility (which let it welcome the flood of web developers)?

Re: Unix command line conventions over time

#113

Earlier quoted context omitted.

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

For some reason, this seems to be vanishingly scarce knowledge in Linux / Unix circles. There was someone on HN a couple of weeks ago who was astounded to learn that "modem" means "modulator-demodulator." Like it was some kind of forbidden magic. Things that you an I consider entry-level knowledge are like scrolls and rune stones to tech people these days.

I had a similar experience, when ppl didn't know that codec comes from coder-decoder... It happened, when I called a Clojure namespace x.y.codec, with encode and decode functions in them. I've also noticed how some of my colleagues hasn't realized, that the Rust serde library is short for serialize-deserialize.

Re: Unix command line conventions over time

#114

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

Why would anyone remember those options? That’s what man pages are for. You only need to remember the ones that you use most often.

Re: Unix command line conventions over time

#115

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

More in this area:

http://www.catb.org/esr/faqs/things-every-hacker-once-knew/

Re: Unix command line conventions over time

#116

Earlier quoted context omitted.

For some reason, this seems to be vanishingly scarce knowledge in Linux / Unix circles. There was someone on HN a couple of weeks ago who was astounded to learn that "modem" means "modulator-demodulator." Like it was some kind of forbidden magic. Things that you an I consider entry-level knowledge are like scrolls and rune stones to tech people these days.

I'm old enough to have used modems and never heard the long name before.

You don't have to be a certain age to have used modems. You used one today to send that comment! Likely more than one.

Radio, cable, and fiber don't carry bits. They carry waves - analog signals - just like an old fashioned copper phone line. They all need a modulator-demodulator to convert between bits and waves.

Re: Unix command line conventions over time

#117
post #71

Earlier quoted context omitted.

> tar is a bit messy but the worst is definitely the worst. It has dash and non-dash options, and they don't have the same meaning and interact in a weird way. Sorry if it should be obvious, but "the worst is definitely the worst" … what is the worst? (Presumably not tar, unless I'm reading incorrectly.)

ps. By far the worst. Because it supports multiple syntax types I can never remember the ps command options. Even if you google for examples you get different syntax and end up with a mix of the same option letters doing different things in one command. It seems to lead to all sorts of subtly unexpected behaviors

    ps -ef | grep foo 
Is what I use 98% of the time.

Re: Unix command line conventions over time

#118

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.

I wrote a post about how to understand find syntax:

find and test: How To Read And Write Them

https://www.oilshell.org/blog/2021/04/find-test.html

tl;dr The args AFTER the root dir args form a boolean expression language -- I call it the "I'm too lazy to write a lexer" pattern

    find /tmp -type -f -a -name 'foo*'
test is the same way, e.g.

    test -f /tmp -a -f /bin

Re: Unix command line conventions over time

#119

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.

Yeah. I wonder if it looks anything like gstreamer...

Re: Unix command line conventions over time

#120
post #58

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.

Have you tried `ps faux`? :)
Post reply on HN