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

171–180 of 222 posts

Re: Unix command line conventions over time

#171

Post by somat »

I have an opinion on this, it is stupid but the more I think about it the more I am convinced I am right.

getopt is lipstick on a pig.

dashed argument are ugly and hard to read.

The worst offenders, programs that implement a language in the args. if you do this just build a proper parser and leave off the dashes. the worst offenders.

iptables find megacli

megacli, remember that? it was the control application for lsi megaraid cards, it was the program that turned me off getopt style args. when I figured out that the megacli parse let you drop the dashes(and the obnoxious capitalization) it was like a breath of fresh air in a fart filled room.

So a better way to do args? use dd style args. Yes dd, dd had it right all this time, I find "key=value" style args to be superior to "--key value" and don't even get me started on the absurdity of "--key=value"

Re: Unix command line conventions over time

#174

Post by onetom »

theamk wrote: post #149
onetom wrote: post #122

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

The double-dash is selected for pure practicality. Any option character excludes a set of inputs, and we want this set to be as small as possible. It is already hard to look at file named "-f" -- do you want to also make accessing files named ":f" (or even worse, "f:") harder? Thus the desire to keep the first "-". Now, they could have used "-:" or "-=" for long options.. but I think "--" won because it is so easy to…

btw, Rebol solved the mixing of options and filenames by introducing a syntax for file references; u prefix them with a percent sign, eg.:

%/c/plug-in/video.r

%//sound/goldfinger.mp3

%"/c/program files/qualcomm/eudora mail/out.mbx"

%c:/docs/file.txt

%\some\cool\movie.mpg %cool%20movie%20clip.mpg

Source: http://www.rebol.com/docs/core23/rebolcore-12.html#section-2...

then you could mix them with `:get-words` and `set-words:`. Rebol also had an interesting take on options - with and without arguments -; it called them refinements and you would just stack them with slashes onto the "command". the refinement arguments were added to the end of the parameter list though, so it was not exactly obvious which argument belonged to which refinement, but in practice it worked quite nice, surprisingly:

str: "test"

insert/dup/part str "this one" 4 5

print str

=> this this this this test

and reversing /dup and /part:

str: "test"

insert/part/dup str "this one" 4 5

print str

=> thisthisthisthisthistest

Source: http://www.rebol.com/docs/core23/rebolcore-9.html#section-2....

Re: Unix command line conventions over time

#175

Post by 1vuio0pswjnm7 »

Macha wrote: post #91
elteto wrote: post #70

Earlier quoted context omitted.

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

OpenBSD, which is a fork of NetBSD, is not the only "outlier".^1

For many years, NetBSD tar has autodetected bzip2 compression.

   tar xzf 1.tar.bz2
will work on gzip as well as bzip2. Whereas GNU tar still requires "j" instead^2

   tar xjf 1.tar.bz2
1. For example, FreeBSD or MacOS tar is BSD tar. It will autodetect bzip2 compression.

2. The GNU tar included with VoidLinux still requires z or j.

The pax(1) utility is the POSIX solution to these incompatibilities.

Re: Unix command line conventions over time

#176

Post by thfuran »

smcameron wrote: post #41
dredmorbius wrote: post #31

Earlier quoted context omitted.

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

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…

For safety, selecting arguments distinguished only by choice of two letters adjacent on the most common keyboard layout seems unwise.

Re: Unix command line conventions over time

#177

Post by 1vuio0pswjnm7 »

jiehong wrote: post #6

And then there is also the case of CLIs that aren’t written in C: they don’t get the benefits of a unified getopts lib. One oddity not explained is tar allowing multi options crammed together without any dash, that nobody can ever remember (eg. tar xvf archive.tar)

"... that nobody can ever remember."

Perhaps it comes down to what programs one uses routinely. Typing "tar xzf" multiple times per week I am unlikely to ever forget it.

Re: Unix command line conventions over time

#178

Post by cb321 »

yourad_io wrote: post #165
Macha wrote: post #91

Earlier quoted context omitted.

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.

Oh this is great, I remember z for gzip but always have to look up J vs j for bzip2/xz

With https://github.com/c-blake/nio/blob/main/utils/catz.nim you can get similar format agnostic decoding/decompression not just in tar but in any pipeline context based on magic numbers, not filename extensions and even doing the copy loop needed for unseekable inputs to replace the early read -- e.g. cat foo.gz|catz|less works..

Re: Unix command line conventions over time

#179

Post by lousyd »

Tijdreiziger wrote: post #79
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…

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

Maybe something like Jupyter? Text documents with sections of code or commands?

Re: Unix command line conventions over time

#180

Post by Maursault »

euroderf wrote: post #131
inopinatus wrote: post #34

Earlier quoted context omitted.

Still waiting for su —-with-wheel-group

I come not to bury wheel, but to praise it.

An industry big wheel, a wheel man with nice wheels, put shoulder to the wheel to put wheels in motion spinning wheels to reinvent the wheel before the wheels came off the wagon and squeaky wheel gets the grease. My name is Jonas. I'm carrying the wheel.
Post reply on HN