🚀 go-pugleaf

In article <9407@gryphon.COM> keithd@gryphon.COM (Keith Doyle) writes:
<At the risk of starting another round of heated controversy over the
<"correct" way to package programs, I've run into some new difficulties
<in trying to package a program to be as clean and easy-to-use as we
<dream of.

I think it's worth the risk. It's a problem that needs to be dealt
with.

<So what's the answer?
<
<1. make sure commercial applications never need boot time configurations
<such as ASSIGN or PATH?  

Commercial binaries should never look through _path_ now. They should
use absolute file names for all commands to be run. Using ASSIGN is
way to solve things for data files. For example:

:	There is a better solution, which I used in Sub Battle Simulator.
: Everytime I need to open a file, I call MyOpen(file,mode).  MyOpen first
: tries an open relative to the current directory, then it tries with
: the diskname (assignname) on the front.  This makes the program run on a
: harddisk with no assigns needed, from WB or CLI, even if you're in a different
: directory (though for a different directory it needs the assign).

I use a nearly identical solution. Except it's "Open(find_file(file),mode)".
That way, I can also do "OpenIFF(file_file(file))" and similar things.
The problem is, you have to do an assign if you want the binary to run
from anywhere other than the directory with all the goodies in it. And
it doesn't work for fonts (I understand that CBM is going to fix that
one, though)

There is, of course, a way to do something like the above, without
using ASSIGNs (there must be, as some programs are easy to install on
systems without any form of symbolic names). That's expressed right
here:

: I like "1." best. Use "s:" as an /etc/rc type directory, and just create a
: file that you can set up your environment with. When the program is run, it
: looks for the file. If it doesn't exist, it asks questions and creates it.

That file in s: is called a configuration file. I've got several in my
s: directory now - mrbackup files, vt100.init, and the shell & cli
-startup files (I think those qualify). For programs that don't
support a script language, you can just make it a binary file you read
on on top of a data structure that describes things. I use that
technic now for setting various parameters in programs.  The canonical
"Save Settings" and "Restore Factory Settings" menu entries. It would
be easy to add a "Directory where data files are stored" type of entry
to that, and then make the installation process create the file (with
factory settings if it doesn't exist), and patch in the directory
name. But that's ungainly. The ASSIGN mechanism is very nice, and
their ought to be a way to expliot it for doing installations. 

So, has someone got a better idea?

	<mike

--
All around my hat, I will wear the green willow.		Mike Meyer
And all around my hat, for a twelve-month and a day.	mwm@berkeley.edu
And if anyone should ask me, the reason why I'm wearing it,	ucbvax!mwm
It's all for my true love, who's far far away.		mwm@ucbjade.BITNET