kriso@NORTHSTAR.DARTMOUTH.EDU (Kris Olander) (11/10/90)
Excerpt from prefs.help
----------------------
Machine-specific preferences
If you need to have preferences that are only active on a specific
machine or sys-type (rt, sun3, vax), you can use the following
preference forms:
?M=machine.name:preference
?S=systype:preference
For example, the following line would cause typescripts you start
while on the machine "pgh.andrew.cmu.edu" to be 600x600 pixels.
?M=pgh.andrew.cmu.edu:typescript.geometry:600x600
------------------------------------------------------------
I know that the ?M directive works since I have the line:
?M=lombard:messages.SurrogateHelpFile: /afs/northstar/user/kriso/todo
in my preferences file and messages does pull up my todo list. However,
when I have the following lines in my preferences file:
?S=sun4_40:ez.BackgroundColor: gold
?S=sun4_40:ez.ForegroundColor: #800000
nothing happens.
We are running AFS 3.0 and so I suspected that maybe /usr/afsws/bin/sys
(Transarc's version of 'sys') was getting executed instead of
/usr/andrew/bin/sys. That's why I chose sun4_40. Both 'sys' commands
return the same string on a Sun4/110.
If I yank out the ?S=sun4_40, ez behaves as expected.
What's going wrong here??????
-KrisCraig_Everhart@TRANSARC.COM (11/10/90)
The directive that's being checked in the version of Andrew that you
have is ?C, not ?S. ?C is mnemonic for the ``cputype'' program that
predated ``sys''. I believe that the next Andrew patch will make this
?S to conform to the documentation, or else will change the
documentation to use ?C to conform to the implementation.
The systype value is the one selected at compile time, generally from
the installed system.h file. It could be overridden (with a compiler
warning) only if that file ({andrew}/overhead/util/lib/config.c)
includes any AFS .h files that override the SYS_NAME or OPSYSNAME
definitions. As it happens, config.c never includes any such files.
The malloc(2) call on line 144 of config.c (storing into ``envar'')
represents a storage leak: the space allocated is never freed or reused.
There should be a simple ``free(envar)'' after the call to
getenv(envar).
Craig