[OS X TeX] OS X TeX newbie needs help installing TeX on non-boot volume

[Anthony Morton]

>> i-Installer (and other tetex distributions) install inside the 
>> /usr/local directory (not as an application bundle or such).
>
> I know.  And as I say, I want to make it install the software 
> somewhere else.

As someone mentioned, probably the most successful way of doing this, 
while keeping everything organised in the way expected under the Unix 
architecture, is to map the entire '/usr/local' file hierarchy to the 
desired location on your other volume.  The easiest way to do this is 
with a symbolic link.

Before you install *anything* whatsoever, go into Terminal and type 'ls 
/usr'.  This lists all the (visible) files in your '/usr' directory.  
Make sure there's no folder called 'local' - if there is then 
something's already been installed there and you'll probably want to 
zap it and re-install it later.  Assuming there's no 'local' directory 
and your other volume is mounted (called something like 
/Volumes/otherapps), do the following:

1. Create a folder called 'unix' on your 'otherapps' volume - this can 
be done in Terminal as
	sudo mkdir /Volumes/otherapps/unix
The 'sudo' bit ensures that the folder is owned by 'root' (the 
super-user), as all high-level folders should be.  Note that you need 
to type your account password to run commands as the super-user.

2. Make a symbolic link to /usr/local from this new folder:
	sudo ln -s /Volumes/otherapps/unix /usr/local

The folder 'unix' on the other volume will now replicate a Unix-like 
local file hierarchy, which will automatically be used as an 
installation location by Unix-like utilities such as i-Installer.  You 
can put any other Mac-like apps, documents, etc. on this other volume 
as long as you leave the 'unix' folder alone.

Of course, the folder doesn't have to be called 'unix' or even be at 
the top level on your 'otherapps' volume, as long as you specify the 
correct path to the folder at step 2 above.  If you ever need to wipe 
and reinstall your boot volume, you'll need to remember to recreate the 
link - this just means typing the command at step 2 once again after 
reinstalling.

The only things that will still want to be installed on your boot 
volume are a few applications like 'xfig' that use X11 (an attempt at a 
GUI for traditional Unix boxes).  Unfortunately there's not much you 
can do about this as Apple installs an X11 file hierarchy on the boot 
volume at /usr/X11R6 and any X11 apps have to go here.  But I'm 
guessing you won't be wanting to use many X11 apps anyway.  (One of my 
projects for an undefined time in the future is an Aqua port of xfig, 
assuming no-one's working on one already.)

(Having said all that, the 'ideal Unix way' to go about this would 
probably be to define /usr/local as a 'mount point', and have the other 
volume 'automount' at this location in the file system, rather than be 
referenced indirectly via a symbolic link.  But explaining how to set 
this up requires more knowledge of Unix administration than I'm 
confident about giving advice on.)

>> b) OS X has significantly mitigated these risks from my experience
>
> OS X is the reason I want to do it.  I never worried about the need to 
> wipe and re-install until I `upgraded' to this allegedly wonderful 
> `modern' (i.e., born in the 1960s) operating system, allegedly so much 
> better than what we had before.
>
> I've lost count of the number of times I've had to wipe and re-install 
> since I got OS X.  It's a major pain - compared to System 6 and System 
> 7 at least.  I never had to wipe and re-install when I used those OSes 
> (oops!  I lied - I did have to do that once, after a freeware disc 
> defragger did the dirty on me one day.  Well, serves me right, doesn't 
> it?)

It's unfortunate that you've had this experience, which is highly 
atypical for OS X.  Admittedly, the typical shell CLI in Unix-like 
systems is arcane, crufty and downright dangerous.  But Unix itself is 
one of the most stable and robust operating system architectures yet 
devised, which is why so many modern OSes are based on it.

What lets Unix-like systems down are two things:

1. The crufty command-line interface whose principles date from the 
1970s and are largely out of date.  NeXT/Apple have probably done a 
more successful job than any at putting a usable GUI on top of Unix 
which largely avoids the need to resort to the command line.  But there 
are still too many gaps, such as the one above, where use of the CLI is 
still necessary.  Most administration functions still aren't GUI-ified, 
which means going into Terminal to do things, and taking the risk that 
a typing error will hose your system (all too easy, particularly if you 
get into the habit of doing 'sudo -s' to run an entire shell session as 
the super-user).

2. The reliance on hard-coded paths.  One thing that takes a lot of 
getting used to when moving from a classic Mac OS to Unix is that the 
location of a file in the file system has semantic value.  If it's a 
'system' executable program it goes in /bin; if it's a 'user' 
executable program supplied by the vendor it goes in /usr/bin; if it's 
a user program supplied by a third party it goes in /usr/local/bin; if 
it's a manual page it goes in /man or /usr/man or /usr/local/man 
depending on its status, and so on.  Again, this stems from a 1970s 
approach to keeping things organised, and OS X does a reasonable job of 
keeping this separate from most of what happens at the user level, so 
you can throw documents and many applications wherever you like without 
things going wrong.  But 'traditional' Unix applications like TeX still 
have to go in the designated place (or at least somewhere that appears 
to be the designated place).

The chief tip for avoiding catastrophic failures on OS X is to never 
enable the root user, and to instead run commands one at a time with 
'sudo' if you need to do something with 'root' privileges.

Cheers,
Tony M.

--------------------- Info ---------------------
Mac-TeX Website: http://www.esm.psu.edu/mac-tex/
           & FAQ: http://latex.yauh.de/faq/
TeX FAQ: http://www.tex.ac.uk/faq
List Post: <mailto:MacOSX-TeX at email.esm.psu.edu>