How To Adopt 10 'Good' Unix Habits 360
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."
Things I had to learn the hard way (Score:5, Interesting)
#rm -r -f / tmp/dir
when "all" you wanted was
#rm -r -f
instead do this:
#(cd
or even better use sudo if you have it:
$(cd
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
Re:Things I had to learn the hard way (Score:2, Interesting)
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 (Score:1, Interesting)
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 (Score:2, Interesting)
#!/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""]];;
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 (Score:3, Interesting)
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
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
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 (Score:2, Interesting)
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! (Score:3, Interesting)
> ~ $ 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
> ~ $