🚀 go-pugleaf

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