LWN: Comments on "Haldar: The Cognitive Style of Unix"

Benefits sure, but with drawbacks too

Legionair — Mon, 20 May 2013 00:44:12 +0000

Something along the lines of

// get short summary of interfaces and sort by field TX (column 8)
ifconfig -s | sort --sort=general-numeric --key=8,8
(or just -g for numeric-sort)

or to get a full output

// use the above to get the sorted list, select the first column \
// (with the sorted interface-names) and get full output for each of them
ifconfig -s | sort -g --key=8,8 | cut -f1-1 -d " " | xargs -n 1 ifconfig

of course not as concise as sort==TX, but having already gone up the
"steep part of the curve", not much worse either
put it in a nicely parametrized script and you can do it exactly the way
you described (obviously less general and portable tough...)

Benefits sure, but with drawbacks too

pkalliok — Tue, 01 Mar 2011 20:24:12 +0000

Ah, it frustrates me when people dismiss the Unix command line like this. People _are_ aware of alternatives, many command line users do use them for other tasks, and still stick to shell for their everyday human-computer interaction. Why? Because it's pretty darn hard to invent a better way of controlling your computer.

http://sange.fi/~atehwa/cgi-bin/piki.cgi/virtues%20of%20t...

ddrescue vs. dd_rescue

jabby — Sat, 26 Feb 2011 22:55:25 +0000

Regardless of whether there was any NIH mentality in the motivation, ddrescue came later and was at least in part a response to the technical shortcomings of dd_rescue. If you try both on a dying disk, you will quickly see why. I'm not the only person who has done this and come away with this conclusion:

http://ubuntu-rescue-remix.org/node/51

dd_rescue is so problematic that it necessitated the invention of dd_rhelp, a script to wrap dd_rescue and try to make it do the things that it arguably should be doing.

So, perhaps it would be more fair to compare ddrescue with dd_rhelp. But once again, ddrescue wins (in my book) because it is an efficient self-contained program written in C++ (not a shell script kludge), produces much cleaner output on the console/terminal, and (most importantly) **handles unreadable blocks gracefully and intelligently**.

Haldar: The Cognitive Style of Unix

jengelh — Sat, 26 Feb 2011 22:25:50 +0000

>Just FY(all's)I: 'dd_rescue' has been superseded by GNU 'ddrescue'

Not really. GNU just had its NIH moment there, which is, IIRC, also Garloff's position on the matter.

Haldar: The Cognitive Style of Unix

jabby — Sat, 26 Feb 2011 21:45:43 +0000

Just FY(all's)I: 'dd_rescue' has been superseded by GNU 'ddrescue' (note the underscore difference!).

The main practical advantage of GNU ddrescue is that it doesn't fall down if it hits an unreadable block. It just marks it for later reattempts and continues rescuing as many readable blocks as possible, as quickly as possible.

Here are some relevant URLs:

http://www.gnu.org/software/ddrescue/ddrescue.html
http://www.forensicswiki.org/wiki/Ddrescue

Haldar: The Cognitive Style of Unix

jengelh — Fri, 25 Feb 2011 17:35:24 +0000

Yeah some don't install it by default, even though it really should.

MS game not working on newer version of Windows

paragw — Thu, 24 Feb 2011 19:41:32 +0000

Funnily I tried Netscape Navigator 4.x on Win 7 x64 and it installed, ran and uninstalled all fine! It couldn't load any modern websites but that was because of JavaScript and HTML5 not OS compatibility!

CLI and democracy

vonbrand — Thu, 24 Feb 2011 19:09:21 +0000

Sure, it would be nice if the flags were all consistent. Sure, it would be awesome if all tools gave their possible arguments in the same format for consumption by autocompleters and such. And I want a pony too.

(The problem is that, standards like FSF's notwhitstanding, everybody does it their own way. And fixing that (rather cosmetic) problem is such a huge (and boring!) amount of work that would have to be redone each time somebody updates something that it just isn't done.)

Haldar: The Cognitive Style of Unix

vonbrand — Thu, 24 Feb 2011 19:02:52 +0000

Add a few more uses:

tar c file1 file2 file3
tar tv

For another take at the same functionality, check out cpio(1)...

Benefits sure, but with drawbacks too

vonbrand — Thu, 24 Feb 2011 18:51:36 +0000

* Unix is a trade mark of .... josh, I cannot remember who owns it just now.

The Open Group, as any Groklawite knows by heart. This is mostly useful as a trivia question by now ;-)

Haldar: The Cognitive Style of Unix

vonbrand — Thu, 24 Feb 2011 15:46:47 +0000

My use case exactly. But then again, I'm an old fart (started with punched cards, then *real* VT100s) that mostly futzes around with text (and looks at how (La)TeX renders it on and off).

Haldar: The Cognitive Style of Unix

nix — Thu, 24 Feb 2011 08:34:11 +0000

Sure.

The horrifically ugly script I used to migrate my DVDs off spinning plastic into something more easily accessible without disk swapping is now up at <http://www.esperi.org.uk/~nix/temporary/copy-dvd-title>. By default it is hardwired to copy only the first English audio track. The video is re-encoded to H.264 (because the H.264 looked better than anything else and this was for my own consumption so software patents be damned); lots and lots of parameters are hardwired, including an assumption of AC5.1 audio (which is not transcoded, just copied, possibly a bad decision). But it works for me, even if it is a patent minefield!

It accepts one-per-disk catalogue files that look something like

offset 8
2 Point of No Return
3 Severed Dreams:audio:130:
4 Ceremonies of Light and Dark
5 Sic Transit Vir

(and now you know what I wrote it to transcode!)

The optional 'offset' line gives the offset of the track titles to generate, while the numbers in front of the individual titles are the DVD track numbers to consume (and can be in any order, nonconsecutive, or even repeated): so this set produces 9-Point-of-No-Return.mkv, 10-Severed-Dreams.mkv, and so on up. There is one per-line option, :audio:, which is followed by a colon-separated list of additional audio track IDs to encode. (I know, colons are awful, but better than most alternatives, and :audio:num:num: is a tiny smidge easier to parse in the shell than :audio:num,num:, particularly given that I was only ever grabbing one extra audio track.)

It took *way* too much effort to figure out those command lines and hunt for a combination which looked good (though the mplayer online manual had a lot of helpful hints, as did h264enc). The result is actually perfectly viewable (if occasionally slightly lossy on fine detail) at 768Kb/s, but because the fine detail loss tended to happen when it was most annoying I reencoded at 1024Kb/s and have seen no problem since then. (Of course this is *TV* footage, not HDTV or anything like that.)

Haldar: The Cognitive Style of Unix

sdalley — Thu, 24 Feb 2011 00:41:32 +0000

> a script that would rip DVDs, including their subtitles and multiple audio tracks, to an .mkv file

What a guy. Could you be persuaded to divulge the incantation? Life is short, after all...

Haldar: The Cognitive Style of Unix

nix — Wed, 23 Feb 2011 22:44:40 +0000

FWIW, I also don't bother with a GUI. But it took six hours of work (five of which were eaten beating up mencoder command lines and retesting them) to come up with a script that would rip DVDs, including their subtitles and multiple audio tracks, to an .mkv file. That is not a rare requirement and should not have required five hours of poring over manpages to do.

(I could have used a GUI... but the GUIs seem to need a lot more manual work, or skip important things like alternate audio tracks or titles, or don't produce output in the right format. I just wanted to dump the track titles into a text file and swap DVDs every few hours.)

Haldar: The Cognitive Style of Unix

nix — Wed, 23 Feb 2011 22:42:05 +0000

You don't quite get it. It's not that there are too many options: it's that their documentation is badly organized, and there are no reasonable defaults. There are some options that are much more often used than others. -vc and -ovc, for instance: they should be at the top of the manpage, highlighted. The defaults should be set so that common transcoding tasks Just Work without having to read most of the 6500-line-long manpage first. There are some things that often require multiple subtly different command-lines that it could do in one go (e.g., why does two-pass mode actually require you to run mplayer twice with different options?)

That sort of thing.

Haldar: The Cognitive Style of Unix

nix — Wed, 23 Feb 2011 22:32:01 +0000

Yeah. The default (non-gmplayer) GUI is (mostly?) gone in current releases: apparently they decided that being easy to use was a bad thing or something.

Haldar: The Cognitive Style of Unix

JEDIDIAH — Wed, 23 Feb 2011 19:14:28 +0000

Windows 7? Are you kidding?

Have you actually USED it?

I really doubt you have.

Haldar: The Cognitive Style of Unix

JEDIDIAH — Wed, 23 Feb 2011 19:12:48 +0000

Some tools are inherently complex because they deal with inherently complex things. Something like mencoder is such a beast because there are so many possible options. You can't just pick a select few to focus on by throwing darts at the mencoder manpage. The result won't be nearly comprehensive enough and someone like you will still be whining.

No GUI that tries to encapsulate everything that mencoder offers ever looks good or terribly usable. Even selected subsets of what mencoder offers present in GUI form look ugly and impenetrable.

OTOH, the nature of the Unix shell is such that I can forget any given set of options as soon as I sort them out and automate use of them in a manner not GUI can match.

This is why I don't bother with GUIs that do the same thing that mencoder does.

I don't want to babysit a GUI for n+1 iterations of something that should be more like a "lasso + hit start button".

"automated" trumps "easy" by a long stretch.

Haldar: The Cognitive Style of Unix

oblio — Wed, 23 Feb 2011 19:08:39 +0000

Yeah, the command line interface isn't much better either.

But I was talking about the default GUI, I believe it's Gtk 1 or 2 (don't really remember, haven't used Mplayer or its GUI in a while).

It was especially funny when you open the advanced options and you needed to be a FFMPEG developer to be able to actually configure anything in there :)

Haldar: The Cognitive Style of Unix

nix — Wed, 23 Feb 2011 18:04:54 +0000

Since it seems I'm finally going to be using Linux most of the time rather than Solaris, that might finally be practical.

-t only works if the target is a directory, though: if you try it with a nonexistent name (aiming for a normal rename), it fails...

Haldar: The Cognitive Style of Unix

nix — Wed, 23 Feb 2011 18:02:06 +0000

mplayer, a gui tool? It has a more nightmarish command line than anything I have ever heard of before or since. It has more (and more inconsistent) options than even GCC.

It's much worse, actually, because most of GCC's options are rarely needed, and it works perfectly well with only a couple, while you need a lot of mencoder options to do anything with it, and they're scattered through the whole manpage rather than being segregated into a frequent-needs section at the top.

CLI and democracy

nix — Wed, 23 Feb 2011 18:00:09 +0000

VMS, now that could have solved it... because it was a closed shop with strict standards. Not really a benefit, all things considered.

CLI and democracy

nix — Wed, 23 Feb 2011 17:57:53 +0000

Also in their staggering complexity :) it takes, what, 200 pages to document them? Half the manual...

Benefits sure, but with drawbacks too

alankila — Wed, 23 Feb 2011 17:49:24 +0000

I think the microsoft approach doesn't even necessarily have a text representations of the objects being passed between programs. I think the environment is more akin to python, or some such managed language, where a function generates objects and another one consumes them. The question "but how do I represent this object as text" doesn't even arise, because there is no need to do this conversion at all.

Consider that PowerShell can use any .Net library from the command line: the analog is that you could name a .so file on your Linux terminal to load it, and afterwards call the functions in there, and have it all work. I am starting to suspect that Unix culture is so far behind the state of the art that we don't even realize it.

Haldar: The Cognitive Style of Unix

jamesh — Wed, 23 Feb 2011 15:01:39 +0000

You could try training yourself to use "cp/mv -t DEST SOURCE" instead.

CLI and democracy

kfiles — Wed, 23 Feb 2011 14:49:45 +0000

@oblio: That's more cynicism than I need in the morning. Unfortunately, all true, though.

@nix: I use bash_completions, but those are manually updated, and can never provide sufficient coverage or recency.

These are the times when I envy the BSD model of binutils, with its centralized development process. Not that they've solved this problem either, but at least they *could*, given sufficient motivation.

Why do you use GNOME?

dgm — Wed, 23 Feb 2011 12:23:48 +0000

Yes, thank you. Modular and scriptable... based on WebKit... Very clever, good stuff.

Haldar: The Cognitive Style of Unix

oblio — Wed, 23 Feb 2011 11:56:34 +0000

Not really. Everytime I use a command line tool I have to look up the parameters. I only know several hundred parameters, ln -s, ls -lha, rm -rf, cp -i, chown -R, tar -zvf, wget -m ... (those are already 12 parameters!), I tend to always forget them or confuse them:
- was it -R or -r?
- was it -v or -h?
I haven't needed a manual for a casual GUI (file navigator, media player, ...) for a loooong time.

You only need a manual for highly technical GUI tools: 3DStudio Max, Autocad, Blender, Mplayer :)
But in that case you're reading more about the problem space than about the tool itself ;)

CLI and democracy

oblio — Wed, 23 Feb 2011 11:52:37 +0000

Except for the fact that from a design point of view the whole concept is flawed. The shell should *not* have to have lists of autocompletion options which need to be updated. The shell should be able to extract meta information from the tools themselves. This way, each time a tools is updated, the autocompletion is also updated.
Powershell-style.

Extra points for extracting information directly from the source code or from a description file autogenerated from source code (see Maven 2/3 plugins for examples, mvn help:describe -Dplugin=... -Ddetail=true).

Of course, this is impossible to do, since all the existing tools would need to be updated to support this mechanism. And people would rather create crappy man pages, 1 bit at a time, than try to solve a bigger problem.

Plus, why would the author of tool X, which only uses csh or ksh or some other ancient-mostly-forgotten shell, try to create this interface for bash or zsh? It's not like csh/tchsh/ksh/pdksh/bash/zsh developers will ever agree on an autocomplete interface :)

Aprpopos Churchill...

ldo — Wed, 23 Feb 2011 11:14:54 +0000

The *nix command line is the worst one out there ... apart from all the others.

CLI and democracy

rleigh — Wed, 23 Feb 2011 09:47:38 +0000

And then there are zsh completions, which are even more awesome in their scope and power.

Switches and Arguments in Unix

nix — Wed, 23 Feb 2011 09:31:56 +0000

Well, yes, all switches work this way. But 'c' is *not a switch*. Nor is 'ax'. It's not as if allowing the minus sign to be excluded rendered anything easier to use. Perhaps it saved one byte on BSD machines, back in the day...

CLI and democracy

nix — Wed, 23 Feb 2011 09:30:39 +0000

bash_completion already contains code to parse --help output and convert it into a set of options, but this is only enabled for a limited (if quite large) set of programs. (I'm not sure why it's a whitelist rather than a blacklist of programs for which this doesn't work...)

Haldar: The Cognitive Style of Unix

euske — Wed, 23 Feb 2011 09:13:25 +0000

"I had a calculus book once that said, 'What one fool can do, another can.' What we've been able to work out about nature may look abstract and threatening to someone who hasn't studied it, but it was fools who did it, and in the next generation, all the fools will understand it. There's a tendency to pomposity in all this, to make it deep and profound." -- Richard Feynman

MS game not working on newer version of Windows

pr1268 — Wed, 23 Feb 2011 03:42:40 +0000

For the record, Microsoft's Return of Arcade worked fine on Win98, but it refused to install on Windows 2000. I later installed and ran it fine on XP. I do know that MS goes to great lengths to ensure backward compatibility with not only their games, but those of other software vendors, or at least they try their best to do so. Of course, sometimes programs such as the one the GP post mentioned slip through the cracks...

Odd that I'm sort of defending MS here - I'm still a devoted hardcore Linux enthusiast!

Switches and Arguments in Unix

jjs — Wed, 23 Feb 2011 03:08:45 +0000

Tar also works with the - switch character (tar -xvzf kernel.tar.gz)

Not certain your other comment - all unix switches work this way - if they take an optional argument (-f in this case) it must immediately follow the switch. Example make -j4 that means use 4 subprocesses for make. the 4 must immediately follow the j.

CLI and democracy

kfiles — Wed, 23 Feb 2011 02:10:02 +0000

I still cannot believe that we don't have autocomplete for command options yet. I've used bash autocomplete to add my own command-specific completions for ones that really matter, but still...

Each command (esp. all the ones supporting GNU long-options) could provide a --arglist option to supply a machine-readable list of args to bash. It's not rocket science, and heck, even rocket science is just math. :)

Haldar: The Cognitive Style of Unix

pflugstad — Tue, 22 Feb 2011 22:53:46 +0000

> The Windows way mostly is: "Backward compatibility at any cost. Don't break users' existing software". As much as possible, the Windows developers try not to break existing applications. Read Raymond Chen's blogs about this.

It's interesting to read Joel on SW's take on this:

http://www.joelonsoftware.com/articles/APIWar.html

scroll down to the "The Two Forces at Microsoft" section. The Raymond Chen stories are priceless...

Benefits sure, but with drawbacks too

neilbrown — Tue, 22 Feb 2011 21:53:25 +0000

> It keeps puzzling me when people use the word *nix. Is there *any* relevant Unix system left that matches that pattern?

I believe this usage was not originally thought of as a pattern, but a trademark avoidance technique. It is quicker than writing Unix(TM)*

* Unix is a trade mark of .... josh, I cannot remember who owns it just now.

Probably all irrelevant now, but companies do sometimes try to protect the use of their trademark - see the very last line of text on this page!

Haldar: The Cognitive Style of Unix

Wol — Tue, 22 Feb 2011 21:46:43 +0000

Add to which, what happens when you do do

cp source destination

Does destination end up as a copy of source? Does destination end up containing a copy of source?

try the following :-)

rm -r dirb
cp dira dirb
cp dira dirb

Provided dira exists to start with, the identical syntax of the two cp commands has VERY different semantics due to the change in environment between the two invocations!

If the command isn't even consistent between two *identical* invocations, then it's a nightmare!

(but as to the ln question, I'd call ln -s dangerous behaviour! Link the file, then delete the original. Your copy is gone as well! I swore when I discovered that "ln -s" was the - afaict ONLY - behaviour of "link" in dolphin - I linked a load of files, then moved the originals, and wondered why all my linked files broke!)

Cheers,
Wol