Reordering the rc.conf manual page

Tom Rhodes trhodes at FreeBSD.org
Fri Sep 16 02:18:51 UTC 2005


On Fri, 16 Sep 2005 02:41:45 +0300
Giorgos Keramidas <keramida at freebsd.org> wrote:

> On 2005-09-15 19:18, Tom Rhodes <trhodes at FreeBSD.org> wrote:
> > On Thu, 15 Sep 2005 16:29:26 +0300
> > Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
> > > On 2005-09-15 06:23, Tom Rhodes <trhodes at freebsd.org> wrote:
> > > > Hi,
> > > >
> > > > I've done some simple reordering of our rc.conf.5 manual page.
> > > > [...]
> > >
> > > The changes include both reordering and text additions (probably
> > > removals too, I haven't had a thorough look at the diff).  Is it
> > > possible to make this two patches, one with only moving around of
> > > existing text and one with new/deleted text?
> >
> > Actually, I did absolutely nothing to the original text other than
> > add to it.  I agree, moving it around and adding new text should
> > be separate commits.  Will handle.  This is just a "proof of
> > concept" patch which was only to arouse interest.
>   [...]
> > What do you think about the idea of what I'm doing though?  :)
> 
> It certainly looks like a good idea.
> 
> Alphabetically sorted variable names may make sense if they are all
> part of a single huge group, without any obvious separation.  I have
> to note that rc.conf variables lend themselves very easily to
> grouping of some sort though.
> 
> I've been using "sections" in my rc.conf files for ages.  Right now,
> I'm typing this on a system whose rc.conf is split into the following
> general categories of options:
> 
>     # Network Interfaces
>     # Misc Other Network Stuff
>     # Enabled Services
>     # Disabled Services
>     # Firewall Settings
>     # Mail Trasfer Agent Options
>     # Console Options
>     # Other System Options
> 
> This separation is, of course, just a matter of personal preference,
> and doesn't really matter at all when rc.conf is loaded by rc.d
> scripts -- all the options are slurped in anywa.
> 
> If my original post sounded like I didn't like the change, then by all
> means go for it.  It *is* useful, IMHO.

Heh, that was all I needed to hear.  :)

-- 
Tom Rhodes



More information about the freebsd-doc mailing list