ooblick.com
Insufficiently-advanced technology
Not under construction

Install scripts

Copyright © 1996 Andrew Arensburger
To: Mike McDonnell
Subject: Re: Don't you just hate it when... 
Date: Wed, 31 Jan 1996 03:25:39 -0500
From: Speaker-to-users <arensb>
On Wed, 13 Dec 1995 16:24:25 EST, mike@xxx.xxx.xxxx.xxx wrote:
> Since Mark just unloaded a few peeves on this long-suffering group, I
> want to solicit opinions about a pet peeve of mine: "user-friendly"
> installation and admin scripts.  I just hate these things.  Some
> examples are the hideous HP sysadmin "tool" called SAM, and almost
> anybody's software upgrade scripts.  

Heartily seconded! AAAARRRGHHH!!! Death to install scripts! And please note the strangely appropriate tagline below.

> The thing about these beasts is that they do things deeply in various
> file systems without telling you what they are doing and where they
> are doing it.  I do know, however, who they are doing "it" to: me.
> They seem to usually fail in a way that leaves the system in a mess
> and you don't then have much of a clue as to what to do to dig your
> way out of this mess.  

Believe it or not, there is such a thing as a good installation tool: the install utility for AmigaDOS interprets a Lisp-like script. This is sort of like PostScript, in that it's a complete programming language (someone wrote an `adventure'-like game in Install), but it's specialized for installing packages.

When you double-click on the icon to run Install on the installation script, the first thing you get is a dialog box:

Installing package FOO
(*) Simple installation (no questions asked)
( ) Intermediate installation (some questions asked)
( ) Expert installation (confirm all actions)

I, of course, go straight for the third option. So I get another dialog box:

Install how?
(*) Install for real
( ) Pretend to install (log all actions, but don't do anything)

Log file: ____________________

This, I think, gives one the best of all worlds: ease of use for the stupid and ignorant, do-the-right-thing-itude for the knowledgeable.

> Contrast this with the good old days of BSD on the VAX.  They had a few
> pages of written instructions.  I just had to edit the /etc/rc and
> /etc/rc.local files, perform a few mkdirs and move a few files around
> and, voila!, I went from 4.2 to 4.3.  If something went wrong, hey I did
> it all myself, so I knew what was likely to be the problem and could go
> fix it myself.  The "new world" of commercial Unices is much more
> "unfriendly" to me than the old, simple way of doing things.  I must not
> be the only one who hates these "Big Brother" scripts, am I?

This is one of the reasons I so love free software: no one writes install scripts for shareware. (``What, no one?'' ``No, no one.'' ``What, no one?'' ``Well... hardly anyone.'')

Just give me a Makefile and a README to steer her by...

Anyway, my horror story follows...

I recently had to reinstall Multiwrite, the front-end for a CD-ROM burner. It comes with not one, not two, but three install scripts! The software comes on three (or four, if you're using HP-UX) floppies. The first floppy has a filesystem; it holds system_install and system_install2.

You're supposed to run system_install cdrec or system_install multiwrite, depending on which half of the software you want to install. Amusingly enough, you can't say system_install cdrec multiwrite or system_install all.

Anyway, system_install copies the files on the first floppy to /tmp, then execs /tmp/system_install2. system_install2 pulls the rest of the software off of the other floppies (including INSTALL) and then execs INSTALL. INSTALL makes sure everything is in the right place, uncompresses a few files, and creates the front-end scripts (set a few environment variables, then exec the real tool).

The first sign of trouble was the first line of system_install:

	#! /bin/csh -f

AAARRRGGHHH!! See Tom Christiansen's article on why you shouldn't write C shell scripts. This is one of the great dividing lines between the clueful and the clueless.

So I printed this out to figure out what system_install was trying to do. After a while, I su-ed to `arnie' (my alter ego account, slightly less privileged than `nobody', created especially for things like this), and ran system_install.

It complained that I wasn't root.

Okay, so I comment that part out and try again. (BTW, Joe Sanjour pointed out to me that this is utterly bogus on AFS, since root doesn't have the privileges necessary to install stuff.)

It complains that ``This software will not run properly on any SunOS revision prior to SunOS 4.1.3''. I know that, that's why I'm running SunOS 4.1.4!

So I comment that out.

At this point, it tries to eject the first floppy, and mount the second one on /floppy. Neither of these is going to work: our floppy drives are automounted. You just stick in a floppy, cd /floppy/local, and it's there. Of course, `amd' doesn't like other programs trying to mount stuff on top of /floppy. Also, you can't just eject floppy, you have to un-automount it first.

(Of course, the other perpetual problem with `amd' is that it breaks `pwd': the directory /c/algron3/Mathematica is really mounted as /a/algron/c/algron3/Mathematica, but it should be referred to as /c/algron3/Mathematica.)

Did I mention that it assumes that you have a local floppy drive? What if the machine with the CD burner doesn't have a floppy drive, but some other machine on your network does? The install scripts are going to make an awful lot of unwarranted assumptions, aren't they?

So anyway, I give up, print out the three install scripts, and start stepping through them manually.

One line says

		set REM=" "

$REM is never used.

One script creates the installation directory, but doesn't bother to find out whether its parent exists (e.g., if you want to install the software in /mw/bin, it'll mkdir /mw/bin without checking to make sure that there's a /mw. I don't think it checks the exit status of `mkdir', either).

When system_install copies system_install2 to /tmp, it does the following:

	/bin/cp $WAS_THERE/system_install2 $TMP_DIR
	/bin/chmod ugo+x $TMP_DIR/system_install2

Um... why is there a `chmod'? Why not just make it executable on the floppy?

Actually, the two lines above are inside an if statement: they're only executed on Suns. This begs the question: if they can make system_install2 executable on other machines, why not on Suns?

Then it goes on to do:

	tar xvfp $WAS_THERE/distrib.tar > /dev/null

Call me crazy, but I rather think it's a waste of time specifying the "verbose" option to `tar', if you're going to throw it out to /dev/null anyway.

We then move on to system_install2, a script that (supposedly) runs as root, but doesn't set its $PATH. <Shudder> Pretty much the same complaints as above, so we move on to the final script, INSTALL.

There's a loop in there that says:

	foreach f ( cdrecgui cdrec vmap_iso )
		chown root bin/$f
		chmod u+x bin/$f
		chmod g+x bin/$f
	end

I'm not sure whether this is cautious or stupid: the script is supposed to be run by `root', so any files it creates will be owned by `root'. Except that if you're not, you can't `chown' anyway, so what's the point? And once again, why `chmod'? (And why are there two of them?) Why not just get the permissions right on the distribution floppy?

Oh, did I mention that bin/cdrecgui and bin/cdrec don't exist?

Then, INSTALL asks you whether you're running OpenWindows or X. If you say `OpenWindows', it assumes that everything is under /usr/openwin, which is a reasonable default (except that you can't override it). The only problem here is that it does:

	set APPDFLT=/usr/openwin/lib/app-defaults
	set LIBDIR=$OPENWINHOME/lib

Pray tell, why not use $OPENWINHOME in the first line? Also, since this is a csh script, you need to check that $OPENWINHOME is set (which this script doesn't do).

If, however, you say that you're running X, it assumes that:

No, you can't override these defaults.

Eventually, INSTALL, with a lot of coaxing, got to the part where it creates front-end scripts. Yay! Well, not so fast, bucko! It uses constructs of the form

	echo "#! /bin/csh -f " >> thescript
	echo "some line " >> thescript

First of all, is there anything wrong with

	cat >thescript <<EOF
	#! /bin/csh
	some line
	another line
	EOT

? And even if there is, what's the deal with the blank at the end of every line?

At one point INSTALL tries to install an X app-defaults file (in /usr/lib/X11/app-defaults, naturally). I guess the authors must have figured that this might fail (it would have: /usr is nfs-mounted, so root is `nobody'), and added a line to set the appropriate environment variable if it wasn't installed in the expected place.

I dutifully went through and created the script manually, adding the line

	setenv XAPPLRESDIR /mw/MultiWrite/lib/X11/app-defaults

(you can't use $XUSERFILESEARCHPATH, because csh truncates that to 18 characters) and tried to run the result. No go. It dumped core. One error message suggested that I try setting $NLSDIR. I tried. I tried setting both $NLSDIR and $XNLSDIR (did you know that they have different syntaxes, and interfere with each other?). I experimented for a whole afternoon. No go.

As it turned out, my problem was that I was typing the script in by hand. When I tried copying lines from INSTALL and pasting them into the generated script, it worked. Guess what? There was a typo in the script:

	setenv XAPPLERESDIR <appropriate-directory>

I ran `strings' and `trace' on the executable. Nowhere does it ever refer to XAPPLE(with-an-E)RESDIR. This line is useless.

I haven't taken it out. Somehow it seemed appropriate that this script wouldn't work if it didn't have a typo.

-- 
Andrew Arensburger, Systems guy         Center for Automation Research
arensb@cfar.umd.edu                     University of Maryland
	      Have you clubbed an ignorant human today?

Footnotes

[1] dialog box: a window that prints a message like,

	File /tmp/foo exists. Overwrite? [Yes] [No]

and then waits for you to check the contents of file /tmp/foo, possibly renaming it or whatever, before you click on "[Yes]". Contrast with

monolog box: a window that prints a message much like a dialog box, but then grabs mouse and keyboard input and doesn't release it until you click on one of the buttons. OpenLook and MacOS use monolog boxes.

In the same vein, ask my why (free) Athena scrollbars are the best.

[2] They may not be pretty, but

There are lots of prettier scrollbars out there, but I haven't seen any that are quite as useful. With Athena scrollbars, you can page up and down through a window by left- and right-clicking on one spot.