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

Things I had to learn the hard way

[gd23ka]

1. Don't rm with an absolute path because you could easily

#rm -r -f / tmp/dir

when "all" you wanted was

#rm -r -f /tmp/dir

instead do this:

#(cd /tmp ; rm -r -f dir)

or even better use sudo if you have it:

$(cd /tmp ; sudo rm -r -f dir)

2. When logged on as root or when using sudo on a production system think things over
at least twice before hitting enter.

3. Make sure at all times you're on the right machine, logged on as the right user in the right directory.
Set up your shell prompt to look like this user@host /path$

Re:Things I had to learn the hard way

[sarathmenon]

you could easily
#rm -r -f / tmp/dir
when "all" you wanted was
#rm -r -f /tmp/dir

You are forgetting one thing - there's no solution for stupidity and lack of common sense. While tips like these are generally useful, the person who's going to screw up a system will ignore you, and the zillion other tips that people have taken efforts to write. I've seen people who've run a rm -rf /bin to clean the recycle bin and then wonder what happened.

Its hard to bring in any improvement in the average unix admin, and part of the reason is that unix is unlike windows an OS that expects people to think and run sane commands. Its hard to cultivate a habit like that especially when the average-joe-fng-admin is used to next-next-next install processes and right-click-select-click-click operations. I'd love to see a change, but I feel that the IQ of the average person using a computer (any computer for that matter) is dropping sharply these days.

(I am not trolling, but I *am* sure that this will be voted down as one)

Re:absolute drivel

[Anonymous Coward]

This is nonsense. The expansion of the path components in the {braces} is not a function of mkdir(1), but of the shell, and how its argument expansion is configured.

RTFA. He was referring to the -p parameter which automaticly creates the parent directories. That has nothing to do with the shell. If this is the only flaw in the article you could come up with then I guess its not as bad as you claim afterall.

Re:Don't use shell

[dheera]

Yuck, I never use bash scripts. I always use Perl scripts. I just do things like

#!/usr/bin/perl
system("blah");
system("blah");
if(perl code perl code) {
    system("blah");
}
etc.

why?
1. because i can't remember the awful syntax of the bash if statement. isn't it something like
    if[[""$X$$"" == ""$Y""]];; ... fi ?
2. how about accepting command line arguments in bash? in perl it's just $ARGV[0]. nice and simple and like C++ (except for the offset by one) so i don't want to have to bother learning another one.
3. because i can't bother learning how to do a regular expression in bash. in perl it's simple with =~/.../ and =~s/.../.../ and it was bad enough that PHP isn't like that.
4. because bash seems to think that sometimes you use x and sometimes you use $x
    x="hi"
    echo $x

i really don't want to learn this language. so i just use Perl everytime i need a script. it works.

Re:Even that's wrong / Ich bin Grammatiknazi

[multipartmixed]

You should be using gzcat, not zcat, anyhow. zcat is only portably able to be compress -d.

gzcat will never be broken in the way described, hence the following is fine and portable IME:

gzcat arc.tar.gz | ssh user@foo 'cd tmp/a/b/c && tar -xvf -'

HOWEVER, I find that even vaguely modern CPUs are much faster at gunzipping than typical internet speeds. So, I would use this myself:

cat arc.tar.gz | ssh user@foo 'cd tmp/a/b/c && gzcat | tar -xvf -'

On the otherhand, I would never actually write that, because if I had the archive in place, I'd just transfer it with scp and untar it myself on the remote end. Unless, of course, cat in the example is just a place holder for 'arbitrary cool shit in the pipeline'.

HEY! PYTHON WEENIE! YEAH YOU, UP THERE!

Let's see you do this in your bloatware:

(cd /updateDir && find . -newer timestamp -type f | tar -T - -zcf -) | ssh user@foo 'cd /stagingDir && tar -zxvf -'

Incidentally, dropping the "z" flags and adding "-C" to ssh will make this totally cross platform, even to non-gnu-land, back as far as ssh 0.99 without significant penalty or performance difference. A reasonable alternative, before about 1992, would have been:

(cd /updateDir && find . -newer timestamp -type f | tar -T - cf -) | compress | rsh -l user foo 'cd /stagingDir && compress -d | tar -xvf -'

Moo hoo hahaha

What would you python weenies do if confronted with an AIX 2 or a SunOS 4 box? Go home and backport the behemoth? Any one of my sysadmins -- who have never used either of those OSs but know shell -- could solve that problem in five minutes flat.

Re:I always use 2 or more args for grep

[mOdQuArK!]

I prefer to use the xargs version of that line where I can get away with it:

      find . -name *.cpp -print | xargs grep someFn

especially if find reports a LOT of file names,
since the backtick syntax can often run afoul of
any command-line length limits that the shell
might have after it has been expanded.

As far as I know, xargs doesn't have any such
limit (other than virtual memory) when it is
constructing the command-line that it is going
to execute.

Incorrect benchmarks!

[Vince]

Does anybody else notice these benchmarks are flawed? For an article discussing the shell, we should know that in this first benchmark, time is only counting the execution time of grep, and not wc, and is thus undercounting how much CPU time is actually used. How about a neat shell trick to correctly run that benchmark?

> ~ $ time grep and tmp/a/longfile.txt | wc -l
> 2811
>
> real 0m0.097s
> user 0m0.006s
> sys 0m0.032s
> ~ $ time grep -c and tmp/a/longfile.txt
> 2811
>
> real 0m0.013s
> user 0m0.006s
> sys 0m0.005s
> ~ $