Subject: Re: /etc/default
To: None <greywolf@tomcat.VAS.viewlogic.com, email@example.com>
From: Captech) <greywolf@tomcat.VAS.viewlogic.com (James Graham>
Date: 07/27/1995 12:52:51
Theo writes (I'm implicitly asking copyright permission here):
#: let's look at a few files:
#: bootparams supports +
#: networks should be deprecated, to use standard hosts lookups
#: hosts has a flag to indicate checking sequence
#: group must support + in sequence for proper ordering
#: passwd must support + in sequence for proper ordering
#: ethers supports +
#: protocols could support +
#: rpc should support +
#: services could support +
Looking back at what I (must have) said (what drugs was I on?), I agree
with the premise of interspersing control information with the data.
It does, indeed, provide more fine control over what goes in the file.
I've been turned into a SunOS junkie in my travels
(I hope to fix this and purify myself :-). bootparams, networks, netmasks,
protocols, rpc, services, ethers and just about every other map under the
sun uses NIS exclusively.
I agree that networks should probably go away except that it's kind of
nice to have hosts and networks separated.
Hosts has a flag? Now I *really* have to look at the hosts stuff...
What kind of flag is present to tell hosts where to look?
Also, token overloading seems to be dropping in, here -- someone else brought
that up. Perhaps we should implement '@' as a network service token, where
one could use @hesiod to tell it to forward to hesiod for the information
service, @dns to forward to dns, @nis to forward to nis (with + remaining
for compatibility), etc. It might (visually) appear to interfere with
the netgroup syntax (has anyone properly implemented this yet?)...
If the netgroup syntax requires +@, it might co-exist peacefully...
Of course, I'm sure there are those who feel that netgroups are a waste of
time, and I don't want to dereference that pointer to arrays of pointers
#: any other files? i don't see anything else which seriously requires a
#: global special file to be added. all the support functions (for the
#: above files) can simply be written to handle a + if they see it. then
#: you can
#: put just regular data in the file
#: put data followed by a +
#: put a + followed by data
#: put just a +
#: or heavens yes, put a + in the middle of the data if you wanted.
#: and if you wanted to support hesiod for these things too, you could
#: very easily use the @ hack that i've yammered about for a few years.
#: in my mind it is stupid to try to centralize the control of data files
#: when the control can be interspersed with the data.
I think I agree with this. As mentioned above, it provides much