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

[Rowland McDonnell]

> 
> >> 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.

Aha!  Gotcha - thanks!  I didn't know that's what was being suggested
and thank you for explaining.

I think I might be able to get somewhere with your suggestions and
explanations (he said, after having read all the way through).  Very
informative and helpful - cheers!

>  The easiest way to do this is 
> with a symbolic link.

Okay.

> 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. 

Umm.  There appears to be quite a lot of stuff there.  Why would I want
to remove it?  That is, is there no way of installing teTeX and friends
without having to delete already installed software?

(complication: it seems I lied when I said I'd not used i-installer to
install anything.  Looking in that folder shows me signs of TeX-related
stuff, so I must have told i-installer to install things).

Having said *that*, I'm not sure there's anything in there aside from
Virex that's not TeX-related, so wiping out the whole lot and
re-installing wouldn't be painful.

> 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

(Called unix or anything else I like, I take it?)

> - 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.

Okay.  Does that mean that *ANYTHING* meant to be installed in
/usr/local will end up being put on the other volume?

I ask because it looks like that is - inescapably - the case, and I'm
wondering about the effect on function when installed software finds
itself somewhere other than it was expecting.  Or does this symbolic
linking business work it all out for you?

>  You 
> can put any other Mac-like apps, documents, etc. on this other volume 
> as long as you leave the 'unix' folder alone.

Righto.

> 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.

Gotcha - but that's pretty straightforward.

> 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.

I'm guessing that I'll want to use quite a few, from what I've seen.
Unless, of course, they've been ported to Aqua.  I'm not looking forward
to it - I've had a look at X11 as installed, and I can't figure out
basic usage.

>  (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.)

<grin>  *And* it sounds a bit scary to me.  I feel I understand symbolic
links.

> >> 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. 

Odd that.  I've heard of a lot of other people in a similar position to
me - not so much since 10.3 came out, it must be said.

> Admittedly, the typical shell CLI in Unix-like 
> systems is arcane, crufty and downright dangerous. 

Actually, I rather like command shells and find them less arcane,
crufty, and dangerous than GUIs for two reasons: firstly, one can find
out what they do; and secondly, one can tell them what to do in a
reliable, easily recorded, easiliy repeatable, and above all efficient
and very easy fashion.  Just type some words, which you can record in a
text file.  Much less error-prone than a GUI, much faster, and all that.

Admittedly what you actually have to type tends to be quite arcane and
I'll admit I've not done half enough learning to have much of a clue
when typing at a Unix shell, but there you go.  I stopped being a
teenaged computer nerd some decades ago.

> 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.

Hmm...  I used Unix boxes in the late 1980s and early 1990s.  Rebooting
tended to occur after power-outs, or after OS upgrades, or every six
months as a preventative measure by a sysadmin who confessed that it was
just his paranoia that made him do it.

But it's not a staggeringly reliable OS - *really* reliable OSes are a
specialist field that I've heard of but never looked into.  It's just
that Unix is the most reliable and stable and solid OS widely used on
`normal' computers.

However, Apple's Unix implementation has not proven anything like as
reliable or usable as System 6.0.7 in my experience - still one of my
favourite OSes of all time because it's just so damned reliable and
fuss-free (okay, so maybe you can't actually do much with it in the
modern computing world).

So many modern OSes are based on Unix?  Er?  Well, there's the world of
Unix OSes which includes a bunch of commercial Unixes, a handful of free
Unixes, and MacOS X (which is something else).  What I can see is `the
BSD and System V branches of Unix' plus Apple's big leap.  Is that what
you mean, or am I missing something?

> 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.

The principles of that interface date back to the the dawn of writing,
not the 1970s.  More to the point, computer CLIs first turned up in the
1950s (just not widely - hell, there were even GUI experiments back
then).  I don't know what you mean by `out of date' - do you mean that
it's got documentation such that users could learn how to use it if they
could be bothered, unlike modern computer user interfaces?

I don't see this as letting anything down at all.  I'd much rather set
up system settings using text files than the GUI Apple forces us to use.
it's quicker and easier to do and to understand if you ask me.

I don't like being forced to use a GUI for everything - but there you
go.

>  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.

Yes.  `Largely'...  I've had to use it quite a lot.  Deleting
undeletable files, for example.  One set of undeletable files took Apple
a week to figure out how to nuke.

> 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

Yes, I know.  That's why I don't mess with certain things unless I've
got good reliable documentation and I'm certain that it's going to work
right and you'd be amazed at how carefully I check things sometimes
before hitting the `go' button.  Paranoia is what keeps my data safe.
Getting useful - let alone good or reliable - documentation is very hard
these days.

> (all too
> easy, particularly if you get into the habit of doing 'sudo -s' to
> run an entire shell session as the super-user).

I don't do that and I won't do that 'cos I was taught by really paranoid
sysadmins.

>2. The reliance on hard-coded paths. 

And this is the bit that *really* gets me.  Not that I'm blaming you or
anyone else, you understand.

> 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. 

Is *meant* to have such a value - you can of course subvert the
intentions of the file system hierarchy if you don't mind storing up
trouble for the future.  But I'm being picky, aren't I?

> 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. 

Gotcha - thanks.  I've never come across a concise and easily understood
description of that part of it before.

> Again, this stems
> from a 1970s approach to keeping things organised, 

Smells much older than that to me and it's a pretty good way to do it if
you ask me - except that the implementation we have lacks flexibility.

Oh, the particular design we have in Unix might well have been defined
in the 1970s (okay, it *was* defined in the 70s), but the approach is
much older.  It's the same as filing cabinets, isn't it?  And the same
approach, more or less, as used in OS X at the GUI level if you ask me.
I like it myself.

Don't knock what they did in the 1970s.  It was the end of the brief but
happy era of really skilled engineers and suchlike.  They're more or
less extinct now - those that are alive can't work as they used to
because the commercial world won't let 'em.  Just look at HP.

Good example, as it happens - I have two HP calculators.  One is a late
70s model, the other a late 80s model (HP 32E and 32S - the one is an
LCD and programmable update of the other with serious UI deficiencies
added).  I use the 1970s machine because it's easier to use and faster
to use and generally much nicer.  HP had basically lost it by the late
80s and don't let anything they say about `That bloody woman' they just
sacked affect your thinking - the rot set in and *then* they hired her
in order to drive the firm into the gutter as far as I can tell.

(And yes of course my 1970s HP calculator still works - I don't expect
the 80s model to last as long.  Both still pass their self-checks, mind.
Just checked ;-) )

> 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).

Hmm.  But why?  Surely it's just a matter of config files pointing at
particular pre-defined places, and one can change all that by changing
what the config files say?  I can see that it's easier if you don't have
to mess about like that.  I once installed emTeX (an excellent MS-DOS
TeX, for those who might not know - one of the best dvi previewers going
amongst other things) in a non-standard place and it took me about a
fortnight to get the blasted thing working.  Next time, I accepted the
defaults and it took an afternoon.

> 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.

I have to log on as root sometimes.  Don't like having an active root
account at all but it's the only way I can make proper backups easily.
Secure passwords, firewall, no remote logins possible, and no always on
'net connection.  I reckon I'll be okay.

But aside from that - oh, I don't often do the `root' thing.  I was
brought up properly in this respect.  But thank you for mentioning it.
The more it gets mentioned, the better.

Thank you once more,
Rowland.
--------------------- 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>