From owner-freebsd-hackers  Wed Oct  1 13:30:58 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA05855
          for hackers-outgoing; Wed, 1 Oct 1997 13:30:58 -0700 (PDT)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA05850
          for <hackers@FreeBSD.ORG>; Wed, 1 Oct 1997 13:30:54 -0700 (PDT)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id NAA17783; Wed, 1 Oct 1997 13:30:45 -0700 (PDT)
To: Mike Smith <mike@smith.net.au>
cc: hackers@FreeBSD.ORG
Subject: Re: Interface configuration : call for ideas. 
In-reply-to: Your message of "Thu, 02 Oct 1997 00:41:48 +0930."
             <199710011511.AAA00666@word.smith.net.au> 
Date: Wed, 01 Oct 1997 13:30:45 -0700
Message-ID: <17758.875737845@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Ah, some input!  I thought you were busy?  If this is the quality of 
> feedback I get from busy people, we must be alone here... 8(

I am busy, but I hated to see this get the usual silent treatment. :-)

> This isn't actually very helpful; it just means @ = "lan", and that's 
> only going to confuse people.  I was originally going to say "ether" 

Actually, I meant "@ = wildcard" - this would be a general convention
and wouldn't just expand to "lan" in all cases, it would expand to
fit whatever was necessary to allow the fall-through case to work,
be it for an ethernet card or something else (how about specific
vs generic route entries, for example?).

But I still like option #2 better, so it's also probably not worth
debating overmuch. :)

> Because the actual set of event-response sequences are very small, with 
> just a few opt-in/opt out items?

Creeping featurism will expand this set of event-response sequences,
I'm sure. :-)

Also, if you think about it, the system's initial boot is also sort of
an "event" of sorts - I'm sure you could generalize this to the point
of absurdity, and it might not even be that bad of an idea.

> OK here.  I'm not sure how others will buy it.  Perhaps a POC 
> implementation is called for?  How do people feel about a potentially 
> new directory in /etc for files associated with this sort of thing?

POC?

> Is there any way in sh of determining the existence of a function?

I thought you'd just expand the target variable and check it
for NULL-ness ("").  If it expands, you pass it to eval.  If it
doesn't, you move on.

					Jordan