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

91–100 of 222 posts

Re: Unix command line conventions over time

#91

Post by Macha »

elteto wrote: post #70
LeoPanthera wrote: post #22

Earlier quoted context omitted.

> 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

> that nobody can ever remember These have gone a long way for me: tar xzf eXtract Zipped File tar czf Create Zipped File Anything more complicated and I have to google.

The `-z` on extract is not needed on basically most modern tar implementations (OpenBSD's is I believe the one outlier). tar -xf foo.tar.gz (or .xz, .bz2, .zst, etc.) will work, auto detect the archive type and extract.

Re: Unix command line conventions over time

#92

Post by eesmith »

lifthrasiir wrote: post #32
teddyh wrote: post #21

> Initially, GNU used the plus (+) to indicate a long option Some tools still use +options, like dig(1).

Also in some cases both -options and +options exist, where +options do the inverse of -options (e.g. dash; I think the old Perl 6 also did the same thing for sub MAIN, though it's now -/options) or a subtle but useful variation of -options (e.g. ImageMagick).

Or "tail", where "tail -12" is the last 12 lines and "tail +12" is everything after the first 12 lines.

Re: Unix command line conventions over time

#93

Post by Macha »

mort96 wrote: post #89
frederikvs wrote: post #28

Earlier quoted context omitted.

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.

`ssh -p` specifies a port number. `scp -p`/`sftp -p` copies the mtime. You need to use -P for the latter two.

Re: Unix command line conventions over time

#94

Post by floren »

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.

Regarding default ps output: remember how people were using Unix in the old days. Logged in via a text terminal on a multiuser system, 99% the only processes you care about are those associated with the current terminal, and that's what ps shows by default. You might have half a dozen backgrounded programs running in that terminal, but that's about it.

Now, my X sessions always have a dozen xterms running and plain ps isn't very useful, but it might break scripts if they changed it...

Re: Unix command line conventions over time

#96

Post by kevin_thibedeau »

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

Just go through the docs. They have a ton of single hyphen long opts that aren't a letter with argument.

Re: Unix command line conventions over time

#97

Post by [deleted] »

floren wrote: post #94
sph wrote: post #58

Earlier quoted context omitted.

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.

Regarding default ps output: remember how people were using Unix in the old days. Logged in via a text terminal on a multiuser system, 99% the only processes you care about are those associated with the current terminal, and that's what ps shows by default. You might have half a dozen backgrounded programs running in that terminal, but that's about it. Now, my X sessions always have a dozen xterms running and plain p…

[deleted]

Re: Unix command line conventions over time

#98

Post by sph »

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.

Re: Unix command line conventions over time

#99

Post by reaperducer »

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

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

#100

Post by sph »

kwijybo wrote: post #7
debdut wrote: post #3

> --mail=ADDR > The --email bit is a joke. what's the context of the joke?

Zawinski's Law of Software Envelopment, also known as Zawinski's Law, states: Every program attempts to expand until it can read mail.

Also the idea that GNU tools are bloated.
Post reply on HN