How To Adopt 10 'Good' Unix Habits

An anonymous reader writes to mention an article at the IBM site from earlier this week, which purports to offer good Unix 'habits' to learn. The ten simple suggestions may be common sense to the seasoned admin, but users with less experience may find some helpful hints here. From the article: "Quote variables with caution - Always be careful with shell expansion and variable names. It is generally a good idea to enclose variable calls in double quotation marks, unless you have a good reason not to. Similarly, if you are directly following a variable name with alphanumeric text, be sure also to enclose the variable name in square brackets ([]) to distinguish it from the surrounding text. Otherwise, the shell interprets the trailing text as part of your variable name -- and most likely returns a null value."

Comments

Re:Don't use shell

[Anonymous Coward]

OK, I agree. Please provide a concise Python script that unpacks a tarball (a .tar.gz or .tar.bz2 file), copies new files in to a said tarball, patches based on the contents of said new files, runs make from various directories in said extracted tarball, and then changes the name of the top-level directory created by the tarball to a new name and repacks the tarball.

Or a concise Python script that opens up a text file of URLs, and extracts the files listed in the URLs:

#!/bin/sh
for a in $( cat file | awk '{print "'\''" $0 "'\''"}' ) ; do
              wget $a
done


Python has it place, and is far better for medium to large projects, and projects where the code needs to be maintainable. Shell, however, works a lot better for automating UNIX tasks than Python does. Not to mention embedded systems: I can compile Busybox to have both a good shell and all of the commands that one would run from shell scripts (including grep, cut, sed, and, yes, awk) in only about 300k. A Python binary is about a megabyte big, and you need about ten megabytes to fit all of the libraries Python 2.4 comes with.

Re:welll..

[AchiIIe]

Some of the points he is making are BS. They are not good `Unix habits` they are simply hacks that marginally reduce the workload but (arguably) increase complexity.

Ie there is NOTHING bad about piping cats. While you might indeed get a ~30% performance increase if you skip the cat, the complexity increases. We often sacrifice performance in order to increase abstraction and understanding.

What makes unix so powerful is its modularity, the fact that you can pipe any output from any application to any applications stdin. This makes it possible to use common tools app1 | app2, app1longoutput | grep thingsIwant. The possibility to mix and match common elements that (arguably) makes unix powerful.

Advice that says "stop piping cats" is akin to "stop using helper functions, they overload the stack, instead do everything in one function"

--
A better articulated article on the programmers intellectual ability vs proper abstraction techniques:
http://www.acm.org/classics/oct95/ - Dijkstra, Edsger - "Go To Statement Considered Harmful"

Re:welll..

[johnw]

I argue that using> grep file1 file2 file3 regex can be more confusing Not least to the grep utility, which expects the regex first, not last.

Re:welll..

[Znork]

I'd tend to agree with the GP. Consider for example if you have excessively badly named files like '-whatever' in a particular directory; cat has very few destructive ways it can go wrong, other commands may be less forgiving, and cause much more surprise.

Further, the assembly line abstraction of cat as 'input the contents of these files into the beginning of my pipeline' is predictable, simple and very clear and readable. Using the filenames in the commands means you have to be certain each command will take filenames, and if you replace the first step (from a grep to an awk, for example), you have to rethink your input method semantics again.

Any typing speed gains and performance improvements you may get will probably get shot the first time some command does something unexpected, or by the extra steps of thought.

And if performance really was a serious concern you probably shouldnt be writing it as a shell script...

No actual habits in the article

[xyloplax]

Here are some more important general IT rules (Unix rules can easily be OS and version dependent and frequently come from usage in YOUR environment)

• Copy before edit
• Tape backup before delete/decommission
• READ YOUR COMMAND before hitting return
• Check where things are symlinked to
• Echo in your scripts instead of destructive commands as a test run
• Test your changes on a lesser-importance box
• Use proper Change Control procedures
• Cover your ass and capture your terminal output
• When taking something out of service, turn it off for a few days/weeks before deleting/purging it

Re:Don't use shell

[JohnFluxx]

Wow, do you think you could be just a little bit more polite next time?