Setup

Access the three environments via ssh from your internet connected computer.

ssh   -p 2211  student@unices.dmorgan.us    for Ubuntu

ssh   -p 2212  student@unices.dmorgan.us    for CentOS

ssh   -p 2213  student@unices.dmorgan.us    for FreeBSD

On all three machines the password for user account "student" is c$l@bLinuX (where the 3rd character is lowercase letter L).

Set up your monitor screen to contain 3 terminal windows, one for each of the platforms, in an arrangement similar to the one below.

 

Tasks

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

man uname | less

We're told that the purpose of uname ("unix name") is to show system information. Good, that's what we're interested in. Scan the three man pages, and exit from less with the q key when done. Are the pages identical? 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.11version 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. Identifying our distribution or OS does not identify our shell; they're independent. There are several ways to try to identify the shell. But first of all, what shells are installed anyway? It's not an ironclad test, but because most shells have a name that ends in sh and whose executables live in /bin, try looking and see what we come up with:

ls -l /bin/*sh

In /bin, we see CentOS there appear to be 3 different shells. A couple of them have alternate names (so -called symbolic links or shortcuts). In Ubuntu 2 shells are shown, also with "nicknames." FreeBSD shows 3 shells but two of them are identical in size so maybe they are copies of the same thing. (Run the cmp command on the two files if you want to find out. If they differ cmp will tell you so and leave exit status 1, if not it will return silently and leave exit status 0.) So among our 3 platforms we have an assortment of shells. On each platform there's a different mix of shells. And other shells exist that don't happen to be installed here on any of our machines (e.g., zsh). bash is quite well known. So is csh. But what is this sh on FreeBSD? That was the name of the very first shell. But it has been obsoleted by today's successors. So on FreeBSD are we looking at a true historical relic, is it the original AT&T shell? man pages often say something about a command's history or versioning near the page bottom. Check the man pages for each of the shells you have discovered. Is FreeBSD's sh the original shell? What is its relationship to CentOS's sh? to Ubuntu's sh?

You might see if the shell will simply tell you what it is, if only you ask with a -version, --version, or -v option. On the various shells give it a try. For example maybe:

/bin/bash --version     or    /bin/sh -version

What the relationship between Ubuntu's dash and FreeBSD's sh is indicated in their man pages?

Most shells (not necessarily all!) maintain a variable named SHELL that contains the answer. Try it on each platform:

echo  $SHELL

Apparently whichever shells we have here all support the variable. We see a mix of values for SHELL: /bin/csh for CentOS, /bin/bash for Ubuntu, and /bin/sh for FreeBSD.

The process list is another place to look. 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). Again we see a mix, "-csh" for CentOS, "-bash" for Ubuntu, and "-sh" for FreeBSD. This seems to comport with the above SHELL results.

A pretty definitive approach is to look in the /etc/passwd file for the current login user, since whatever shell he is running stemmed from the shell field in his user record. On the three platforms:

grep $(whoami) /etc/passwd

The familiar  $( ... )  syntax for command substitution supplanted an earlier syntax, which placed back-ticks around the command. Here's the back tick:  `  which is in the upper left corner of modern keyboards sharing a key with the tilde. Don't confuse backtick with single quote. If the modern syntax fails, try the older one. Observe the last field in the user record. It holds the shell file to run whenever a given user successfully logs in. Whatever shell you are running after logging in, this is why you're running it. We see for "student" /bin/csh in CentOS, /bin/bash in Ubuntu, and /bin/sh in FreeBSD. Again this is in apparent agreement with the other tests.

 

 

Now become root, on all 3 nodes. To do that, one or the other or both of these might work:

sudo su -     or     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    or use backticks if $( ) doesn't work

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. For CentOS and ubuntu:

/bin/bash --version

or for FreeBSD:

/bin/csh --version

Ubuntu is running bash for root, same as it was for student account, while CentOS and FreeBSD run as root under different accounts than they did as student. Why, what determines?

 

	previously as student	currently as root
CentOS	csh	bash
Ubuntu	bash	bash
FreeBSD	sh	csh

Currently, with your root shell running, what about those student shells? 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 have seen several shells on each platform, either running live or on the disk as executables-in-waiting. If you wanted you could run any installed shell from any running shell. To view shells sitting on each computer, on all 3 platforms:

which  bash  tcsh  csh  sh  ksh  dash

("which" does the same PATH search for executables as when you execute them, but stops short of actually executing, serving to find). Beyond the shells installed on these boxes are still more that could be obtained and installed if desired. 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 and Ubuntu (where bash is currently running) and FreeBSD (where it's csh):

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 csh?

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, by typing 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 files seen 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. (To see the ones ifconfig didn't show you in linux, tell it you want them all:   ifconfig -a

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. But find the commentary about that in the man page:

man builtin | less

Do the executable and the builtin really differ? 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 output 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?