Unix Culture

After so much time and so much code, people deeply exposed to Unix tend to think about things in a UnixWay. Some programs are unixy, and some are not. PerlLanguage is (consciously) unicious, BasicLanguage is not. EmacsEditor is, MicrosoftWord isn't, Wiki is halfway.

Taken together, a few books capture most of it:

Those in this culture perceive TheNotUnixCulture as insensitive.

Programs are hardly ever ported from TheNotUnixCulture; instead, the assumption is that if you weren't some kind of weirdo you'd be using "not Unix" like everyone else.

"Unix is the latin of computer science." -- WardCunningham

Except it ain't dead yet; though there are many who wish it would be. Including yer boss. :)

Live Free Or Die

"...Armando Stettner, one of the early Unix developers, used to give out fake license plates bearing this motto under a large Unix, all in New Hampshire colors of green and white" http://catb.org/~esr/jargon/html/L/Live-Free-Or-Die-.html

I am very pleased to have one of these, from the old days. The thing people don't understand about us UnixWeenies? is summed up, from our point of view, in this borrowed phrase. UnixOs isn't perfect, but it is freedom. All other operating systems before and since are fascist bondage and discipline "you can't get there from here" systems, no matter what individual nice features they have, or (these days) how flashy their GUI.

We value freedom, thus "Live free or die!"

I don't see this as a TermOfAbuse. There is a Unix culture, with it's own conventions and design principles. Even systems like DOS and NextStep have absorbed a certain amount of the Unix culture.

The history of UnixOs is rather like the history of British-style parliamentary democracy. We sort of invaded lots of other countries and left behind similar systems of government. Perhaps "porting" has done to Unix what colonization has done for UK-style government.

For example:

Australia ... quite a lot of influence. Some Australians even want the queen to remain head of state. BsdOs is in a similar situation... almost "vanilla unix".

US ... similar in origin. e.g. adversarial system, legal precedent matters. MicrosoftWindows/MsDos is like that - similar in origin but has departed on its own path. (No offence intended here, honest.)

India ... somewhere between AUS and USA in influence, but the common influence from outside is clearly grafted on top of a different existing culture. E.g., a BSD compatibility layer on top of the mach and OpenStep.

Then again, perhaps the CeeLanguage is more influential than the OS ... Sort of the "International English" or the Latin of its day? A LinguaFranca for writing on the metal? --

"sort of invaded"? Surely we invaded, or we didn't? -- RogerLipscombe

Nice to know that my gentle understatements are appreciated. ;-) --

UnixOs in the movies (sad but true):

Apparently, megalomaniacs bent on world domination prefer OS/2 (if you believe the product placement in Goldeneye).

Then, we never have to ever worry about world domination, do we?

I wouldn't be so sure. There appears to be a new breed of supervillains: http://ubergeek.tv/article.php?pid=54

Unix can be evil, too! "curses(3), fold(1) again!" twiddling moustache.

It seems to me that the UnixCulture always gets excited when really cool new operating system ideas make the scene, like in PlanNineFromBellLabs. However, that excitement appears to evaporate quickly once it's discovered that it renders most of their toolbox obsolete.

If this keeps up we'll still be using UNIX for centuries to come. :-) -- MattBehrens

That implies that the UnixCulture crowd loves their tools. I'm not sure. They love the power and flexibility, but I've never heard anyone praise the elegance and style of the interface for, say, sed or find or curses!

Curses I can't speak to, but I love sed; find is not my favorite but is useful in far too many ways to count. Whenever I have to use a MicrosoftWindows box, the first thing to go onto it is CygWin. -- MattBehrens Even better: the first thing I install is VirtualBox and Debian

Consumer-based OSes like MacOs and MicrosoftWindows traditionally had a captive GraphicalUserInterface with no scripting (or v. poor scripting). Facilities like WindowsScriptingHost and AppleScript attempt to compensate for these weaknesses. It'll be interesting to see what happens with them. I doubt they'll have the same following: People had to learn UnixShells and got scripting as a bonus. I expect programmers will learn wsh because they just need to do some scripting. --

Unix culture is about each tool doing one thing very well and combining all these little tools to achieve your objective. Sorry but EmacsEditor is a refugee from the long dead culture of LispMachines. It's an asylum seeker in the UnixCulture. That's why it doesn't work like any other unix tools. Although Emacs has brought some interesting ideas to UnixCulture. Yes, this is EmacsAsOperatingSystem.

It's a real shame that none of the major tools are complete enough to do ANY things well. Using UnixOs commands is like being handed two bits of metal with 60-degree angles milled into them and told that hey, this is a universal socket wrench, just hold them apart at the right distance and you're set! (One of my favorite Unix memories was asking an experienced (correction: highly inexperienced; see below) Unix guy what the total size of all those .java files in that directory was, and watching as four people poked at the problem for half an hour. I finally gave up, logged in to the drive from a MicrosoftWindows box, and used "DIR".)

Is there some reason why they didn't just type "du -k -c *.java"? I wouldn't call myself an experienced UnixOs guy by any means, and I can't say what Unix-like OSs this would work on other than LinuxOs. But, a guy can't really be an expert if it takes that long to quickly check the ManPages. If, say, SunSolaris's version of du didn't support the -c flag, it certainly wouldn't have taken 30 minutes to use some other program to parse and sum the output of du.

Because they didn't know "du", most likely. I freely admit that as coders, these people were really great statisticians. The fact remains, however, that I didn't know about "du" either until I saw you mention it. While ManPages are a good way to learn more about a command when you only have an approximate idea of what it does, they are worthless if you don't know which one to use. (Some cross-references in the man pages would get around this... but there are none.)

You know, you could always just "man -k [command related word]," or "apropos [word]." The ManPages are not worthless if you know how/when to search them... I have found many useful commands this way. Of course, this gets into something strange, because how would you search the man pages for "how to search for a command" without knowing how to search the manuals in the first place? This is a typical Unix problem, I would agree: not knowing how to know how to do something. And this is where the oral tradition of Unix comes in, i.e., a Google search.

I cannot believe this story either. I am far from being a UnixOs expert, but "wc *.java" crossed my mind immediately. If you just want the relevant data, "wc -c *.java | tail -1" gets you there.

Of course the DIR command worked, because the example was trivial. But in a real-life project the source files are scattered along a directory hierarchy. In UnixOs I would do "find -name "*.java" | xargs du -b -c". And if I want the line count, I replace "du -b -c" with "wc -l". This is Unix culture at its finest.

This is why books like UnixPowerTools and a whole slew of other O'Reilly publications exist. I learned more about UnixOs from UnixPowerTools than any other book on Unix I've ever read. It has all the cross-references between different tools that any person could want.

Actually, it's worse than that. This story boils down to "the entire small connectable tools philosophy of UNIX is crap because there's one case where the default behaviour of something in UnixOs doesn't do what it does in MicrosoftWindows". This is the big problem with trying to make Windows people understand the philosophy. For almost everything you can type at a command line in UNIX, you can go download and possibly install something that will almost do it in Windows. DIR also sorts files. Not by any arbitrary criteria, just by 5. Now they /look/ like a full set. And almost always are. It's that 1 in a 100 case where the one you want is not on that list that's the killer, and it's where the tools approach saves you tons of effort. Sort the files on the criteria of alphabetically, by name, ignoring the first letter... 

 ls | sed "s/\(.\)\(.*\)/\2\1/g" | sort | sed "s/\(.*\)\(.\)/\2\1/g"
"Oh, " says the Windows user, "how often does THAT need doing?"

The answer is, actually, that things like that crop up annoyingly often if you're actually trying to work on things. I ended up with much more grossness sorting files that were named <random process number>.<date in MMDDYYYY format>.<extension> into date order.

-- KatieLucas

The command line up there is a sort w/ SchwartzianTransform, an algorithm implementable in under 15 lines of JavaScript, with the WSH FileSystemObject? model to provide the file names. Care for me to demonstrate?

Er, what's wrong with ls | sort -k 1.2 ??

Agreed. I have a better example. When I take a backup of my Psion, I simply copy the contents of the disk to a directory whose name is today's date. This gives me a large collection of directories, nearly one per day, whose contents are nearly identical. I then index each one using this comment: 

find $new -type f -exec md5sum '{}' ';' | sort -k 2 > $new.ndx
Now I delete all the identical files from the older directory like this 

diff -rqsb $old $new | gawk '/identical$/{print $2}' | xargs rm
It has a problem if there are filenames with spaces.

Real situation, real problem to solve, real code I use frequently (in a script). How would I do this in Windows? Perhaps people who use Windows simply don't do this sort of thing, and maybe that's because they can't.

I think it's David who is so eloquently putting the Windows point of view, and I suspect that you're arguing against something I never said. I pointed out that Unix allows me to have near complete command of a small number of tools, and to glue them together to accomplish what I want. I also observed that frequently on a Windows system I simply can't do what I want because the tools I have been given don't contain the required feature(s). You said that the Windows environment suits you, and 90% of the time what you want to do isin the tools you have. You then added that the rest of the time you either don't bother, or you write scripts.

Is that a fair summary?

I also gave an example of something I had to do today, this morning, and you said that you've never had to, and if you did you were sure you could cobble something together. Noted. It seems that when you do so you are using what is often thought of as a Unix way of working, and not a Windowsy way of working.

Here, my point was that I don't see the sense in using a shell script or the like to solve a problem that a specialized tool already solves well. If I want to drive a nail into a board, I'll use a hammer without trying to find out how to do it with an electrical screwdriver and a Leatherman. Solving problems you encounter is not even remotely a Unix thing; it's common sense. It's just when I decide to solve them myself (which is when, and only when, they haven't been solved satisfactorily already) that [??] seems to be the difference.

This isn't a value judgement, it is an observation. It's also not a 100% correlation. I use the Gimp, KMail, FireFox and other large applications that do a lot of what I want. My problem is that my "10%" is more like "50%", and I can never find a Windows tool to do what I need. Yes, my life is different from yours. I have different, complex problems to solve every week, and GUI designers of monolithic tools have rarely anticipated them. Hence I work in what is generally considered to be a UnixCulture way.

The tool philosophy in its core doesn't seem flawed to me; it's just the many quirks that bother me - mainly the lack of consistency and orthogonality. And why use half a zillion different tools/languages that do almost the same things but not enough to avoid having to use three of them, glued by sh, a most flaky scripting language, when a Perl/Python/Ruby script would do the same in a far less confusing manner. An extra line of code or a longer identifier never hurt anyone... In the UnixCulture, I lack a tendency of creating shared, reusable, programatically embeddable discrete components managed on the OS level from which to build on, where the command line "tools" themselves would be front-ends to more generic functionality which I can use without the gyrations of marshalling data from/to byte streams and spawning subprocesses (a procedure call still is, and probably shall ever be more efficient and concise than spawning a subprocess). The world needs a BetterOs?, anyone? But that is a notion that is in Windows, even if in an extremely unknown way. The fact something isn't a full-blown process invokable per command line doesn't mean it isn't there, and I'd like to see a problem a combination of awk/sed/grep/find can solve, and Windows JavaScript cannot, although admittably with a few gyrations in the form of utility functions to do what said Unix tools do. (Diffing might require the use of a diff engine wrapped in a COM component, which would take slightly more effort. Yet, that should indeed be doable.)

Oh how I hate ThreadMode. Let me try again. (Indeed, this needs a severe refactoring, alas, I don't have experience with that.)

Then: I find Windows bloody annoying because I can rarely find a tool that does what I want. You complain that the Unix tools lack consistency and orthogonality. I'm not arguing with you about any of these points. It seems that the Windows way of working mostly suits you well. It doesn't suit me because most of what I do hasn't been anticipated by the suppliers of Windows programs.

Let me say it again. The Unix domain has a small number of tools with which I can do almost anything. The Windows domain has a vast number of tools, and when you want to do something you need to pick one. To me, having a small number of tools that I understand well and with which I can do everything is far superior to having to know vast numbers of tools, and even then to be stuck if there's a task without an appropriate tool.

And here comes the "far superior", which I consider is strongly subjective. Since ease of use is always considered when specialized tools are being made, I find it easier to learn a larger amount of them still. And when I am indeed forced to improvise, I can do that - the Windows domain -does- have tools, only their usage is different, and they don't come with the system (which is a result of historical evolution from a simple, single-user OS aimed at personal computers and marketing). Windows doesn't come with batteries included for the power user, which is indeed a shame, but nothing stops you from going out and buying some. Heck, getting them for free.

Said rattling off a command line is programming, you are transforming and processing data, Unix command line tools are functions/APIs, only more expensive to invoke, and requiring marshalling the implicitly structured outputs to match the expected input for the next tool.

You said:

"In the UnixCulture, I lack a tendency of creating shared, reusable, programatically embeddable discrete components managed on the OS level from which to build on, where the command line "tools" themselves would be front-ends to more generic functionality which I can use without the gyrations of marshalling data from/to byte streams and spawning subprocesses (a procedure call still is, and probably shall ever be more efficient and concise than spawning a subprocess). The world needs a BetterOs?, anyone? But that is a notion that is in Windows, even if in an extremely unknown way."
Quite frankly I can't understand what you're saying here. Perhaps you could start another page and explain what it is that Windows has that Unix doesn't - this text seems rather opaque to me.

Finally, you work well and are productive on Windows. Great - go for it and I wish you well. I wish I were too, but on a Windows system I find myself constantly trying to work out how to do things, and mostly give up and write a program. I'm more productive on a Unix system.

-- AnonymousDonor

I got my introduction to UnixCulture from Living with Unix by Don Libes. 

 ls | sed "s/\(.\)\(.*\)/\2\1/g" | sort | sed "s/\(.*\)\(.\)/\2\1/g"
This, and its cousins in PerlLanguage and AwkLanguage, are for me the distinguishing characteristic of UnixCulture. If you find reading and writing strings like this fun, informative, exciting, rewarding, whatever, you are comfortable in the UnixCulture. If, to the contrary, you find it revolting, tedious, stupid, monotonous, opaque, whatever, you are not. The UnixCulture is created, populated, and maintained by people who belong to the first group. YourMileageMayVary.

See TermOfAbuse, TheNotUnixCulture

CategoryCulture, CategoryUnix

EditText of this page (last edited September 9, 2014) or FindPage with title or text search