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.
Unix command line conventions over time
111–120 of 222 posts
Re: Unix command line conventions over time
#112Re: Unix command line conventions over time
#113Earlier 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.
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…
Re: Unix command line conventions over time
#115Earlier 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....
Re: Unix command line conventions over time
#116Earlier 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.
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
#117Earlier 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
#118Interesting 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.
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 /binRe: Unix command line conventions over time
#119I 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.
Re: Unix command line conventions over time
#120And 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.