Setup

It is assumed here you already have a DETER account and password, created following these instructions. Please log in to DETER and "Begin an Experiment," naming it "comparativeUNIX-xxx" (where xxx is some suffix like your initials likely to be unique to avoid name conflict with other students' experiments) and loading in this network specification (.ns) file (the file is inside a zip file, unzip after downloading).

Swap your new experiment in.

To interact with your nodes you need to gain an interface to each. You gain a terminal window interface to any of the nodes by "double ssh," connecting to users.isi.deterlab.net and from there to the node. For example, to connect to node FreeBSD:

ssh ‹your account name›@users.isi.deterlab.net
ssh FreeBSD.comparativeUNIX.SMC-CS41.isi.deterlab.net

(Important: This documentation is written as if the experiment name is "comparativeUNIX". The real name of your experiment being the variation comparativeUNIX-xxx, you should substitute the real name for your particular experiment wherever you see this document using "comparativeUNIX".)

Set up your monitor screen to contain 3 terminal windows, one to each of the experiment nodes arranged as in the graphic below. To do so first use ssh to get 3 terminal window connections to users.isi.deterlab.net, then from them again to the 3 nodes respectively as above. Your screen will look something like the following, with the windows stacked in the same order, and the title bars accessibly arranged for single-click selection of the window of any desired node. You are logged in on each machine under your own, non-root user account.

(As a possible alternative, there is a utility called "screen" installed on users.isi.deterlab.net. It is a character-mode program allowing you to open mulitple remote sessions and show them alternately or in split-screen.)

Tasks

Let's start by running a program called uname. Find out somthing about it. On ubuntu please run:

man uname | head

We're told that the purpose of uname ("unix name") is to "print system information." Good, that's what we're interested in. On all 3 platforms, ask what the kernel name is of the UNIX that's running:

uname -s

Two Linux and one FreeBSD. We already knew that. So CentOS and ubuntu run the same OS. No they don't! On all the platforms, query the release and version levels for more detail:

uname -r
uname -v

So even the ones that are both running linux aren't both running the same linux. Which one is running the more recent version, CentOS or ubuntu? So ubuntu runs the 3.2 version of linux. No it doesn't! This ubuntu does, but not last year's or next year's ubuntu. Older versions of ubuntu run older versions of linux, and newer newer. So which version of ubuntu is this one? On all 3 platforms try:

cat /etc/issue

Anything useful? Any differences in behavior? Is FreeBSD a distribution or an operating system?

We have to contend with different operating systems, different distributions, what about the shells? Those too. Most shells (not necessarily all!) maintain a variable named SHELL that contains the answer. Identifying our distribution or OS does not identify our shell; they're independent. There are serveral ways to try to identify the shell. On the 3 platforms:

ps ax | grep $$

in order to find the entry in the running process list for our running shell. We will locate it in the list by its process number ($$ gives us that). All 3 show tcsh (the c shell). Reinforce that observation, by running on all 3:

grep $(whoami) /etc/passwd

and observing the last field in the user record. It holds the shell file to run whenever you successfully log in. If you are running tcsh, this is why. Yes, all 3 passwd files show tcsh to be your login shell. Now become root, on all 3 nodes:

sudo su -

and again test on all 3 nodes what shell you are running, and what shell you are supposed to be running:

ps ax | grep $$
grep $(whoami) /etc/passwd

Looks OK, except ubuntu's shell process test seems a little inconclusive (shows the "su" without mentioning any shell). Maybe the shell itself has a "reveal my version" option. Run whichever shell the /etc/passwd test revealed, giving absolute pathname, and try a likely option:

/bin/bash --version

for CentOS and ubuntu or:

/bin/csh --version

for FreeBSD. FreeBSD is running csh for root, same as it was for your pre-su non-root account, while both linuxes run bash following su (what about the csh's they were running before, did those terminate?). Both linuxes are running the same shell, bash, but not really exactly the same because they are different versions. Which is the more recent? A shell is just a shell. That is, merely some particular program running under the supporting local operating system like any other program. And there are different shells out there, we're looking at two. We know that both tsch and bash are present on both CentOS and ubuntu, we saw both running. As well, a copy of bash is present on FreeBSD. If you wanted you could run it and operate in bash instead of tcsh. To view both shells sitting on each computer, on all 3:

which bash tcsh

And there are some other shells installed on these boxes, and still more that could be obtained and installed. What is the import of having one shell versus another? Behavior! They are more similar than different but are different. Variable creation and assignment offers one example. Try this on both CentOS (where bash is currently running) and FreeBSD (where it's tcsh):

set y=5; echo $y
x=6; echo $x

On each platform one of these works and the other doesn't. Which one works on bash? on tcsh?

These are differences among shells. Can we see any differences among the operating systems themselves? Each operating system knows (learns at boot) something about the hardware on which it's running. Usually there's a way to query it about that. But how the information is stored and queried differ. If you want to know about the cpu on one of the linux nodes:

cat /proc/cpuinfo

but on the FreeBSD node:

sysctl hw.model

At the application level, there will be differences between one and another copy of the same program, such as the vi editor. Create a 20-line text file for vi on each platform:

seq 1 20 | sed 's/^/This is line number /g' | tee testfile

Oops, didn't work on FreeBSD. There, try jot instead of seq:

jot 20 1 | sed 's/^/This is line number /g' | tee testfile

Now on each node open "testfile" in vi

vi testfile

and within vi try to delete all of its 20 lines, in 2 stages. First on CentOS, once the file is open and the cursor on line 1, press 5 then dd in rapid succession. It means "delete 5 lines." Now 15 remain. Get rid of them by pressing 99 and dd in rapid succession. It means "delete 99 lines" and will erase the 15 lines it still has. Try the same in FreeBSD. What' happens (or doesn't) differently? This is a vi-versus-vi difference. What are these vi's? On CentOS and ubuntu:

vi --version

On FreeBSD, open vi (on any or no file) and give a last-line command within it by typing : (colon) then, at the last line prompt, "version" and press enter. (Leave vi, colon-q-exclamation). Following is a further sampling of various differences.

• awk
• route
• updatedb
• ifconfig
• log file
• read
• echo

awk: Linux features gawk (GNU awk) while on FreeBSD it's awk. Try these:

echo one two three | gawk '{print $2}'
echo one two three | awk '{print $2}'

route: I like to look at the route table like this (try it on all 3):

route -n

if you find it doesn't work then try:

netstat -rn

updatedb: This command builds a database for later consumption by the locate command. The database contains a snapshot listing of all the files in the filesystem, when updatedb runs. Try it on all 3:

updatedb

if you find it doesn't work then try:

/usr/libexec/locate.updatedb

ifconfig: Look at the differences in this command's output. Run on all 3:

ifconfig

The format differs. If you wrote a shell script to obtain an IP address from this output, by extracting it from the second line of output for an interface, it would work in linux but break in FreeBSD. Note also the NIC nomenclature differs, eth versus em. And, in linux you only see the interfaces that are "up," while FreeBSD's ifconfig shows you all interfaces regardless.

log file: The main log file, used for log message placement by many programs, is /var/log/messages. A program to write arbitrary text into the log is logger. On all 3 try:

logger "This is a test"
tail /var/log/messages

if you find it doesn't work then try:

logger "This is a test"
tail /var/log/syslog

read The read command blocks (halts and waits) for keyboard input. It then discards the input, or places it in a variable if the variable's name is given as an argument.

echo "Press enter to learn what the moon is made of"; read; echo "Green cheese"

tcsh's read built-in demands at least one argument. So give it a throw-away argument x:

echo "Press enter to learn what the moon is made of"; read x; echo "Green cheese"

What about read's status as a shell builtin or a freestanding external executable? Look for an executable:

which read

There's no executable in CentOS or ubuntu, so it must be a builtin. There is one in FreeBSD however find the commentary about that in the man page:

man builtin | less

and look at the executable's source code:

cat /usr/bin/read

Executable or builtin, what's the verdict?

echo echo is famously a command whose development got out of hand, in terms of being taken in different directions by different programmers resulting in incompatible versions (a nightmare for script programmers, who prefer to use printf for that reason). One feature you may or may not have is the ability for echo to ouput control characters, like tab:

echo -e "One\tTwo\tThree\nFour\tFive\tSix"

What about echo's status as a shell builtin or a freestanding external executable? Look for an executable:

which echo

Executable or builtin?