Comparing UNIX environments
  differences between kernels
  differences between shells
  differences between applications
Though the most fundamental operating system in computer science, development of UNIX over its 40 years has split and branched into a thousand variations. The original AT&T code base led to several commercial flavors like HP/UX (Hewlett-Packard), AIX (IBM), and Solaris (Sun Microsystems, now Oracle). Others resulted from the very major additions to the code base by the University of California at Berkeley. Berkeley's contributions live on in non-commercial versions also, like FreeBSD, OpenBSD, NetBSD. And upstart linux arose from a fresh effort starting in 1991 that very successfully mimicked the outward behavior of a UNIX environment and its components, but without a shared codebase. Linux (which is unitary) was then delivered in many "distributions" (which are not). They include slackware, gentoo, ubuntu, fedora, debian, and many others. Not to mention academic and experimental relatives like minix and the GNU operating system.
The similarities among "unices" outweigh the differences, much as with the dialects of a natural language like English. But those differences can be enough to get in the way. If you are familiar with one UNIX you are largely familiar with them all. But this exercise focuses on what may be unfamiliar. It sets 3 unices side by side to let us find where some of the differences lie. Broadly, between two platforms there can be differences of operating systems (kernels) themselves, between shells (your points of contact with everything), and/or between particular applications. When you experience some unfamiliar behavior when visiting a UNIX foreign to yours, try to attribute it correctly. You're running FreeBSD. You ask to delete more lines of a document in vi than actually exist, expecting deletion to end-of-document, and nothing happens. Don't "blame" FreeBSD. It's probably an older vi, and its vi's "fault," not FreeBSD's.
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).
Note: I experienced an error with the above command-line ssh command for connecting to CentOS. This is the command:: ssh -p 2212 student@unices.dmorgan.us The error message was: Unable to negotiate with 10.0.0.12 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 I was able to circumvent it with an added clause: ssh -p 2212 -oKexAlgorithms=+diffie-hellman-group1-sha1 student@unices.dmorgan.us The error is a function of the ssh
client you are using. You may not get it if you switch to a different
client, another way to solve. |
Set up your monitor screen to contain 3 terminal windows, one for each of the
platforms, in an arrangement similar to the one below.
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
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
/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
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 vivi 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.
echo one two three | gawk '{print $2}'
echo one two three | awk '{print $2}'
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
logger "This is a test"
tail /var/log/syslog
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?
Answer the following questions. Put your answers in a file named "capstone.txt" following these preparation and submittal instructions . Put the file in your assignments directory.
1. You found differences in the way variables must be assigned.8. The root account on one of the machines lacks a password. Which machine?
a. ubuntu
b. cento
c. freebsd