🚀 go-pugleaf

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