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

151–160 of 222 posts

Re: Unix command line conventions over time

#151

Post by gumby »

The double dash was indeed from the GNU project and specifically RMS (though I think it was at the recommendation of someone else whose name I am blanking on). This followed an earlier GNU approach, also from RMS, of using + to signal long options.

The idea, though not the syntax, came from the installation of a TOPS-20 machine and some VMS machines on a lower floor. Our own homegrown OS (ITS) used control characters as commands and had DDT as a shell.

> In the beginning, in the first year or so of Unix, an ideal was formed for what a Unix program would be like…

Note that the approach you’re talking about came straight from the Multics of that era, though Multics already supported some short options at that time.

> None of this explains dd.

Because just as Unix in many ways copied Multics, the dd command copied IBM.

Re: Unix command line conventions over time

#152

Post by layer8 »

jlarocco wrote: post #136
MontyCarloHall wrote: post #81

Earlier quoted context omitted.

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

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

A general tool for that workflow is vipe: https://github.com/juliangruber/vipe

Re: Unix command line conventions over time

#154

Post by bfrankline »

jancsika wrote: post #137
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…

> 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. Do you know if those ideas are documented anywhere?

The most popular today outside of the shell environment is the statistical environment “S.” John Chambers would recreate it as “R” and I understand that it’s very popular and does a nice job of performing statistics and graphics together.

Re: Unix command line conventions over time

#155

Post by kergonath »

LeoPanthera wrote: post #22
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)

> 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

> gtar --create --file etc.tar --verbose /etc

That’s considerably more cumbersome than tar -cvf.

Re: Unix command line conventions over time

#156

Post by bfrankline »

tambourine_man wrote: post #90
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.

It was very primitive. It was essentially a mechanism for composing operations on vectors. I don’t know for certain but I would guess that it was inspired by IBM and their work on APL.

Re: Unix command line conventions over time

#157

Post by kitschyred »

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.

> Talk about bad UX.

I think you could say this for CLIs in general. While we can all agree that the CLI is great for tasks that require repetition; it's just a PITA for any one-time task. When you just need to do something once and as soon as possible, the manual-help-type-run loop gets tiresome quickly.

Passing options to a program so it can do what most users would want it to do in the first place is nonsensical, and yet that describes the behaviour of many if not all of *nix's tools. It should be the other way around: do what is expected by default, and provide options for different, more uncommon use-cases. Though I suppose this is also a form of baggage from the past that it's very difficult to get rid off because of backwards compatibility.

Re: Unix command line conventions over time

#158

Post by layer8 »

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’m curious why they introduced the ‘=‘ variant at all. Maybe they thought it would be clearer for human readers?

Re: Unix command line conventions over time

#159

Post by ElevenLathe »

archduck wrote: post #127
blacklion wrote: post #110

Example in "Early 1970s" is notoriously bad. Text says: "it would be given some number of filenames as command line arguments, and it would read those ... Options didn’t exist". Example shows: unneeded usage of `cat` as if `wc` is non-standard utility and cannot process file names by itself, option for `wc` is used. It contradicts text in both ways!

Is there any actual, useful, worthwhile reason for avoiding useless `cat` though?

I can imagine if you are running 70s vintage DEC hardware, there might be appreciable performance benefits to not spawning that extra process.

Re: Unix command line conventions over time

#160

Post by andi999 »

MontyCarloHall wrote: post #146
IshKebab wrote: post #144

Earlier quoted context omitted.

> one-off use case And fortunately nobody is foolish enough to think that shell scripting is robust enough to use for more than one-off uses! /s

Hah, I have a friend who spent a large chunk of an undergraduate summer internship at Google porting a >50k line bash script (that was used in production!) to Python. It was not their most favorite summer, to say the least.

How does one do that? I mean you just can type 50k lines in 2.5 month if you type 1000 lines per day. Which sound a lot to me.
Post reply on HN