The *niX tools however is well known to utilize existing tools as much as possible. It is very common to see a Debian package that bases on more than ten other packages. The CLI tools are fundamental building blocks to achieve versatile goals. It is very common in this note collection that 3 to 5 (and even more) CLI tools works together to achieve one goal (One very common Window$ oriented question was, "how come grep doesn't have the capability to recursively descend into sub directories and search within a specific type of files". The answer is, "welcome to the niX philosophy — a program will only do one thing but do it well").

Let me explain using a vivid example. Each *niX CLI tool is one power tool in your tools collection. You use them to make whatever thing you'd like to make, be it chair, desk, shelf, etc. There is one Window$ software company that sells a standalone all-in-one GUI tool, chair-maker. The chair-maker is really convenient for you, all you need is to throw in the wood, nails and paints. It will then spit out a chair for you. Easy!!!

But wait, how about the sizes, and styles? Now the trouble begins, all kinds of chair-maker producers now produce all kinds chair-makers that have slightly different controls over how to customize build chairs of different sizes and styles. Some advanced ones will boast that their products are capable of building stools as well (since chairs and stools are really not that much different). Some really advanced ones will boast that they can build all kinds chairs, stools, and even bar-stools. The problem is, they need to have panels and panels of control bottoms in order to make "all kinds" of them that you want. Now everybody is happy. But is it really? What if you want to do a little bit different? Also, does such fancy chair-maker can produce all styles of chairs exist in the world? Imagine how complicated just its control panels and bottoms will be in order to produce a chair like this:

A normal Window$ user will normally end up with several chair-makers in their tools collection to make various chairs. Further, this is yet only about a chair. They also need maker for desk, shelf, etc as well. I.e., each thing they make they end up having several "easy" but actually fancy, expensive and cumbersome tools. Now looking back at the "simple" niX power tools in your tools collection, which philosophy makes more sense? Which tool set is hard in learning to use in the long run? Which tool you will more likely to forget how to use after a longer period of time? Before I entered the *niX world, I was impeded by the common saying "*niX do not have as many tools as Window$ has". Now I just laugh at such stupid propaganda.

documented on: 2008-01-12

http://www.linuxlots.com/~dunne/unix-philosophy.html

ls -l | less

http://www.linuxjournal.com/article/2877

September 1st, 1995 by Belinda Frazie

From the book "The Unix Philosophy"

 Author: Mike Gancarz
 Publisher: Digital Press
ISBN: 1-55558-123-4

The main tenets (each of which have sub-tenets) of the Unix philosophy are as follows:

The author introduces each tenet with a simple, real-world example (or "case study") , then further explains why the tenet is important by including non-technical computer-world examples.

Tenet 1. Small is beautiful.The book offers an example of how Volkswagen ran an ad campaign with the phrase "small is beautiful" in the US to promote the VW bug, but the idea was generally ignored in the US until the price of oil went up and Americans learned the advantages of small cars. The author draws an analogy to these nouveau small-car-appreciators to programmers at AT&T Bell Labs discovering that small programs were also easier to handle, maintain, and adapt than large programs.

In a non-Unix environment, a program to copy one file to another file might include, as in an example given in the book, twelve steps which do more than perform a file copy. The twelve steps perform extra tasks, some of which are considered "safety features" by some. The steps might include checking to see if the file exists, if the output files are empty, and prompting users to see if they know what they're doing (for example, "Are you really really sure you want to do this, and does your mother know you're doing this?"), etc. Just one step of the sequence might be the actual copy command. A Unix program (or command) would only include the one copy command step. Other small programs would each do the other 11 steps and could be used together if the Unix user wanted to use these extra steps. Although the author purposefully steers away from giving Unix examples until near the end of the book, I would have liked to see several Unix commands strung together to accomplish all the tasks described by the twelve steps.

Tenet 4. Choose portability over efficiency.The example given here is of the Atari 2600 which was the first successful home video game. Most of the code for the game cartridges was very efficient but nonportable. With the advent of new hardware (the "5200"), the code had to be rewritten to run on the 5200 which took time and money. The author proposes that Atari would have been the largest supplier of software in the world if its code had been portable.

There is a three-page analogy of selling Tupperware to the "use software leverage to your advantage" tenet. Who would have realized a multilevel marketing scheme is a good way to write software?

A sub-tenet of the leverage tenet is allow other people to use your code to leverage their own work. Many programmers hoard their source code. The author states that "Unix owes much of its success to the fact that its developers saw no particular need to retain strong control of its source code." Unix source code was originally fairly inexpensive compared to the cost of developing a new operating system, and companies started choosing Unix as the platform to build their software on. Companies who chose Unix spent their effort and money on developing their applications, rather than on maintaining and developing an operating system.

documented on: 2008-01-12