keithd@gryphon.COM (Keith Doyle) (12/09/88)
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. Not a demo contest entry, it would seem even more important
that it adhere to such standards, even though the problems I've been
experiencing are not specifically in conflict with the BADGE rules.
1. You apparently cannot do (easily) the equivalent of a an AmigaDOS
path xxx REMOVE
So, if you find it useful for a disk to add a command directory to the
current path for some reason, that disk's icon will not go away once
you remove it from the drive.
Why would you want to do such a thing? I can envision one scenario, where
you have a product that supplies several new CLI commands, and you have
an icon that you can click on (after having booted from any WB disk) that
does a path add, and gives you a NewCLI all ready for you to try out your
new commands.
One potential solution would be to do something like a "path >ram:foo"
and later do a "path reset" followed by the appropriate number of
"path xxx add"s reconstructing the users original environment. Doable,
but messy.
Further, if a developer would like to construct an auto-install program
that adds these new commands to the users C: directory, we have the
problem that likely as not, the novice is using a completely packed WB
floppy disk that has no room for added commands. Apparently Commodore has
encountered this problem and resolved it with questions like "would you
like to delete fonts?" or "would you like to delete narrator/translator?"
and various stuff like that. It would seem to be clear that a "make room
on the WB disk" could be a general utility that many developers could
make use of when installing certain types of new capabilities into a
users native environment. A lot of novice users have figured out how
to use a few basic CLI commands, but have no conception of how the C:
directory works, and are completely unsure of what they need or don't
need on their boot disk.
And the worst problem. Those of you who have installed programs under
MSDOS are presumably familiar with various INSTALL.BAT programs that
do auto installs on hard disks, many of which actually modify the
AUTOEXEC.BAT or CONFIG.SYS to add necessary boot-time configurations
for the new package.
A similar scenario on the Amiga might be a click-on icon that installs
a package on a hard disk. Let's say this package needs an Assign and a
path xxx add added to the startup-sequence, and the package is being
installed in DH1:.
Now lets investigate what the GVP hardcard builds as a boot sequence when
you click on *their* auto-install icon. I pick the GVP system because that's
what I've got.
DF0:s/startup-sequence looks about like this:
mount dh0:
binddrivers
dh0:c/execute dh0:GVPScripts/HDstartup-continue
Somewhere buried in HDstartup-continue is the mount for DH1:. Thus,
an ASSIGN foo: DH1:somedirectory is not doable until sometime after
this mount DH1: command.
How could an auto-install program address this situation?
1. Somehow determine if we have an autoboot rom or not.
2. if autoboot, start with DH0:s/startup-sequence
3. otherwise start with DF0:s/startup-sequence
4. chase startup sequence looking for execute commands, and
5. nest into subscripts looking for ????
What. What do we look for? LoadWB? EndCLI? The end of the script?
Then backup up and insert our ASSIGN and PATH commands? Do we really
want to even be modifying a script like this? (though I presume there
would be lots of *WARNING* messages letting you know what it is about
to do "Are You Sure" "Are You Sure You're Sure" "I Don't Think You're
REALLY Sure, Do You?"
Now, arguments that anyone who has a hard disk should be able to add
ASSIGN commands to his own startup-script are nice, but far from
reality. I talked to a user a couple of days ago, who had a brand
new Amiga 2000 with HD which was completely installed and setup by his
local dealer. He was trying to install packages onto his hard disk simply
by dragging the visible icons onto the hard disk. He couldn't drag the
entire disk icon onto the hard disk (as you would expect ala-MacIntosh)
because you get a "Can't move icon out of window" error or something like
that. We apparently don't have a "move entire disk into a drawer on the
HD" capability without the CLI. While some packages perhaps can be
installed simply by draggin the visible icons, certainly not all can.
So, I proceeded to spend about 1-1/2 hours with this guy explaining to
him how to use the CLI for the first time (CLI, what's that?) and
over-the-phone following his startup-sequence maze to a convienient
place to add the useful ASSIGNS, how to use ED etc. Fortunately he
had a GVP harddisk with which I had some familiarity. After it was
all over, he said "well that isn't all that hard". And he's right,
it isn't all that hard, but it would have been if he had tried to
figure it out for himself.
So what's the answer?
1. make sure commercial applications never need boot time configurations
such as ASSIGN or PATH?
2. chase startup script chains looking for something typical and adding
in the commands automatically after ultra-warning operator?
3. warn user that the Amiga is inherently unfriendly to novice Hard Disk
users who are unfamiliar with the CLI, so he'd better go out and buy a
good book, or drag his system back into his dealer and let *him* install
it?
4. ???? (god I hope there's a 4. and maybe a 5. and 6.)
Keith Doyle
gryphon!keithdsmaug@eneevax.UUCP (Kurt Lidl) (12/10/88)
In article <9407@gryphon.COM> keithd@gryphon.COM (Keith Doyle) writes: >[lots of stuff I don't want to comment about] > >Further, if a developer would like to construct an auto-install program >that adds these new commands to the users C: directory, we have the >problem that likely as not, the novice is using a completely packed WB ^^^^^^ >floppy disk that has no room for added commands. To say nothing about the "experienced" user. I have had my Amiga for just over a year, and am planning a hard disk addition soon. Right now, my bootdisk is over 90 percent full (with NO fonts, translator drivers, etc on it!) > >And the worst problem. Those of you who have installed programs under >MSDOS are presumably familiar with various INSTALL.BAT programs that >do auto installs on hard disks, many of which actually modify the >AUTOEXEC.BAT or CONFIG.SYS to add necessary boot-time configurations >for the new package. I am unfortunately EXTREMEMLY familar with the batch files available under Messy-DOS. I have YET (in over 5 years of experience) to see one that will allow me to fully install programs the way I want them to be installed. Even worse are the executable programs to install things, which are basically prompters for their own versions of copy... This type of programs are TOTALLY useless. The typical environment where I am installing software is a large (~4 gigabyte PC-LAN network) PC based network. No script for installation has ever worked right the first time. We follow fairly exacting rules on how we have packages installed, for ease of backups and ease of use. I just don't think it can be done without hand-tuning each installation script. >A similar scenario on the Amiga might be a click-on icon that installs >a package on a hard disk. Let's say this package needs an Assign and a >path xxx add added to the startup-sequence, and the package is being >installed in DH1:. I think that the ultimate solution is to provide a interactive, bare-CLI execute script for the installation. Obviously, if the user has more sophisticated needs, they will have to modify the script for their own installation. However, between querying the user and making a few "rational" defaults, it shouldn't be hard to make a general enough installation script that even the most naive user can install the product on a hard-disk and have it WORK THE FIRST TIME! >[lots of good comments deleted] >So what's the answer? > >1. make sure commercial applications never need boot time configurations >such as ASSIGN or PATH? Make damn sure that ALL the programs needed to install the application are on that disk, and reference them as such. IE, don't go looking for PATH in the C: directory already there, use MyDISK:c/path to add the path to the device... Ad nausem with other commands. Granted it may be a bit slower, but it will WORK! >2. chase startup script chains looking for something typical and adding >in the commands automatically after ultra-warning operator? Warn user and then add (before any endcli command) an "execute s:myproduct" command to the last thing in the s:startup-sequence >3. warn user that the Amiga is inherently unfriendly to novice Hard Disk >users who are unfamiliar with the CLI, so he'd better go out and buy a >good book, or drag his system back into his dealer and let *him* install >it? Bad solutions, at least in my experience. Telling Jerry Pournelle to get the help of a dealer/guru is one thing, but aver Joe User won't be as lucky to be graced with the presence of Joanne Dow or another Commodore luminary... Some dealers are willing to help users install, and this is a *Good Thing*. Others barely seem capable of ordering the correct products for you, much less installing a product. (I have a friend with an atrocious (sp) WB1.3 setup -- the first one that the dealer had installed. Almost makes me cry...) >4. ???? (god I hope there's a 4. and maybe a 5. and 6.) I'm all typed out. Somebody else can answer these questions... >Keith Doyle gryphon!keithd -- ================================================================== == Kurt J. Lidl (smaug@eneevax.umd.edu) (301)454-3184 == == UUCP: [seismo,allegra]!umcp-cs!eneevax!smaug == ========"It's after 3am, no point in going to sleep now..."=======
dillon@CLOUD9.BERKELEY.EDU (Matt Dillon) (12/10/88)
:Now, arguments that anyone who has a hard disk should be able to add :ASSIGN commands to his own startup-script are nice, but far from :reality. I talked to a user a couple of days ago, who had a brand :new Amiga 2000 with HD which was completely installed and setup by his :local dealer. He was trying to install packages onto his hard disk simply :by dragging the visible icons onto the hard disk. He couldn't drag the :entire disk icon onto the hard disk (as you would expect ala-MacIntosh) :because you get a "Can't move icon out of window" error or something like :that. We apparently don't have a "move entire disk into a drawer on the :HD" capability without the CLI. While some packages perhaps can be :installed simply by draggin the visible icons, certainly not all can. Just a few of the workbench bugs which have to be fixed (will be 1.4 I hope). :So, I proceeded to spend about 1-1/2 hours with this guy explaining to :him how to use the CLI for the first time (CLI, what's that?) and :over-the-phone following his startup-sequence maze to a convienient :place to add the useful ASSIGNS, how to use ED etc. Fortunately he :had a GVP harddisk with which I had some familiarity. After it was :all over, he said "well that isn't all that hard". And he's right, :it isn't all that hard, but it would have been if he had tried to :figure it out for himself. : :So what's the answer? : :1. make sure commercial applications never need boot time configurations :such as ASSIGN or PATH? Many commercial applications must reference modules within themselves, dictionaries, help files, control files, etc..., and the absolute best way to do this is by assuming they exist in a custom assign'd place. For example, the company Foo might have a dictionary program which assumes the dictionary can be found in foodict: Thus, the user must add 'assign foodict: whereever' in his startup script. How the !@#$ else do you do it? Assume the dictionary is in S: or C:?? lovely. Why don't we just assume the dictionary is in DF0:? Think this:... It is nice to think that installation of software should be as easy as moving an icon, but the reality is quite different for many applications. Without Assign's, most large commercial programs have little Flexibility. It should be obvious from past experience, when programs made ridiculous assumptions like there had to be a floppy in DF0:, or the support files for the program were in the current directory or something like that. Yick. >2. chase startup script chains looking for something typical and adding >in the commands automatically after ultra-warning operator? Not possible. For example, my s:startup-sequence on my HD executes another startup-sequence conditionaly and then starts a shell which does most of the system init. It is not possible to write an automated program that is able to trace that, and just adding the assign to s:startup-sequence would not work in my (and many other) cases because not only has DHB:C not been added to the path yet, but my four other partitions haven't even been mounted yet! Even a 'stupid-user-intallation' program would have trouble for the same reasons... that there is no way to tell how that user's startup-sequence is setup, it would depend on who he bought the drive from. And before you say it, tracing out the commands a startup-sequence does is out of the question too for obvious reasons (if you just think a little). A company might include such an installation program anyway, but would still have to accompany it with manual installation instructions. >3. warn user that the Amiga is inherently unfriendly to novice Hard Disk >users who are unfamiliar with the CLI, so he'd better go out and buy a >good book, or drag his system back into his dealer and let *him* install >it? > >4. ???? (god I hope there's a 4. and maybe a 5. and 6.) > >Keith Doyle >gryphon!keithd The reality is that the user must be smart enough to follow instructions. Of course, most installation instruction manuals are really bad and impossible to follow. The solution is to fix the manual, and the fault is that of the company. But then again, the user had better not be too stupid or he'll never understand the product. Apple had the right idea with their friendly user interface, but found out all too quickly that it wasn't so friendly due to the unavoidable complexity of the applications run on it. -Matt
pds@quintus.uucp (Peter Schachte) (12/10/88)
In article <9407@gryphon.COM> keithd@gryphon.COM (Keith Doyle) wonders
how to make installation easier. In particular, how can an automated
procedure add assignments to your startup-sequence.
Here's an approach that requires Commodore to do something, but
something VERY simple. Change the standard startup-sequence to include
something like:
EXECUTE S:ASSIGNS
somewhere early on, and move all the standard assigns to S:ASSIGNS.
Then installation scripts can just append to S:ASSIGNS. Of course,
experienced startup-sequence hackers will move things all around, and
may even delete the EXECUTE S:ASSIGNS line, but they can do the
installations themselves.
-Peter Schachte
pds@quintus.uucp
..!sun!quintus!pdsjesup@cbmvax.UUCP (Randell Jesup) (12/10/88)
In article <8812091849.AA02843@cloud9.berkeley.edu> dillon@CLOUD9.BERKELEY.EDU (Matt Dillon) writes: >:1. make sure commercial applications never need boot time configurations >:such as ASSIGN or PATH? > > Many commercial applications must reference modules within >themselves, dictionaries, help files, control files, etc..., and >the absolute best way to do this is by assuming they exist in a >custom assign'd place. For example, the company Foo might have a >dictionary program which assumes the dictionary can be found in >foodict: 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). > Without Assign's, most large commercial programs have little >Flexibility. It should be obvious from past experience, when programs >made ridiculous assumptions like there had to be a floppy in DF0:, or >the support files for the program were in the current directory or >something like that. Yick. > Even a 'stupid-user-intallation' program would have trouble >for the same reasons... that there is no way to tell how that user's >startup-sequence is setup, it would depend on who he bought the drive >from. And before you say it, tracing out the commands a startup-sequence >does is out of the question too for obvious reasons (if you just think a >little). However, if there were a standard file that contained nothing but assigns, then installation scripts could add assigns to it safely. -- You've heard of CATS? Well, I'm a member of DOGS: Developers Of Great Software. Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
peter@sugar.uu.net (Peter da Silva) (12/10/88)
In article <9407@gryphon.COM>, keithd@gryphon.COM (Keith Doyle) writes: > 1. make sure commercial applications never need boot time configurations > such as ASSIGN or PATH? This is a good one. It's easy enough to see if an assign hasn't been made yet, and to make it. Dissect my "mounted" program to see how to scan through the mountlist. Looking for assigns is as easy as looking for volumes. > 2. chase startup script chains looking for something typical and adding > in the commands automatically after ultra-warning operator? Nope. > 3. warn user that the Amiga is inherently unfriendly to novice Hard Disk > users who are unfamiliar with the CLI, so he'd better go out and buy a > good book, or drag his system back into his dealer and let *him* install > it? Nope. > 4. ???? (god I hope there's a 4. and maybe a 5. and 6.) The expansion drawer is a good place to do some of this stuff. A little complex, since there's hardly any system when this is run. 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. This should be entirely safe. The last question can be "Are you booting from a floppy and copying everything into RAM?"... if the answer is "yes", you then ask them to insert their boot floppy in df0: and copy the configuration file to df0:s. Simple. Easy. Always safe. Many programs do this already. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: My typos are my own damn busines#!rne
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/10/88)
:>2. chase startup script chains looking for something typical and adding :>in the commands automatically after ultra-warning operator? : I write: : Not possible. For example, my s:startup-sequence on my HD :executes another startup-sequence conditionaly and then starts a shell :which does most of the system init. It is not possible to write an Well, I should amend that. If there were yet another standard script file for assigns then it would be extremely easy to write an install program for it. So if all the companies got together, or commodore specified a specific file name (s:startup-assigns ?) that will be executed and that contained *nothing* except assign commands, then the user need only stick an 'execute s:startup-assigns' in the appropriate place in his startup sequence. Commercial software install programs would then always add their assigns only to this file, and can also check to make sure they aren't adding it twice (i.e. you install the program several times in frustration). -Matt
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (12/10/88)
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.BITNETlphillips@lpami.van-bc.UUCP (Larry Phillips) (12/12/88)
> Here's an approach that requires Commodore to do something, but > something VERY simple. Change the standard startup-sequence to include > something like: > > EXECUTE S:ASSIGNS Not a bad idea at all. As long as we're 'getting Commodore to do something', why not have the ASSIGN command accept a file with pairs of arguments indicating all the assigns to be made? That way, one ASSIGN is executed for all the assigns. Lots quicker. -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------+ | // Larry Phillips | | \X/ lpami.wimsey.bc.ca!lphillips or van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
papa@pollux.usc.edu (Marco Papa) (12/12/88)
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. [very interesting stuff deleted] |So, I proceeded to spend about 1-1/2 hours with this guy explaining to |him how to use the CLI for the first time (CLI, what's that?) and |over-the-phone following his startup-sequence maze to a convienient |place to add the useful ASSIGNS, how to use ED etc. Boy, how much do I relate to that, Keith :-) |So what's the answer? | |1. make sure commercial applications never need boot time configurations |such as ASSIGN or PATH? Well, A-Talk III would like to have: Assign AT3: <hddisk:drawer> path AT3: add BUT our installation program puts the executable and related directories (for scripts and settings) in a fixed place relative to the directory in which the A-Talk III executable is copied. When A-Talk III comes up first it looks for settings/script files in currentdir/Settings and currentdir/Scripts; if it doesn't find anything then it looks into AT3:Settings and AT3:Scripts. This works just fine for the Workbench user. For the CLI user, we ASSUME he knows about PATH and ASSIGN, and remind him during hd installation to add HIMSELF the appropriate commands to the Startup-Sequence. We also added to the manual the ED commands needed to do just that. So far it has worked nicely. |2. chase startup script chains looking for something typical and adding |in the commands automatically after ultra-warning operator? I have seen it done to my AUTOEXEC.BAT in PC-DOG and I HATED it so much, I'll never consider doing it on the Amiga. Beside you need a CLI "expert system" for doing it "right" :-) |3. warn user that the Amiga is inherently unfriendly to novice Hard Disk |users who are unfamiliar with the CLI, so he'd better go out and buy a |good book, or drag his system back into his dealer and let *him* install |it? Well, that's not just a problem for the Amiga. What we need is something like Peter Norton's "Inside to the IBM PC". So far most Amiga books for novices have been just dreadful. |4. ???? (god I hope there's a 4. and maybe a 5. and 6.) Really? :-) -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
papa@pollux.usc.edu (Marco Papa) (12/13/88)
In article <5486@cbmvax.UUCP| jesup@cbmvax.UUCP (Randell Jesup) writes: |In article <8812091849.AA02843@cloud9.berkeley.edu| dillon@CLOUD9.BERKELEY.EDU (Matt Dillon) writes: ||:1. make sure commercial applications never need boot time configurations ||:such as ASSIGN or PATH? | | 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). As I said I concur with this. I used it in A-Talk III, and it does the job. The trick is to just write your installation script and use Xicon to execute it. Ask one (1) question to the user: On which disk (or volume) do you want to install package XXX? Then copy the XXX executable and copy subdirectories/drawers RELATIVE to the same location on the disk. Then use MyOpen() as Randell describes above and the end result is that the "dumb hd user" has to click on 1 icon, and answer 1 question to get package XXX properly usable from a hard disk. Is that easy enough? -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
cg@myrias.UUCP (Chris Gray) (12/13/88)
In article <8812100429.AA08669@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > Well, I should amend that. If there were yet another standard >script file for assigns then it would be extremely easy to write an >install program for it. So if all the companies got together, or >commodore specified a specific file name (s:startup-assigns ?) that will >be executed and that contained *nothing* except assign commands, then >the user need only stick an 'execute s:startup-assigns' in the >appropriate place in his startup sequence. > -Matt YES! Excellent idea! Unless problems crop up with this method, I would like to see something like this recommended by CBM as a standard. Perhaps a mention in the next AmigaMail? The sooner something like this is done the better - the stories of lost sales because of difficult installation are all too likely to be true. Since V1.4 is about Workbench, perhaps the standard could be set up there - perhaps by including a 's:startup-assigns' in the standard WorkBench startup. f i l l e r -- Chris Gray Myrias Research, Edmonton +1 403 428 1616 {uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cg
cmcmanis%pepper@Sun.COM (Chuck McManis) (12/13/88)
About program installation ...
My startup sequence has a callout that runs the execute file
called "utility-setup". This consists of entries that look like
; PRODUCT : <name>
;
; <comments>
;
if EXISTS <install_dir>
echo "Setting up <Application>"
ASSIGN ASSIGN1: <install_dir>
...
Path <executable_dir> Add
Endif
In the case of Lattice C this looks something like :
; PRODUCT : LATTICE C
;
; Set up for Lattice C 5.0
;
if EXISTS sys:lc
echo "Setting up Lattice C 5.0"
Assign LC: sys:lc/c
Assign INCLUDE: SYS:lc/include
Assign LIB: SYS:lc/lib
Assign QUAD: RAM:
path LC: add
Endif
Now to install something into the startup sequence I do two things,
one remove the old product definition. This can be accomplished with
an edit script that searches for the PRODUCT line and deletes lines
from there to the first "Endif" it encounters that starts in column one.
Then diddle around with the product definition stuff and assignments
and create a new temporary file PRODUCT.e and then use the AmigaDOS
Join command to tack this onto the end of my "utility-setup" file.
Next time I reboot it does the assignments.
As far as convention goes, I execute this just before I execute the
loadwb.
Future Directions ...
Of course as anyone will tell you I have a zillion utilities and applications
that are on my system. And yet, everyone of them only requires that there
be "assignments" and path additions in the setup mode. (With the exception
of Manx which uses 'set'). This suggests to me that a utility "Mount"
command may be the ticket to save a lot of disk grinding on assigns
and such like. Using a format that is something like a cross between
a mountlist and a makefile, possibly like this:
#
# Comment and delimiter of entry are the "#" marks.
#
Product
Lattice C 5.0
Installed
sys:lc
Assigns
LC: $(INSTALL)/c
INLCUDE: $(INSTALL)/include
LIB: $(INSTALL)/lib
QUAD: ram:
Addpath
LC:
Environment
EditorFlags "a,b" ; An example only not needed for Lattice
# <- end of entry mark
This utility would read this entry and "setup" the application for you
with only "two" disk reads, one for the entry and one for the initial
setup utility loading.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.mroth@ihlpf.ATT.COM (Roth) (12/13/88)
In article <8812100429.AA08669@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > >:>2. chase startup script chains looking for something typical and adding >:>in the commands automatically after ultra-warning operator? >: >I write: >: Not possible. For example, my s:startup-sequence on my HD >:executes another startup-sequence conditionaly and then starts a shell >:which does most of the system init. It is not possible to write an > > Well, I should amend that. If there were yet another standard >script file for assigns then it would be extremely easy to write an >install program for it. So if all the companies got together, or >commodore specified a specific file name (s:startup-assigns ?) that will >be executed and that contained *nothing* except assign commands, then >the user need only stick an 'execute s:startup-assigns' in the >appropriate place in his startup sequence. > > -Matt There are problems with the approach of a special 'ASSIGNS' file upon bootup. When does the system perform the assigns? If it is done before the startup-sequence then assigns will fail to devices which have not been mounted yet. If it is done after, then no assigns will be done if the user sets up a turnkey system (less of a problem). My harddisk has four partitions. I do assigns to directories in the different partitions. I could have a startup-sequence which queries which partitions I wish to mount at startup time (Since mounting devices eats up valuable memory). These are just problems I have thought of off the top of my head. There may well be more. For the novice user they may not exist at all. For the semi-novice user, they could cause much grief. I think the solution is to have a special 'config' file for packages which could exist in the S: directory or a new CONFIG: directory. That way each package can do what is needed when it is fired up, including things other than just assigns. This would be much more flexible for both the package developer and the operating system. ------------------------------- Mike Roth - ihnp4!ihlpf!mroth -------------------------------
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/13/88)
I write: :be executed and that contained *nothing* except assign commands, then :the user need only stick an 'execute s:startup-assigns' in the :appropriate place in his startup sequence. : : -Matt :There are problems with the approach of a special 'ASSIGNS' file upon :bootup. When does the system perform the assigns? If it is done before :the startup-sequence then assigns will fail to devices which have not :been mounted yet. If it is done after, then no assigns will be done :if the user sets up a turnkey system (less of a problem). : :My harddisk has four partitions. I do assigns to directories in the :different partitions. I could have a startup-sequence which queries :which partitions I wish to mount at startup time (Since mounting devices :eats up valuable memory). You didn't read the last line! or maybe I didn't say it clearly. The system would not explicitly execute s:startup-assigns .. the user would place 'execute s:startup-assigns' somewhere in his startup sequence. I.E. a one time thing, maybe even a zero time thing if HD distributors stick it in their HD installation packages. I have four major partitions on my HD. Each has a c directory and each of these contains a file init.sh which contains assigns specifically for that partition. I source all four files somewhere in the middle of my shell's .rootlogin. I'm not proposing that you put all your custom assigns in s:startup-assigns, it would just be a place for commercial programs to install themselves. The only other things I can think of that a commercial program might want to 'install' are some enviroment variables. So maybe one should allow SetEnv commands in s:startup-assigns. Even so, that is iffy because some people (like me) will assign ENV: to permanent storage (HD) rather than a RAM: disk. In that case the commercial program would simply set the appropriate variables to their default states. -Matt
keithd@gryphon.COM (Keith Doyle) (12/16/88)
In article <836@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >Here's an approach that requires Commodore to do something, but >something VERY simple. Change the standard startup-sequence to include >something like: > >EXECUTE S:ASSIGNS > >somewhere early on, and move all the standard assigns to S:ASSIGNS. >Then installation scripts can just append to S:ASSIGNS. Of course, >experienced startup-sequence hackers will move things all around, and >may even delete the EXECUTE S:ASSIGNS line, but they can do the >installations themselves. Something like this would probably work, but agreed, Commodore should decide this (or something) is the standard approach and publicize it to the developers. We might consider wording the file name a little differently, though it's not a big deal, assigns are not all that might go into it, certainly PATH commands might as well. We could call it APPLICATIONS or something indicating it is for application specific boot commands. A developer could decide to take this approach without Commodore support by simply checking for the existance of such a file, and if not finding it, creating one and informing the operator he must add an EXECUTE S:___ to his current startup chain in an appropriate place, as a stopgap measure. However, you wouldn't want every developer to decide to do this and do it slightly differently where they would become incompatible with each other. You don't want to end up with a S:AEGIS_STARTUP and a S:EA_STARTUP, and a S:BROWNWAUGH_STARTUP etc.. ad nauseum. Keith Doyle keithd@gryphon.COM gryphon!keithd gryphon!keithd@elroy.jpl.nasa.gov
keithd@gryphon.COM (Keith Doyle) (12/16/88)
Matt apparently has come to some of the same conclusions I have about this issue, 1. Assigns are great and useful and commercial applications should be able to use them. and 2. Auto-edit of the current startup chain is about impossible. However, I don't like Matt's idea of simply saying "the user must be able to follow instructions" when those instructions require he learn the CLI, ED, and how to follow a startup chain himself so he can determine where he should add the ASSIGN and PATH commands for a commercial application that requires them. Keith Doyle keithd@gryphon.COM gryphon!keithd gryphon!keithd@elroy.jpl.nasa.gov
charles@hpcvca.HP.COM (Charles Brown) (12/20/88)
> You don't want to end up with a S:AEGIS_STARTUP and a > S:EA_STARTUP, and a S:BROWNWAUGH_STARTUP etc.. ad nauseum. > Keith Doyle Actually I do want to end up with that. It makes installation of the tool simple. Almost as important, it makes clean removal of the tool just as simple. -- Charles "Modularity! That's the ticket!" Brown
keithd@gryphon.COM (Keith Doyle) (12/23/88)
In article <1410010@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >> You don't want to end up with a S:AEGIS_STARTUP and a >> S:EA_STARTUP, and a S:BROWNWAUGH_STARTUP etc.. ad nauseum. >> Keith Doyle >Actually I do want to end up with that. It makes installation >of the tool simple. Almost as important, it makes clean removal of >the tool just as simple. Except that clean removal is cleaner if all the applications keep their specific commands in a common applications execute file, as they can have no fear of removing commands that were inserted by them, assuming we can all agree on a format. Your approach requires a person's startup-sequence chain to somewhere be modified *specifically for each manufacturer* in addition to adding the execute files for each: if exists s:ea_startup execute s:ea_startup endif if exists s:aegis_startup execute s:aegis_startup endif if exists s:newtek_startup execute s:newtek_startup endif etc. etc. etc. Wouldn't it be better to have: execute s:appspecifics in your startup chain, and then appspecifics would look something like: ;# Aegis Videoscape 3D specifics assign vid3d: dh2:viddir path dh2:viddir add ;# NewTek Digi-View specifics assign dview: dh2:dviewdir path dh2:dviewdir add ;# Byte by Byte Animate 4D specifics assign a4d: dh3:animate path dh3:animate etc. etc. And then make sure each program as an install/remove icon that will automatically insert and delete their appropriate sections? With a system like this, a new companies HD install program can just add their stuff to the s:appspecifics file without any operator intervention. Your approach requires either the install program signal the operator he must add the "if exists" junk above, or that some sort of execute script is done to recognize files with a certain naming convention in s: as being app specific executes, (making sure it ignores *.bak, *.info, and a few other things) as well as doing considerably more disk thrashing on the way up. Not to mention difficult to explain to the novice where and why he needs to type it in himself the first time because the existing systems don't already contain this smart code in their startup-chains Granted, applications need re-install (move to somewhere else) and remove options as well as install, all of which operate on the s:appspecifics file. Keith Doyle keithd@gryphon.COM gryphon!keithd gryphon!keithd@elroy.jpl.nasa.gov
dfisk@hawk.ulowell.edu (David Fisk) (12/23/88)
As a hard disk user, I've been following this discussion about ways to do software installations with Assign batch files. Personally I don't like having to have a lot of assigns that have to be made for all of my programs to work. What I would like to see is for programs to look for a configuration file in a certain directory (either current or a regular assign such as s:) and use that instead of Assigns. This is currently done by one shareware program I have seen, Access!, which makes things very neat and tidy. An installation program/script would copy the program files from the distribution media, to a user specified directory and then either run the program and have it prompt the user for configuration info, or create the config file itself. I think that this is a lot nicer than having someones script/program editing my startup-sequence. Any Comments? Dave... --------------------------------------------------------------------------- | dfisk@hawk.ulowell.edu (David Fisk) | | | University of Lowell | still looking for a good quote...| | Computer Science Dept. Student | | --------------------------------------------------------------------------- --------------------------------------------------------------------------- | dfisk@hawk.ulowell.edu (David Fisk) | | | University of Lowell | still looking for a good quote...| | Computer Science Dept. Student | |
peter@sugar.uu.net (Peter da Silva) (12/23/88)
In article <9910@gryphon.COM>, keithd@gryphon.COM (Keith Doyle) writes: > Your approach requires a person's startup-sequence chain to somewhere > be modified *specifically for each manufacturer* in addition to adding > the execute files for each: > if exists s:ea_startup > execute s:ea_startup > endif .. You don't need to be so baroque. Try this: list >ram:manufacturers_startup s:#?_startup lformat "execute %s%s" execute ram:manufacturers_startup Or just have each program, when it's run for the first time each session, run a quick little CLI session: if(access("ram:my-startup-sequence") == FAIL) { copyfile("s:my-startup-sequence", "ram:my-startup-sequence"); Execute( "Newcli \"CON:0/0/640/200/Installing Me\" from ram:my-startup-sequence", NilFH, NilFH); } Or even have it use s:my-init-file directly, like Browser, DTerm, WKeys, and even the new Amiga Shell do. -- Peter "Have you hugged your wolf today" da Silva `-_-' peter@sugar.uu.net
keithd@gryphon.COM (Keith Doyle) (12/24/88)
In article <10866@swan.ulowell.edu> dfisk@hawk.ulowell.edu (David Fisk) writes: >As a hard disk user, I've been following this discussion about ways to >do software installations with Assign batch files. Personally I don't >like having to have a lot of assigns that have to be made for all of >my programs to work. What I would like to see is for programs to look >for a configuration file in a certain directory (either current or a >regular assign such as s:) and use that instead of Assigns. This is >currently done by one shareware program I have seen, Access!, which makes >things very neat and tidy. An installation program/script would copy >the program files from the distribution media, to a user specified >directory and then either run the program and have it prompt the user >for configuration info, or create the config file itself. I think that >this is a lot nicer than having someones script/program editing my >startup-sequence. > >Any Comments? Yes. You can't use the current directory for anything because programs run under the Execute() call don't know what their current directory is. You MUST have a full pathname to such files. Let's pose a scenario: 1. program A runs. 2. program A wants to cause program B to run. Program A must be able to find program B, and if program A was run from an Execute(), it can't reference it without a complete path name if A was run from an icon. Program A could concievably read file S:PROGA_CONFIG and find the supposed current path of program B, but it takes extra disk activity at run time over the assign approach. Program A could read all of PROGA_CONFIG upon initial invocation so that the information is around all the time so that reading of this file is not done every time program B is invoked. Now. Program B wants to use data files that are in the same directory as program B. Program B also has to read a config file to find out what it's current directory is if it perhaps can't assume that an assign is available. We are using the config file as a workaround for the lack of an assign, a facility which we DO have, so why not use it? Program A wants to accept a filename typed in by the user. Program A must then parse the file name to determine if it is a complete or partial path, if not complete, must prepend the config file's current directory information as the operator is then presumed to be specifying the file as relative to program A's directory. But what if program was run via PATH ADD from another directory, and the current directory there is not the same as is in the config file? This one's a mess. If the user knew that program A's directory was FOO:, assigned at startup, he could specify FOO:filename when he knows he want's it in program A's directory and "filename" by itself when he is in the directory he wants and the program has not been Execute()'d from another icon-invoked program. Ultimately, the best way to fix all these problems is to fix Execute() to correctly inherit the path of the parent process even when the parent was invoked from an icon. In that instance, 99 percent of the reasons one needs startup assigns go away. Startup PATH ADDs may still be necessary however, and there's no amount of config-file reading an application will be able to do to cure it if the PATH ADD is required to get to the application in the first place. Keith Doyle keithd@gryphon.COM gryphon!keithd gryphon!keithd@elroy.jpl.nasa.gov
charles@hpcvca.HP.COM (Charles Brown) (12/24/88)
> Except that clean removal is cleaner if all the applications keep their > specific commands in a common applications execute file, as they can > have no fear of removing commands that were inserted by them, assuming > we can all agree on a format. Sounds good. (see below) > Wouldn't it be better to have: > execute s:appspecifics > in your startup chain, and then appspecifics would look something like: > ;# Aegis Videoscape 3D specifics > assign vid3d: dh2:viddir > path dh2:viddir add > ;# NewTek Digi-View specifics > assign dview: dh2:dviewdir > path dh2:dviewdir add > etc. Except that I don't believe manufacturers would make it as clean as you show here. Why should they bother putting in the header line? ;# NewTek Digi-View specifics Financially it only helps them to make it easy to install the program. It does not help them at all to make it easy for me to remove their program from my system. If we combine both proposals we make the s:appspecifics file look like: execute s:ea_startup execute s:aegis_startup execute s:newtek_startup I like this best of all. I figure that the less editing the install does to my global files, in this case s:appspecifics, the less chance my system will get destroyed and the better chance I have of restoring it if it is damaged. > And then make sure each program as an install/remove icon that will > automatically insert and delete their appropriate sections? Icon??? I don't DO icons! > Granted, applications need re-install (move to somewhere else) and > remove options as well as install, all of which operate on the > s:appspecifics file. > --Keith Doyle Now this sounds VERY dangerous with your proposal. What are the chances that the string search for ea specific lines will accidentally find some aegis lines as well? When we combine both proposals this becomes a simple matter of editing s:ea_startup, which I am much more likely to trust the application to do. After installation, the s:appspecifics file does not need to be touched at all. -- Charles Brown charles%hpcvca@hplabs.hp.com Not representing my employer.
peter@sugar.uu.net (Peter da Silva) (12/24/88)
In article <9946@gryphon.COM>, keithd@gryphon.COM (Keith Doyle) writes: > Now. Program B wants to use data files that are in the same directory > as program B. Program B also has to read a config file to find out what > it's current directory is if it perhaps can't assume that an assign is > available. We are using the config file as a workaround for the lack > of an assign, a facility which we DO have, so why not use it? But this isn't the same thing as startup assigns, which hang around all the time. There's nothing wrong with having PROGB (or PROGA, for that matter) looking for an assign (set pr_WindowPtr to -1, then tru to Lock() the assigned name) and only going to S:PROGB.CONFIG if it needs to. Also, there's nothing very large in S:. If the disk activity bothers you copy it to RAM:. > Ultimately, the best way to fix all these problems is to fix Execute() to > correctly inherit the path of the parent process even when the parent was > invoked from an icon. This is the bottom line. Execute() has serious brain damage, and I hope it's fixed in 1.4. However, there is a workaround. Have PROGB called in a workbench environment (CreateProc, then pass a startup message). PROGB can get its current directory from WBStartup->sm_ArgList[0].wa_Lock. The code to do this in the general case is available from the binary groups. It's completely clean, there's no fudges and kludges needed to do it, and you get absolute verific- ation that the program completed (your startup message is returned). If you like I will repost my example program. > In that instance, 99 percent of the reasons one > needs startup assigns go away. Startup PATH ADDs may still be necessary > however, and there's no amount of config-file reading an application will > be able to do to cure it if the PATH ADD is required to get to the application > in the first place. PATHs are irelevant to the Workbench, and presumably CLI users will be sophisticated enough to know how to do these themselves. -- Peter "Have you hugged your wolf today" da Silva `-_-' peter@sugar.uu.net
csc21824@unsvax.UUCP (Jay) (12/25/88)
> Your approach requires a person's startup-sequence chain to somewhere > be modified *specifically for each manufacturer* in addition to adding > the execute files for each: > > if exists s:ea_startup > execute s:ea_startup > endif > if exists s:aegis_startup > execute s:aegis_startup > endif > if exists s:newtek_startup > execute s:newtek_startup > endif > etc. Nope, just keep them all in the same directory, then do this list >ram:startfiles S:configscripts LFORMAT="Execute %S%S" execute ram:startfiles and all those scripts get executed. This assumes WB1.3, but I think that will be a safe assumption in the future. --------------------------------------------------------------------- This space for Rent Eric J. Schwertfeger CIS [72657,1166] or csc21824%unsvax.uns.edu Disclaimer:These are just the mad ramblings of a man forced to use vi once too often, and as such, should be ignored.
elg@killer.DALLAS.TX.US (Eric Green) (12/25/88)
in article <9910@gryphon.COM>, keithd@gryphon.COM (Keith Doyle) says: > In article <1410010@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >>> You don't want to end up with a S:AEGIS_STARTUP and a >>> S:EA_STARTUP, and a S:BROWNWAUGH_STARTUP etc.. ad nauseum. > Except that clean removal is cleaner if all the applications keep their > specific commands in a common applications execute file, as they can > have no fear of removing commands that were inserted by them, assuming > we can all agree on a format. > > Your approach requires a person's startup-sequence chain to somewhere > be modified *specifically for each manufacturer* in addition to adding > the execute files for each: > > if exists s:ea_startup > execute s:ea_startup > endif Foo. Bogus. Simply have a file: s:bbs_devices which contains the lines: upload_dir=DH1:uploads bulletin_dir=DH0:bulletins etc. And at startup have your program grok that file i.e. DON'T use the "assign" convention. Then have a subroutine OpenPath in your program which: MyFile *OpenPath(pathname,filename,mode) char *pathname,filename; int mode; { ... strmov(buffer,pathname); .. strcat(buffer,filename); ... Open (...); } and voila. You can have an "install" program for your novice user which tells the user what each one of these devices does, asks where he/she wants it to be located, if it doesn't exist ask him if he wants to create it, etc.... all very friendly, very self-explanatory, doesn't require the user to even KNOW what a CLI is. -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 Netter A: In Hell they run VMS. Netter B: No. In Hell, they run MS-DOS. And you only get 256k.
keithd@gryphon.COM (Keith Doyle) (12/27/88)
In article <1410011@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >Except that I don't believe manufacturers would make it as clean as >you show here. Why should they bother putting in the header line? So they can find it again if you run re-install to move the application elsewhere. >If we combine both proposals we make the s:appspecifics file look like: > execute s:ea_startup > execute s:aegis_startup > execute s:newtek_startup >I like this best of all. Except for the thrashing the system goes through doing all those extra executes. This is also my complaint with the script programs that execute everything that ends in _startup. >I figure that the less editing the install >does to my global files, in this case s:appspecifics, the less chance >my system will get destroyed and the better chance I have of restoring >it if it is damaged. Perhaps. Then again, the install program could add what it needs in the S:appspecifics file, and a copy of it in a newtek_startup file that never gets executed but is there so you can figure out what it did if the file gets muched by some other program. There you get both better boot-time performance, and keep track of what was done to the file by who if it is ever damaged. >Icon??? I don't DO icons! Well, that's the whole point. If all the users could figure out how to edit their startup-sequence, this conversation would be moot. I've run into quite a few hard-disk users who don't fit that category though. >Now this sounds VERY dangerous with your proposal. What are the >chances that the string search for ea specific lines will accidentally >find some aegis lines as well? That's why you use the manufacturers name in a comment preceding the actual commands, silly. Assuming we could all ever agree on a common format, this technique would work fine. >When we combine both proposals this >becomes a simple matter of editing s:ea_startup, which I am much more >likely to trust the application to do. After installation, the >s:appspecifics file does not need to be touched at all. True, at the cost of a longer boot sequence. I'd be willing to buy off on either scheme, provided it was established as a standard and published as such by C=. In fact, some example boilerplate install/re-install/remove code with standardized icons would be useful as well, C= needs to establish similar procedures for installing their own software. My guess is whoever implements such a scheme first and submits it to C= for consideration as a standard will likely decide for us de-facto. However, there may be other sticky issues. Certainly there would be some "hands off" commands perhaps, using STACK could mess up another program that needed a larger stack, unless you did some shell fiddling that would only make the stack larger, never smaller. And while STACK is basically only used when CLI-invoking programs, it is still true that not all beginning CLI dabblers yet have the expertise to edit the startup-sequence to add appropriate stack commands. Concievably there may be some application that contains it's own device drivers or handlers, and requires insertion of "mount" commands, etc., and who knows what else. All I'd like to see is a standard mechanism whereby every manufacturer doesn't end up inventing his own scheme such that it continues to be a total confusing mess for the novice every time he needs to install something new on his hard disk, as it is to varying degrees now. Keith Doyle keithd@gryphon.COM gryphon!keithd gryphon!keithd@elroy.jpl.nasa.gov
keithd@gryphon.COM (Keith Doyle) (12/27/88)
In article <3151@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: .This is the bottom line. Execute() has serious brain damage, and I hope it's .fixed in 1.4. However, there is a workaround. Have PROGB called in a workbench >environment (CreateProc, then pass a startup message). PROGB can get its .current directory from WBStartup->sm_ArgList[0].wa_Lock. The code to do this .in the general case is available from the binary groups. It's completely clean, .there's no fudges and kludges needed to do it, and you get absolute verific- .ation that the program completed (your startup message is returned). If you .like I will repost my example program. This looks like it could be a partial solution. Programs run by IconX probably lose it, as IconX won't pass them startup messages. >PATHs are irelevant to the Workbench, and presumably CLI users will be >sophisticated enough to know how to do these themselves. Don't count on it. Keith Doyle keithd@gryphon.COM gryphon!keithd gryphon!keithd@elroy.jpl.nasa.gov
keithd@gryphon.COM (Keith Doyle) (12/27/88)
In article <6546@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: >Foo. Bogus. Simply have a file: > >s:bbs_devices > >which contains the lines: > >upload_dir=DH1:uploads >bulletin_dir=DH0:bulletins >etc. > >And at startup have your program grok that file i.e. DON'T use the >"assign" convention. Except that your example must first check "filename" to see if it is a full pathname, instead of a relative pathname, and only prepend the current directory if it is a relative pathname. Agreed, this technique will work, though assigns may also be useful in the process, and startup script mods are still needed for PATH ADD commands and any other application related boot requirements, even if you eliminate any need for ASSIGNs. I got it! Let's just put everything in one big giant C: directory then we won't have any of these problems :-) Keith Doyle keithd@gryphon.COM gryphon!keithd gryphon!keithd@elroy.jpl.nasa.gov
peter@sugar.uu.net (Peter da Silva) (12/27/88)
In article <10023@gryphon.COM>, keithd@gryphon.COM (Keith Doyle) writes: > Agreed, this > technique will work, though assigns may also be useful in the process, > and startup script mods are still needed for PATH ADD commands Any program that depends on PATH ADD is already hosed for workbench users. > and any > other application related boot requirements, even if you eliminate any > need for ASSIGNs. About all I can think of here is loading device drivers and the like. I'd rather solve this by adding "Assign()" and "Mount()" to dos.library. I'm still amazed and disturbed that they're not in there already. -- Peter "Have you hugged your wolf today" da Silva `-_-' peter@sugar.uu.net
peter@sugar.uu.net (Peter da Silva) (12/27/88)
[ I said, make your programs workbench programs ] In article <10022@gryphon.COM>, keithd@gryphon.COM (Keith Doyle) writes: > This looks like it could be a partial solution. Programs run by IconX > probably lose it, as IconX won't pass them startup messages. If the program is a workbench program in the first place, what's iconx doing in the loop at all? -- Peter "Have you hugged your wolf today" da Silva `-_-' peter@sugar.uu.net
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (12/28/88)
From article <10023@gryphon.COM>, by keithd@gryphon.COM (Keith Doyle): > I got it! Let's just put everything in one big giant C: directory > then we won't have any of these problems :-) What a great idea! Only instead of calling it C: we could call it /bin. :) --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...codas!usfvax2!jc3b21!fgd3 ...uunet!pdn!jc3b21!fgd3
keithd@gryphon.COM (Keith Doyle) (12/30/88)
In article <3160@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >If the program is a workbench program in the first place, what's iconx doing >in the loop at all? Many programs should work in either mode. Running a program from the CLI can also allow command line parameters that can be useful in a BATCH mode. I can imagine IconX running a batch script that moves all the images in a given directory through PixMate (assuming it had a CLI batch command version, which it may in the future) massaging the images and perhaps passing them to an ANIM compressor afterwards. In addition, a program may want to allow other programs to Execute() it to perform specific functions, again using command line arguments. If a program wants to operate in both the CLI batch and the workbench click-me environments, it might need to be able to figure out: 1) where it is being run from (so it can access user data files kept in the "current" directory), and 2) what directory it is kept in (so it can access program-related files). I've yet to see a method where both 1 & 2 can be achieved whether or not the program is run from the CLI, WorkBench, IconX, Execute() or LoadSeg/CreateProc. #2 can be solved with a boot-Assign. #1 can be solved from CLI, WorkBench and perhaps LoadSeg/CreateProc, but not from IconX or Execute() in all cases. Keith Doyle keithd@gryphon.COM gryphon!keithd gryphon!keithd@elroy.jpl.nasa.gov
peter@sugar.uu.net (Peter da Silva) (12/31/88)
In article <10131@gryphon.COM>, keithd@gryphon.COM (Keith Doyle) writes: > 1) where it is being run from (so it can access user data files kept in > the "current" directory), and > 2) what directory it is kept in (so it can access program-related files). > I've yet to see a method where both 1 & 2 can be achieved whether or > not the program is run from the CLI, WorkBench, IconX, Execute() or > LoadSeg/CreateProc. Easy. Use a PROJECT icon. WBArgs[0] is the program's directory and name, WBArgs[1..n] contain the same info for the data files. Same thing for programs run as Browser tools in Workbench mode. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`