bryan@chroma.UUCP (Bryan Ford) (06/13/89)
I just had an "incredibly brilliant" idea (in other words, probably dumb :-), on program start-up. Every computer I've seen, including both micros and mainframes, allows you to have a special command file that is run on startup. On the Amiga this is called the Startup-Sequence. However, there are problems with this method of getting programs started. It's ugly. Unless you're some structured programming fanatic, your Startup-Sequences are not going to look all that beautiful. This is complicated by the fact that that different programs take different startup options in different ways, and it can get real ugly trying to give every program the startup options it needs. It's hard to pass configuration parameters to the program. Usually you end up using SetEnv, a configuration file in S:, or icon ToolTypes. Using SetEnv makes the Startup-Sequence even uglier, a config file in S: makes the S: directory (which, by the way, is *supposed* to be reserved for scripts) uglier, and using ToolTypes require you to keep an icon around (and ugly up your directory), even if you never use WorkBench. It's hard for programs to modify it. I have yet to see a program try to install itself in the user's Startup-Sequence (upon the user requesting it do so, of course). This is because there are so many places the file could be inserted, but only a few of them will work, and those few will be very different for every user. For example, I'm sure some people still use the single 1.2 Startup-Sequence. The program would have to be sure and put itself before the LoadWB and EndCLI, but after everything else. For 1.3, things get more complicated, with two different startups. Sticking it in the Startup-Sequence probably wouldn't be a good idea, because nothing else has been set up yet. It would have to trace the chaining of the scripts into Startup-II, but be able to recognize not to go into a Shell-Startup or something that gets run more than once. So you see the problem. Now for my idea to fix it. Make a "sister" of Mount, which, instead of starting up devices, it starts up resident programs. It could use a "Devs:StartList" or something, which would look very much like a MountList. Then a program called "Start" traverse the StartList, starting all the programs that need to be started. The StartList could have options that go with each program that is started, and Start would pass those options to the program the way it wants them passed (Unix-style switches, AmigaDOS-style arguments, whatever). The advantage to this is that all the options are in the same place, and they are easily edited with a normal text editor (no searching for config files, or having to load WorkBench to change some ToolTypes). Additionally, this would be easy for programs to change. Just append its own setup file to the end, possibly allowing the user to change the startup options from within an installation program. It could even search the list for an entry for itself, in case the user just wants to change some of the options or remove the entry. Ideally, this Start program would be an ARP program, and there would be routines provided in arp.library which could allow programs to add, change, or delete entries in the StartList. Of course this couldn't be used for some parts of the Startup-Sequence like conditionally copying things to RAD: or whatever. However, it would get Startup-Sequences down to size, and it would be great for "normal" users. Note that this is not a standard specification or anything, just an idea to think about and play with. Criticisms welcome, flames ignored. Have fun! Bryan
new@udel.EDU (Darren New) (06/15/89)
My thoughts along those lines were these:
When I first heard that ENV: was assigned to a disk, I thought it
was a great idea. "Now we only have to set the environment once instead
of every time we boot."
Sadly, ENV: is initially assigned to RAM: and it looks like C= is
encouraging people to put non-environmental things out there
such as "list >env:qw{$$} blah blah".
My thought is to make two environmental spaces, one for temporary
stuff and one for actually storing the environment.
In other words, get rid of ">env:{$$}" stuff in scripts and just use
RAM: instead. This way, people could leave ENV: assigned to disk and
just SetEnv once and for all. Also, during installation, software could
write its configuration out to ENV: and not have to worry about putting
a SetEnv into the Startup-Sequence.
It would also be possible to simply COPY SYS:ENV RAM:ENV ALL in order
to initally install the environment, but then a script file or something
would need to be added to copy it back down (or better, two different
SetEnvs. Even better: "SetEnv EDITOR memacs PERMANENT"). These changes
would seem minimal; possibly as little as changing a few script files.
One of the things about Unix that bugs me is the mixing of the
environment and the shell variables -- please don't continue this way.
-- Darrenske@pkmab.se (Kristoffer Eriksson) (06/16/89)
In article <0873.AA0873@chroma> bryan@chroma.UUCP (Bryan Ford) writes: >I just had an "incredibly brilliant" idea (in other words, probably dumb >:-), on program start-up. [...] Make a "sister" of >Mount, which, instead of starting up devices, it starts up resident >programs. It could use a "Devs:StartList" or something, which would look >very much like a MountList. Then a program called "Start" traverse the >StartList, starting all the programs that need to be started. You're not the first one to come up with this idea. In Unix (System V) the program is called "/etc/init" and the file is called "/etc/inittab". -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske
rosenber@ra.abo.fi (Robin Rosenberg INF) (06/18/89)
(LONG) In message 2266 bryan@chroma.UUCP (Bryan Ford) points out some problems with executing programs in the startup-sequence. He points out that adding something to the s-s. is not trivial and thus effectively prevent programs from editing it. I think having to edit the startupsequence just to install a program is a primitive and *BAD* method. Bryan suggests we use a 'mountlist' to install programs. I suggest a 'make-file' instad. Why a makefile then? The problem is that sometimes when you are about to do something you have to do something else first. For example we cannot do anything that involves dh1: before dh1: is mounted. We probably have a lot of thing that is located on dh1:. A makefile takes care of executing ALL commands we need to execute in the correct order since we say that to do this you must have done that first. Another plus with a makefile is that it is easy to edit, both manually and automatically (automagically) > Ideally, this Start program would be an ARP program, and there would be > routines provided in arp.library which could allow programs to add, change, > or delete entries in the StartList. Or in a separate library so the routines don't lie in memory when not needed. We need them only when booting(maybe) and when installing a program. > Of course this couldn't be used for some parts of the Startup-Sequence like > conditionally copying things to RAD: or whatever. However, it would get > Startup-Sequences down to size, and it would be great for "normal" users. A makefile could handle conditions. The unix-like make we use for compiling and linking programs is not the best solution. Rather we should have a tailored format. ISSUE#2: Setting program parameters. Programs that have parameters to change should have an intuition program to to that. The program should be callable from the main preferences program so we can set *all* parameters from essentially the same place. The preferences program could store the parameters in the makefile along with the rules for running the program. SetMap: PAR keymap = s CMD sys:system/setmap <keymap> Comments? > !Have fun! > Bryan Don't worry, be happy! Robin ------ o Robin Rosenberg, cs. Abo Akademi - FINLAND "I don't speak for anyone but me" PS! I tried a lousy idea. I changed my startup-sequence to read lmk -f s:boot-makefile endcli And then a makefile takes care of running all commands in the correct order. Pretty nice.