Into The Union Mac OS
From OS X Scientific Computing
December 2005 Mac OS X lets you use 'union' mounts. Imagine you have a directory with files in it, and you then mount some device on that directory. Apple’s Mac OS X was so well thought-out, and my new machine was fast and powerful. When it came time to upgrade in 2012, I got another MacBook Pro without even thinking about it.
To access Console press ⌘+space and type 'console' in the Spotlight box that appears.
|
Introduction
Scientific computing is typically carried out on computers equipped with the unix operating system. There are many varieties, or 'flavors,' of unix, including Irix, Solaris, BSD, GNU/Linux and so on, each of which has its own peculiarities in terms of file system structure and occasionally command syntax, but they all tend to be quite similar and function according to the same principles. The flavor of unix on Apple computers running Mac OS X is called Darwin, and it is closely related to BSD, from which it has evolved. Unlike Cygwin, a unix emulator that can be grafted onto the Microsoft Windows operating system, Darwin is the fundamental core of the Mac OS X operating system. The whole of Mac OS X is thus a superset of unix; the Aqua graphical user interface (GUI) of OS X provides an aesthetically pleasing and functionally elegant mechanism by which the user can control the computer via the underlying unix operating system using mouse clicks in application windows rather than typing cryptic unix commands.
The OS X Aqua GUI interface shields the naive and routine users, who are mainly concerned with running applications such as Microsoft Word, Adobe Photoshop and so on, from the complexity of the underlying unix operating system. It also provides an intuitive, elegant and simplified mechanism for carrying out complex system administrative tasks whose command-line equivalents are often obscure to all but the most seasoned unix veteran. But between these extremes lies the need for command-line access to carry out scientific (and other) computing tasks. Fortunately, Apple also provides easy access to the unix command line environment for users who require it.
Apple's OS X operating system does not simply provide access to unix commands. OS X is unix. This is an important point, because it entails that any operation carried out in the GUI interface in OS X can, at least in principle (and almost always in practice), be carried out on the unix command line. It may be incredibly cumbersome to do so, but it is almost always possible, an important point to consider when writing shell scripts to automate routine tasks.
The Filesystem Structure
Apple has a a filesystem structure rather different from what one finds with canonical unix systems. This section gives an overview of the main points.
You Need to Install X-Windows
Apple's native windowing system is not X11. Fortunately, it is easy to install X11 on OS X, so you can have the best of both worlds.
- X11 page
The Terminal Application and Alternatives
OS X includes an application, Terminal.app, that provides unfettered command-line access to the entire unix underpinnings of the operating system. The Terminal application (the .app suffix on all applications is hidden from view in the GUI) may be found in the directory /Applications/Utilities. Its icon looks like (surprise) a terminal. In addition to the Terminal application that Apple provides with OS X, other options are available. iTerm.app is a free, third-party application that is similar to Terminal.app but has additional functionality, most notably tabbed windows. Similarly, xterm is provided with Apple's X11.app (see section [#xwindows_section 1.2]), and any other x-windows-based terminal program may also be installed, so a user who requires all the familiar functionality of xterm or its brethren need not compromise.
- See also Editors for OS X
In order to create or to edit the contents of a unix (ascii) text file, you will need to use a text editing program. There are at least three types to choose from. The simplest and most ubiquitous are command-line editors, such as vi(m), pico and emacs, and those come with OS X. An enhanced user experience is made possible by editors augmented with a graphical user interface. These include X-windows based GUI editors such as gvim and xemacs, as well as true OS X native Aqua text editor applications such as the TextEdit.app that comes with OS X, as well as payware editors. It is a good idea to master one of the command-line editors (vim or emacs), as these are the most versitile and ubiquitous, and sometimes may be the only realistic possibility when editing files while logged in to a remote account. My personal favorite is vi(m), which has powerful, albeit cryptic, syntax, and is much more lightweight than emacs.
I've created a separate wiki section called Editors for OS X that goes into much more detail and has links to specific options.
Line endings differ for each of unix files, standard Mac files, and Windows files. It is critical to save text files with unix line endings if the files are to be used as input for unix programs. If, for example, you create a file in Microsoft Word (a bad idea) and save it as a text file, it will, by default, put non-unix line endings (carriage return special characters) in the file. A simple way to change all line endings into the proper unix form is to use perl, taking advantage of the regular expressions n for unix line endings and r for carriage returns. To convert a file with Mac line endings to unix line endings, use:
To change a file having DOS line endings to one with unix line endings, use:
When you start a unix terminal session, a program known as a unix shell command interpreter, or simply a shell, is immediately invoked. The shell accepts commands and prints responses; it is thus the primary means by which the user communicates with the unix operating system. Several unix shells are distributed with Mac OS X. These are tcsh, bash and zsh; ksh joins the family with 10.4.x. Each has its own syntax, but tcsh is fundamentally different from the others. (If you look at what shell programs are provided in the /bin directory, you will find, in addition to those listed, sh and csh. These are in fact the same binary files as bash and tcsh, respectively.) Here are a couple of simple but essential examples of how the syntax differs between (t)csh and the others:
Operation | tcsh or csh syntax | zsh, bash, sh, ksh syntax |
setting an environment variable | setenv EDITOR vim | export EDITOR=vim |
making an alias | alias calc ``open -a calculator | alias calc=``open -a calculator |
The Default Unix Shell on OS X
You can see that the two sets of commands are incompatable. If you did a new or clean install of OS X version 10.3 or more recent, the default user shell is bash. Bash is essentially an enhanced and GNU freeware version of the original Bourne shell, sh. If you have previous experience with bash (it is often the default on GNU/Linux installations), this should make the OS X command-line experience rather familiar. But if you are unfamiliar with bash, I recommend switching your shell either to tcsh or to zsh, as both of these are more user-friendly. If you upgraded from, or are still using, OS X version 10.2.x, 10.1.x or 10.0.x, the default user shell will be tcsh. tcsh is an enhanced version of csh, the ``c-shell,' which is more user-friendly than the Bourne shell, but early implementations were buggy, and the programming syntax is peculiar, so it developed a somewhat undeserved bad reputation.
Properties of the OS X Unix Shells
Each of the shells has its unique properties. The original unix shell was sh, or the Bourne shell. Its syntax tended to be a bit cryptic and its behavior user-unfriendly. In addition to being the command-line user interface, the shell is designed to be a programming language in which one can write shell scripts that are interpreted rather than compiled. The Korn shell, ksh, was developed as an enhanced shell programming environment, and some user-friendly features were also incorporated. Its syntax is rather similar to, but richer than, sh. The C-shell implemented a different syntax, one that is apparently more natural to those who know the C programming language. Early implementations tended to be buggy, and unlike ksh and later versions of sh (and zsh), there is no way to define functions (or subroutines) in csh, making shell programming more difficult. tcsh is an enhanced (and corrected) version of csh, and is considerably more user-friendly, introducing command-line completions (enabling the user to hit the tab key to complete typing of uniquely specified commands) and syntactic improvements.
Bash is the GNU Free Software Foundation re-implementation of sh designed for the GNU/linux operating system but available for installation on any platform. Invoked with the command sh, it emulates the canonical sh faithfully, but invoked as bash, it provides many useful enhancements, both in terms of user-friendliness and programmability. It is, however, more terse and cryptic than tcsh and zsh. The Z-shell, zsh, combined the programming power and superior syntax of ksh with the best user-friendly aspects of tcsh, and then added many of its own enhancements, making it the most powerful and pleasant shell for user interaction and programming. A few of the essential unique features of each of these shells are listed in the table below.
Shell | Origin | Comments |
---|---|---|
sh | The original Bourne shell | present on every unix system |
ksh | The original Korn shell | richer shell programming environment than sh |
csh | The original C-shell | c-like syntax; early versions buggy |
tcsh | Enhanced C-shell | user-friendly and less buggy csh implementation |
bash | The GNU Bourne-again shell | enhanced and free sh implementation |
zsh | The Z shell | enhanced, user-friendly ksh-like shell |
Many scientists who use unix probably have gotten used to csh or tcsh without ever giving much thought to what shell they are using, but if you find yourself suddenly using one of the other shells, the different syntax can be frustrating. If you are a long-time tcsh user, you may be uncomfortable with bash. Furthermore, many scientific programs seem to assume in their user documentation that you are a (t)csh user. I find bash as a user shell a bit uncomfortable, and prefer tcsh or zsh. I have in fact made zsh my default user shell. zsh is the most user-friendly of all the shells, as well as the most powerful. (It is an enhanced version of ksh, but with all the user-friendly functionality of tcsh plus lots of other great things like recursive globbing, remote file completions, a whole bunch of really useful functions that are included, etc.).
Changing your Shell
If you want to return to being a tcsh user, or to become a zsh user, just type one of the following commands:
or
Creating Unix Shell Startup Files
When you open a Terminal or terminal-like application, it will invoke your default user shell. As the shell starts up, it looks for various system and user-created startup files that govern customizable settings for environment variables, the prompt, aliases, functions and so forth. What files are read depends upon which shell is invoked and which files are present. The user will need to create files in his or her home directory and include in them various commands in the appropriate syntax. Here is a listing of user shells along with what files will be read on startup. In several cases I have provided links to sample startup files (i.e., .bashrc, .bash_profile, .zshrc, .cshrc) to help get you started. These all include commands to set the DISPLAY variable properly and customizations for iTerm title bar and tab labels (these will also work for the title bar on Terminal.app and xterm). The files are commented to help you understand and change the customizable parts.
Shell | User files | Comments |
---|---|---|
bash | .bash_profile or .bashrc | .bashrc for non-login and .bash_profile for login shells |
ksh | .profile or .kshrc | .kshrc is always read |
tcsh | .login and .cshrc | .cshrc is always read |
zsh | .zlogin and .zshrc and .zshenv | .zshenv is always read; .zshrc almost always read |
Bash is unusual in that the .bashrc is always read on an invocation of bash, except in the case of an interactive login, when .bash_profile is read (if present). This is further complicated by the fact that an 'su' command (switch user) is issued, such as su - (switching to root), the bash shell behaves as sh behaves for compatibility reasons and reads .profile from the root's home directory. Also, by default, the root user, if enabled, has it's shell set to sh. So if you use the root account, you should use cash to your favorite shell there as well. For the root user, you can create a .profile that sources your user's .bashrc and .bash_profile. Because a login shell is reads .bash_profile and because Apple's Terminal.app performs a login as it's first step, it reads .bash_profile. However, when xterm and related terminals are started on OS X, depending on whether they invoke a login shell or not, .bashrc may be read. This can create massive headaches for the user who uses both types of terminals interchangeably.1.11
Newest Mac Os System
The simplest and most robust solution to this problem is to do the following:
1. Put all of your bash customizations into your .bash_profile file.
2. Put the following line into your .bash_profile to force it to run your .bashrc every time the shell runs your .bash_profile:
3. In /var/root (if you use root), create a .profile that sources your .bashrc and .bash_profile with the full path.
If you are trying to debug this, use the command 'logger' with a text string which you will see in the Console. Never use echo in any profile in the event you want to login using ssh.
One other note on .bashrc -- if you use it to setup important environment variables or modify the path, you must source it explicitly with a full path in scripts that are called by the system, say from a crontab or launchctl.
For the other shells, it is usually easiest to simply put all of your shell customizations into your .xshrc file.
The following example shows lines a bash, ksh or zsh user might include in his or her .bashrc or .kshrc or .zshrc file to set the DISPLAY environment variable. The first line tests to see if the DISPLAY environment variable has already been set. If it has not, then a value of :0.0 will be assigned to it and the value is exported.
For single individual zsh, ksh and bash users, we can use the following syntax:
For individual tcsh users (csh is tcsh on OS X), you should instead use the following syntax in your .cshrc file:
This works well for one user, but OS X permits multiple users to be logged on simultaneously via ``Fast User Switching.' A problem then arises for the second person to log in and start X11.app. Since DISPLAY=:0.0 for the first user, the second user most likely needs to have DISPLAY=:1.0, and the third user to start X11 most likely needs DISPLAY=:2.0 and so on. But what if the second user logs out before the fourth user logs in? We need a way to ensure that every user gets the correct DISPLAY variable set. If it is assigned the wrong number, launching X-windows based applications from Terminal.app and iTerm.app will fail. For that reason what I have put in the sample startup scripts (linked above in the table) is a bit more complex.
Why zsh Should Be the Default Shell on OS X
I've assembled a web page with the above title composed of a number of useful links to unix resources. It has become fairly popular, and I try to update it regularly. The main points are summarized below, with hypertext links in the pdf and html versions of this document. Readers of the printed document will find visiting the above website much easier than entering a bunch of links into a browser.
General Unix Links:
Unix tutorial for beginners
Unix for beginners by Gerard J. Kleywegt (written by an X-ray crystallographer). Comprehensive.
Unix for beginners by Ian Tickle (written by an X-ray crystallographer). Some Dos/unix conversions.
Unixhelp for Users Edinburgh Univ. (a bit more advanced)
A note about Unix Shells My page. (brief notes about [t]csh vs. sh-type shells).
Apple's Command Line Primer covers basic shell concepts, frequently used commands, environment variables, and running programs.
General Unix Books:
Learning the Unix Operating System, 5th ed. (good for the absolute beginner).
Using csh and tcsh (the next most basic book, but has a lot of useful stuff in it). tcsh was the default shell in Jaguar and is available in Panther. (Use chsh -s tcsh to switch back to it.)
Guide to zsh (A free, on-line, and extremely well-written pdf and html book on the best shell ever invented.)
From Bash to Z shell An excellent more advanced introductory book, written by the zsh folks, that gives a highly useful introduction to bash (the default shell in Panther and Tiger) and zsh (what should have been the default shell in Panther and Tiger).
Unix in a Nutshell (a useful reference).
Books and tutorials specific to Mac OS X Unix:
Mac OS X has brought the world of unix to a new set of users, and it has some non-canonical quirks. Here are some helpful books:
Mac OS X Unix Tutorial
Learning Unix for Mac OS X, 2nd Edition (Very basic treatment for an absolute beginner.)
Mac OS X for Unix Geeks (introduce OS X to unix-oriented folks).
Unix for Mac OS X: Visual QuickPro Guide -- a couple of chapers are on line here: Unix for Mac OS X
OS X Unleashed, 4th ed. (basic to advanced). A large, very comprehensive book with stuff for beginners and more seasoned folks.
Gary Kerbaugh's Picks: A Valuable Suggested Reading List for OS X Unix
Bash on Mac OS X: O'Reilly macdevcenter.com tutorial
Zsh on OS X (My propaganda and how-to page for using the best user shell ever invented on the best operating system ever invented).
Some customization suggestions:
Here are some OS X applications and hacks that I can't live without.
Here are some ways to make the terminal-finder interactions more integrated.
Configuring zsh on OS X is easy with these drop-in scripts that work 'out of the box.'
New Mac Os 11
Shell Scripting and scripting languages:
Unix shell commands can be put together to make fairly elaborate programs that you execute from a file called a shell script. These programs do not need to be compiled and are generally pretty easy to read and modify for your own needs. Here are a few places to start:
Unix shell scripting
Mendel Cooper's Advanced Bash Scripting Guide (A definitive source for sh-type scripting.)
Python scripting tutorial
Python for Science
Terminal.app starts and immediately launches a unix command
Terminal sessions that perform preprogrammed functions can be saved and initiated when needed. Occasionally the user may do this inadvertently, with surprising results. By far the easiest way to deal with this is to reset the Terminal application's user preferences by deleting the file
in the user's home directory.
Terminal.app is really small
If Apple's terminal window is very small and can't be resized, make sure the Monaco font is enabled. Terminal needs Apple's Monaco font. If that font is disabled or missing, the Terminal window will be really small and unusable. Use Font Book to enable the ''Monaco Font'' in the All Fonts collection. If you have previously picked a different custom font for Terminal windows, enable that font, or select a different font.
Running X11 programs that require 256 colors or 8-bit display
Launching an X-windows based unix program fails
If you try to launch an X-windows based unix program and obtain an error of the form
or
or
then it is most likely that you forgot to start Apple's X11.app. You can launch it from the command line by issuing the command open -a X11, double-click on the application's icon in /Applications/Utilities, or simply add it to your ``Accounts' System Preferences ``Login Items'.
If you try to launch an X-windows based unix program and obtain an error of the form
and X11 is in fact running, it probably indicates that DISPLAY has been set incorrectly. This happens when multiple instances of X11 are running, at least one of which was started by someone else (using Fast User Switching) and they have set DISPLAY to :0.0. In that case, issue the command
If this returns, for example, the value :2.0, then set DISPLAY to :2.0.
If you try to launch an X-windows based unix program and obtain an error of the form
(where a number is not specified) and X11 is in fact running, it probably indicates that the DISPLAY environment variable has not been set. Use the procedure above or enter the appropriate commands into your shell startup files as described in Section 1.5.4 and initiate a new shell session.
If you launch X11.app and your blood pressure goes up because an xterm immediately appears, you can copy the file /etc/X11/xinit/xinitrc to .xinitrc in your home directory and comment out or delete the line xterm & in that file.
Into The Union Mac Os 11
The Apple OS X Bulletin Board
Apple maintains a bulletin board discussion forum website where many knowledgeable and helpful people congregate. I have learned quite a bit, and have received generous help with several problems, from the Apple unix forum.