From owner-freebsd-hackers Fri Apr 25 20:38:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA02025 for hackers-outgoing; Fri, 25 Apr 1997 20:38:25 -0700 (PDT) Received: from mixcom.mixcom.com (mixcom.mixcom.com [198.137.186.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA02020 for ; Fri, 25 Apr 1997 20:38:20 -0700 (PDT) Received: by mixcom.mixcom.com (8.6.12/2.2) id WAA26978; Fri, 25 Apr 1997 22:38:13 -0500 Received: from p75.mixcom.com(198.137.186.25) by mixcom.mixcom.com via smap (V1.3) id sma026951; Sat Apr 26 03:38:02 1997 Message-Id: <3.0.32.19970425224042.00b1e2a8@mixcom.com> X-Sender: sysop@mixcom.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 25 Apr 1997 22:40:43 -0500 To: Curt Sampson From: "Jeffrey J. Mountin" Subject: Re: /etc/netstart bogons.. Cc: hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 11:54 AM 4/24/97 -0700, Curt Sampson wrote: >Not really, no. Setting the variable to "DEFAULT" means use the >default value. Many of our variables are set to "NO" not to run >the program, "DEFAULT" to use reasonable defaults, or a list of >flags. Thus, having the variable set to "" or unset (they're the >same thing in /bin/sh) means `run the program with no command line >arguments.' Exactly. There are some things that users may wish to run without any flags. FWIW, I go in /etc/rc.* and comment what I never want. >We have other variables that simply turn things on or off, and >these are set to just YES or NO as needed. So then the default should be yes or no, but the lesser of evils. 8-) I don't run a print daemon, so having to unset LPD="YES" annoys me, but considering the other changes I must do... Another thing that is adding lines (comments are nice) are the repeated "imported from /etc/sysconfig" entries. How about a nice layout, as it looks like they could be under a section, just like sysconfig is compartmented. >As for using shell functions and passing program names and whatnot >as parameters, there are enough special cases out there that this >may not be worthwhile. Things like: I guess what is boils down to is how to make it reasonably foolishness-proof and yet not bloat the thing with a zillion checks. A backup shell script I wrote could be done with far few than the almost 300 lines it has, but with mounting and unmounting going on, I decided to make it more bulletproof than easily readable. With that in mind, it could be done with extensive checks, but where would they go? Certainly not in sysconfig or newer users would be a bit lost. ------------------------------------------- Jeff Mountin - System/Network Administrator jeff@mixcom.net MIX Communications Serving the Internet since 1990