[Coco] Data Modules (From:(Nitr)OS-9 and path numbers in MWC)

[Jeff Teunissen]

Joel Ewy wrote:
> Jeff Teunissen wrote:
>> ..
>> Also, has anyone thought of using a per-user data module for mocking up an
>> environment space? Say, an 8K module named ENV<uid> that would be read from a
>> random or sequential file by the Shell (or LOGIN, on multi-user systems) to
>> hold shell variables like the PATH, Multi-Vue information, the user's "home"
>> directory, etc.
> 
>     I think that's a pretty neat idea, though 8K would probably be way
> more than you'd need for setting a few environment variables.  Of course
> it would take up an 8K block if it was loaded individually.  You could
> always put it in the bootfile, but that might feel a bit too static for
> environment settings.  It could also be merged with frequently used
> commands and loaded just after login.  But then it would probably be
> loading too late to initialize the user's shell.

Putting it in the boot file is pretty silly, since you don't know what users
are going to be logged in. :)

>     It would be nice if this facility were complemented with a nice
> utility to easily create data modules -- "The Modulator".  Simulated
> command lines:
> modulate <env.txt >env.dat
> modulate -d <env.dat >env.txt  [-d = demodulate option]
> modulate -t dd <dd_720k.txt >dd.dd  [-t dd = type, device descriptor]
> modulate <icon.vef >icon.dat

I wasn't actually referring to that kind of module (though I think there is an
implementation of that idea out there -- thought I saw a "datamod" lzh on
RTSI). OS-9 lets you create new modules in memory on the fly -- it's how you
do shared memory between programs.

Anyway, here's a more complete description of the concept:

When a Shell starts, it checks for the existence of an ENV<number> module in
memory, where "number" is the user ID it's running as. If it exists and can be
linked to, nothing further needs to be done as far as setting it up is
concerned. The shell then goes on to set the execution path from the PATH
variable inside the module, the prompt character from the P variable, the
wildcard flag from WILD, and so on.

If there is no ENVnum present, then the shell reads, in order:

its own defaults
/dd/sys/env.file, if present
[user's home dir from /dd/sys/password]/environment, if present

Obviously, there needs to be a lock byte used so that one program can't write
to the environment while another is reading and vice versa. This can be made
transparent to programmers by implementing getenv() and setenv() library calls
in the C library, and providing an equivalent CMDS library module (a la gfx2)
for Basic-09. I believe (but am not sure) that the Basic-09 functionality
would be small enough that "env", "getenv" and "setenv" commands could be
merged into the same module for use by other programs.

There's a gotcha there in that on a multi-user computer, the password file
should not be public-readable because unless you're using a Unix-style
password file (say, with UUCPbb), passwords are stored "in the clear". So in
that case, it's Login (not Shell) that needs to set up the environment. With a
Unix-style password file, this isn't as big of a problem because the password
is stored encrypted (but opens up the possibility that you can copy the
password file to a faster machine and crack the passwords within -- this is
why most *nix machines use two password files).

>     If one were going to go to the trouble to do something like this, it
> would make sense to make gshell get its configuration data from the same
> module.  What other settings could be squeezed into it?  The more use
> you can get out of it, the more it can be justified taking up RAM.

GShell could be another user of this, yes. Indeed, "control" could be extended
to save the current environment to the user's env file.

[snip]

-- 
| Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek at d2dc.net
| GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project     http://www.quakeforge.net/
| Specializing in Debian GNU/Linux           http://www.d2dc.net/~deek/