Linux System Administration Recipes A Problem-Solution Approach

CHAPTER 1 ■ SAVING YOURSELF EFFORTThe -w flag turns on warnings. This means that if Perl thinks you might be doing something wrong,then it’ll tell you so before running the program. It’s not always right—in particular, if you’re readingfrom files, you may get some warnings if your data isn’t always complete—but most of the time it’sworth at least taking another look at the warning.use strict means that you have to declare all your variables before using them (or at least at thesame time). This is demonstrated in line 11. You could also use this:my $file;// some stuff$file = "/etc/passwd";But if you just have $file = "/etc/passwd", the script will complain and die. This is an absolutegodsend if you are remotely prone to typos or to variable name forgetfulness (because if you declared$file and then try to set $dile, you will be told what you’ve done). If you’re not remotely prone to eitherof these events, then you are unusually fortunate; you should use strict anyway because it’ll be evenharder to find the mistake the one and only time your fingers or memory betray you.It’s best to declare all your variables up top, before you start, as in line 11. (Obviously, there’s noneed to do this for temporary variables such as loop variables.) Again, it makes it much easier to keeptrack of what you’re doing.Don’t hard-code anything. Put it in a variable, and put it at the top of the file. Put this sort ofpossibly-might-change variable (for example, the e-mail address that you want to send output to or thelocation of a particular file) before any other variables, as well, so they’re easy to spot. Resign yourself tothe fact that things will change, and the just-one-time script will still be here in six months’ time whenyou rearrange your filesystems and all your directories change. At this point, first some of your scriptswill break, and second you will have to fix them. Make that fix a two-second job rather than a searchand-replace-through-every-filejob.When you pass variables into a script or a subroutine, don’t just use the default names (for example,$_[0] or @_ for a Perl subroutine).Instead, give them real names immediately, and use those thereafter—as in line 23. It’s a single extraline of code, and it makes it far, far easier to remember what exactly it is that you’re doing with whatyou’re passing in. It will also help you remember what it is that you’re passing in, rather than having torepeatedly check what variables are expected.And, while you’re naming variables, name them something sensible that is going to be meaningfulwhen you return to the file, say, tomorrow morning. So, use $file, not $f.1-7. Testing Scripts FullyBooks can and have been written on proper testing, but that’s overkill on a quick script. However, youshould do basic testing on even a junk script. (If there’s any possibility of it being used more than once,put in basic error handling as well.) If you don’t test it and you accidentally delete something importantor wipe the log data you’ve spent the last month collecting, you’ll be very irritated with yourself.Test edge cases, and check what happens if the input is bad (too many or too few arguments, a wordinstead of a number, or vice versa). Testing in chunks is also useful—check that the first half of the scriptis generating what you want it to before you start writing (or at least before you start testing) theprocessing in the second part.Printing to screen (print in Perl or echo in bash, as in line 25 of the script in recipe 1-7) is a quick andeasy way to debug. Remember to comment it out afterward if you don’t need it; even better would be toset a debug variable and use that to control whether the debug output is printed:9Download at WoweBook.Com