For all the new visitors of this blog, I’ve just created a Using Unix Tutorial page which is linked from the sidebar.
Please feel free to have a look and let me know if there’s any more introductory information I can add to make it even easier for you to find and get exactly what you came looking.
If you’re just getting started with your Unix scripting or new to Unix shell, today’s little tip will make your life much easier: I’m going to show you how to update your shell variables.
If you have a text variable in your script and would like to append some text to it or somehow process this value, it’s perfectly normal to reuse the current variable value using a syntax like this:
ubuntu$ echo $VAR1 hello ubuntu$ VAR1=$VAR1" world!" ubuntu$ echo $VAR1 hello world!
You see? It’s this easy!
Most frequently, I use the technique described above to update some of my environment variables. I’m sure you’ll find them useful too.
PATH is the user environment variable responsible for the directories where Unix shell looks for executable commands every time you type something. Quite often you get a “file not found” error not because there isn’t such a command installed in your OS, but simply because your PATH variable has not a corrept path to a directory with that command.
Here’s an example from a standard user on one of my Red Hat Enterprise Linux systems.
I like the runlevel command, it’s quite simple and can be useful in scripts. When I attempt to run it, here’s what happens:
redhat$ runlevel bash: runlevel: command not found
Like I said earlier, it’s most likely because my PATH variable doesn’t have the /sbin directory which is where this command resides. Let’s confirm this:
redhat$ echo $PATH /usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
Now it’s time to update the PATH and append the /sbin path to it:
redhat$ PATH=$PATH:/sbin
runlevel command will be found now and here’s a proof:
redhat$ runlevel N 5
Another good example is the MANPATH variable, which contains the list of directories with manpages which man command uses.
If some command doesn’t have its man page in neither of the directories specified by MANPATH, you’ll get an error.
Here’s an example from one of the Solaris systems, I’m looking for a Veritas vxprint command man page:
solaris$ man vxprint No manual entry for vxprint. solaris$ echo $MANPATH /usr/man:/opt/sfw/man:/usr/perl5/man
Let’s add the /opt/VRTS/man to the MANPATH variable:
bash-2.03# MANPATH=$MANPATH:/opt/VRTS/man solaris$ echo $MANPATH /usr/man:/opt/sfw/man:/usr/perl5/man:/opt/VRTS/man
It’s bound to work now:
solaris$ man vxprint Reformatting page. Please Wait... done ...
That’s all I wanted to share with you today. Hope you liked the tip, and as always – feel free to ask any questions!
In my system administration job, I come across this particular requirement quite often: run a command, then confirm how long it took to complete the job. You guessed it right – there’s a very easy way to do it.
What you need to do is to use the time command, which takes as a parameter the full command line you need to run. Upon completion of the command, time will report the system resources usage during the execution. All the reported numbers are presented in a simple table.
Here’s an example: running du command to confirm the size of a directory while timing the effort and reporting the stats:
ubuntu# time du -sk /var 4228720 /var real 0m17.747s user 0m0.010s sys 0m0.080s
As you can see, first the du command output is shown, and then the table with real, user and system times reported.
I’m finally back from my holidays and thrilled to be sharing next of my Unix tips with you!
Today I’d like to talk about parsing text files in Unix shell scripts. This is one of the really popular areas of scripting, and there’s a few quite typical limitations which everyone comes across.
If we agree that by “reading a text file” we assume a procedure of going through all the lines found in a clear text file with a view to somehow process the data, then cat command would be the simplest demonstration of such procedure:
redhat$ cat /etc/redhat-release Red Hat Enterprise Linux Client release 5 (Tikanga)
As you can see, there’s only one line in the /etc/redhat-release file, and we see what this line is.
But if you for whatever reason wanted to read this file from a script and assign the whole release information line to a Unix variable, using cat output would not work as expected:
bash-3.1$ for i in `cat /etc/redhat-release`; do echo $i; done; RedHat Enterprise Linux Client release 5 (Tikanga)
Instead of reading a line of text from the file, our one-liner splits the line and outputs every word on a separate line of the output. This happens because of the shell syntax parsing – Unix shells assume space to be a delimiter of various elements in a list, so when you do a for loop, Unix shell interpreter treats each line with spaces as a list of elements, splits it and returns elements one by one.
Here’s what I decided: if I can’t make Unix shell ignore the spaces between words of each line of text, I’ll disguise these spaces. Since my solution was getting pretty bulky for a one-liner, I’ve made it into a script. Here it is:
bash-3.1$ cat /tmp/cat.sh
#!/bin/sh
FILE=$1
UNIQUE='-={GR}=-'
#
if [ -z "$FILE" ]; then
exit;
fi;
#
for LINE in `sed "s/ /$UNIQUE/g" $FILE`; do
LINE=`echo $LINE | sed "s/$UNIQUE/ /g"`;
echo $LINE;
done;
As you can see, I’ve introduced an idea of a UNIQUE variable, something containing a unique combination of characters which I can use to replace spaces in the original string. This variable needs to be a unique combination in a context of your text files, because later we turn the string back into its original version, replacing all the instances of $UNIQUE text with plain spaces.
Since most of the needs of mine required such functionality for a relatively small text files, this rather expensive (in terms of CPU cycles) approach proved to be quite usable and pretty fast.
Update: please see comments to this post for a much better approach to the same problem. Thanks again, Nails!
Here’s how my script would work on the already known /etc/redhat-release file:
bash-3.1$ /tmp/cat.sh /etc/redhat-release Red Hat Enterprise Linux Client release 5 (Tikanga)
Exactly what I wanted! Hopefully this little trick will save some of your time as well. Let me know if you like it or know an even better one yourself!
If you want to learn more, here’s a great book:
