Question:
I'm logged in to a UNIX machine. How do I find out the IP address of a computer on the local network if I only have its host name?

Answer:
The easiest way is to use the command:
ping hostname

This will normally return something like:
PING humphrey (192.168.1.100) 56(84) bytes of data.
64 bytes from humphrey(192.168.1.100): icmp_seq=0 ttl=64 time=0.088 ms
64 bytes from humphrey(192.168.1.100): icmp_seq=1 ttl=64 time=0.081 ms
64 bytes from humphrey(192.168.1.100): icmp_seq=2 ttl=64 time=0.086 ms
64 bytes from humphrey(192.168.1.100): icmp_seq=3 ttl=64 time=0.084 ms

and you press Ctrl+C to stop the process.

However, sometimes ping will be set up so that it isn't so informative. It may just reply:
humphrey is alive

in which case you have a couple of alternatives.

If you want to find the IP address of the current UNIX machine you can use the command:
cat /etc/hosts | grep `hostname` | awk '{print $1}'

Note that the first quote marks are backticks (you can replace `hostname` with the host name of the current machine if you prefer, but this makes the command less portable), and the second set of quote marks are normal, straight, single quotes.

If this doesn't work it's probably because you aren't allowed to see the contents of /etc/hosts, but most system administrators trust their firewall enough to leave this file readable by domain users.

If you want to find out the IP address of another machine on the network, try:
ypcat hosts | grep hostname

See also:
Find a host name given an IP address

My previous posting made me think that I should probably note down something about redirecting standard output and standard error. This can be very useful, now and again, but rarely enough to make it easy to forget how it's done.

Redirection of standard output is easy:
> in most cases
< to go the other way
>> or << to append.

Redirecting standard error is the one I tend to forget.

In the C shell you can use the following to redirect standard error:

(command) >& file

For example:

(tar cvf tarfile.tar myprogramdirectory) >& log.txt

This tars up a directory and sends the verbose output to the log.txt file,
rather than the screen, so that you can peruse it later.

You can redirect standard output and standard error independently like so:

(command > outputfile) >& errorfile

For example:

(ls mydirectory > directorylisting.txt) >& ls_error.txt

This sends a directory listing to a text file.
If there's an error (e.g. there's no such directory)
the error message gets put in the ls_error.txt file.

In bash (and most other shells), you use 2> to redirect standard error.
So the bash version of the previous example is:

(ls mydirectory > directorylisting.txt) 2> ls_error.txt

A little reminder (because I hadn't done it for a while and had to look it up) of how to tar and zip and unzip and untar files.

First up, a recap on tarring and zipping.
Tarring pulls a directory full of files and subdirectories together into a single file. Zipping a file compresses it.

> To tar a directory use the command:

tar cvf destinationfile.tar directory

This creates a file called destinationfile.tar containing the entire contents of the directory called directory (including any subdirectories). The c flag means create (rather than append to an existing file). The v flag means use verbose mode (i.e. print a notification of each file that is tarred). The f flag means you're going to specify the name of the tar file rather than using the value of the TAPE environment variable or the default value defined in /etc/default/tar.

The verbose details get printed to standard error, which is the screen by default. You can redirect standard error to a file if you want to capture the output. This is a good idea if you are tarring a lot of files, otherwise the details of any problems appear briefly on the screen before being replaced by more information. If you capture the verbose details you can check what happened when the process completes. To capture the verbose details for the previous example:

In the C shell:

(tar cvf destinationfile.tar directory) >& log.txt

In bash:

(tar cvf destinationfile.tar directory) 2> log.txt

> Once you've got your tar file, nine times out of ten you're going to want to zip it.

To zip the tar file, use gzip:

gzip destinationfile.tar

This replaces destinationfile.tar with a compressed file called destinationfile.tar.gz. If you want to keep the original tar file, take a copy of it before zipping it.

> To unzip a file zipped with gzip, use gunzip:

gunzip destinationfile.tar.gz

As you'd expect, this replaces destinationfile.tar.gz with a decompressed file called destinationfile.tar.

> To untar your tar file:

tar xvf destinationfile.tar

This unpacks the tar file, recreating the original tarred directory as a subdirectory of the current directory. If a directory of the same name already exists the files from the tar file are added to it, overwriting any files of the same name. Existing files with different names are not removed. The tar file is not deleted.

> If you want to see what's in a tar file, without going to the lengths of untarring it, use the command:

tar tvf tarfile.tar

The t flag lists the table of contents for the file. If you want to check whether the tar file contains a file called myfile.fm, you can use the command:

tar tf tarfile.tar *myfile.fm

If you want to check for files called alsfile.txt, alistairsfile.fm, bobsfile.doc, etc. you could use the command:

tar tvf tmp.tar | grep .*sfile\....

The \. is the dot character. The final three dots is the regexp way of saying any three characters.

Using this method, you can untar selected files. For example, to untar just files whose names end .fm use the command:

tar xvf tarfile.tar `tar tf tarfile.tar | grep \.fm$`

In this command the dollar sign is the regexp way of denoting the end of a line.
This command would unpack all the .fm files, recreating the directory structure in which they originally lived.

If you are untarring a single file and you don't want to recreate all the directories that originally housed it, but you just want the file to be unpacked into the current directory, you can use the following syntax:

tar xvfO tarfile.tar *myfile.txt > myfile.txt

The O flag (that's a capital "oh") isn't documented in the man page, but I just tried it and it had the desired effect. It sends the output of the process to standard output, which allows you to redirect it to a file.

However, beware! If you use a command such as:

tar xvfO tarfile.tar `tar tf tarfile.tar | grep .*file\.txt$` > myfile.txt

you are asking for trouble, because more than one file may be matched by grep and unpacked by tar, and the contents of all of the unpacked files will end up in the specified output file (myfile.txt in this case).

Today's big news (for those of us it affects) is Microsoft's decision to give away the new release of Services for UNIX. SFU 3.5 will be released by the end of this week, apparently, and will be available as a free download.

See www.informationweek.com/story/showArticle.jhtml?articleID=17300643 for the full story.

The company I work for uses SFU to provide its server-side software on Windows servers. The code was originally written to run on UNIX (most of it tailored for Solaris) but SFU provides and easyish way to port to Windows.

Personally I like SFU. It's a big improvement on its predecessor (Interix), and it works pretty well. It allows you to have something very like UNIX running on your Windows machine, without having to dual boot or run VMware, and in my experience it's much easier to install and maintain than cygwin.

So I'm very pleased that 3.5 will be free. However, my main SFU gripe is that you can't install it on XP Home, which is what I have on my main home PC. It will only install on Professional – either Windows 2000 or XP. This means when I'm working from home I have to use my Win2k laptop as the server and my main desktop as a client. My Dell Latitude takes ages to boot up, so this setup can be a pain. Will 3.5 run on XP Home? Guffaw, guffaw!

timestamp.com is a useful site if you need to calculate the UNIX time stamp for a particular date. There's a downloadable program is this is something you want to be able to do offline.

The site also includes a paragraph headed What happens on July 8, 2038?, which describes the UNIX date of death, when 32-bit processors run out of numbers for date stamps.

Another site I came across that might be useful if you're looking for a quick and basic introduction to XML is Learn XML in 11.5 minutes.

I spent some time over the weekend starting to design the home page for this website. Lots more to do, so I haven't uploaded anything yet, but it should be ready before too much longer.