Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!elroy!gryphon!keithd From: keithd@gryphon.COM (Keith Doyle) Newsgroups: comp.sys.amiga.tech Subject: Re: Amiga Roadblocks to User Friendliness Message-ID: <9652@gryphon.COM> Date: 15 Dec 88 19:22:08 GMT References: <9407@gryphon.COM> <836@quintus.UUCP> Reply-To: keithd@gryphon.COM (Keith Doyle) Organization: Trailing Edge Technology, Redondo Beach, CA Lines: 32 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