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

This article...

[nevali]

...is so littered with basic errors that it really shouldn't be recommended to anybody. How is 'tar xvf -C tmp/a/b/c newarc.tar.gz' expected to work, for example? Quote variables with square brackets? Running subshell commands using ; instead of && ? No mention of 'xargs -0' ? Don't pipe from cat to grep? Does anybody actually care that people do this (primarily so that the syntax is consistent between a munged- and unmunged-grep, and also such that the order of the command-line is logical from a human point of view)? Plus, of course, it's possible that cat | grep could yield better performance than grep alone: if cat uses mmap() to efficiently read the input files, and the kernel's pipe implementation is good, then it could do better than a grep implementation alone that simply read()s the files.

Comment removed

[account_deleted]

Comment removed based on user account deletion

absolute drivel

[Anonymous Coward]

This is, without a doubt, the most worthless article I have ever seen, both on Slashdot and on ibm.com, of which I thought better. It is not that the article is boring, but that it is factually incorrect in some places.

"the only excuse to define directories individually was that your mkdir implementation did not support this option, but this is no longer true on most systems. IBM, AIX®, mkdir, GNU mkdir, and others that conform to the Single UNIX Specification now have this option."

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. I cannot believe that anyone "with 20 years of experience" is brazenly quoting names of standards in an effort to give his ramblings an air of credibility. Actually, wait a minute...

Another bad usage pattern is moving a .tar archive file to a certain directory because it happens to be the directory you want to extract it ...

Better is to check what's in the archive before extracting it in case some inconsiderate fool has failed to put a top-level directory in it.

His research interests include digital publishing and the future of the book.

Let me give you a couple of hints.

Re:Don't use shell

[Anonymous Coward]

This code is not pure shellscript : it uses awk and wget to get the job done...

A Python equivalent might be :

#!/usr/bin/python
import os
for a in file('filename').readlines():
  os.system('wget ' + a)

It's not that much longer, it's much easier to read and less error-prone (especially the awk part), and it uses fewer external utilities.

To me, the *only* advantage of shellscript is that it's the only language that you are sure to find on any Unix system.

Re:Square or Curly brackets?

[lmfr]

The correct form is {}, not []. There are other things you can use with ${VAR}:

• ${VAR:-text if $VAR is empty}
• ${VAR:=text if $VAR is empty and set VAR to this}
• ${VAR:+text if $VAR is set}
• ${#VAR} -> length of $VAR
• ${VAR#pattern} or ${VAR##pattern} -> remove match of pattern from beginning of $VAR (## -> longest match)
• ${VAR%pattern} or ${VAR%%pattern} -> remove match of pattern from end of $VAR (%% -> longest match)

There are other formats (see the man page), but these are the ones I use the most. Eg:

for i in *.png; do convert "$i" "${i%.*}.jpg"; done

Re:Don't use shell

[duguk]

Um, whats wrong with

wget -i filename

Or have I missed something?

Monkeyboi

Actually useful hints

[Artraze]

As has been pointed out, this article is riddled with errors. It's also not very interesting. So in the interest of perhaps actually providing some interesting tips:

In scripts, prefix dangersous commands with an 'echo' for a test run (So you can catch all those rm -rf /).

Single quotes are the best quotes for plain strings. The only reasion to use double quotes is if you need to quote a variable or a single quote.

Completion is fun, but using wildcards is more flexible (though you'll only want to use benign commans like cd, less, etc):
    nano /etc/modules.autoload.d/kernel-2.6
    nano /etc/m*a*d/*6

Note that the use of subpaths reduces the amount of flexibility.
    cd /etc/m* -> /etc/mail
    cd /etc/m*d -> /etc/modules.d
    nano /*/m*/*6 -> /etc/modules.autoload.d/kernel-2.6, and /etc/modules.d/i386 (not quite!)

Finally, as a comment for the article, using:
    test -e $DIR || mkdir -p $DIR
is much better than their suggestion and probaly faster anyway. Though I'd just do "mkdir -p $DIR" and maybe "&>/dev/null" under most circumstances anyway.

That's all I can think of at this point. Anyone else have tips?

Re:welll..

[hackstraw]

cat-ing a file and then piping it to grep. surely that is a good point he is making, because grep already takes filenames as an argument?

That list was fairly arbitrary, but the piping cat thing is something that basically only annoys the most anal of anal, and they probably do it sometimes too.

Its common for me to do cat foo and then hit the up arrow and append a pipe to another command instead of editing the whole command line. Computers are pretty fast, and real anal people would use fgrep instead of grep, but again I always use egrep, because I never know when a regular expression will be edited into a more complex one, and to me all of the speeds are the same.

My #1 habit to tell people, although it is not a habit, but just where to start it to learn your shell. No science guys, csh is not a worthy shell in 2006. If you have to suffer with the wacky behavior of a csh variant, at least use tcsh.

My #2 thing to learn is a text editor.

As far as habits go. First and foremost, unalias cp, mv, rm to have the -i flag. In my opinion, that is a BAD habit to start. You WILL lose files sooner or later, and the more painful the better so that you will think so you will stop doing it. the -i flag will NOT stop you from redirecting into a file, and the most dangerous is the -rf flag with rm will override that -i. Remote copies via rcp or scp will not honor the -i flag. Unarchiving an archive will not honor the -i flag. There are tons of ways to lose files, and you will lose them. Its a much better habit to universally save yourself from yourself to not lose them by testing with -i, working off of a copy, and thinking before you hit return, creating new directories to eliminate clobbering a file, NEVER, EVER, do tar cf foo.tar . or tar cf foo.tar *. You will piss yourself and others by doing that.

Actually, this top 10 list is pretty lame, and should be ignored.