From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 19 03:43:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5865516A403 for ; Wed, 19 Apr 2006 03:43:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C735443D49 for ; Wed, 19 Apr 2006 03:43:10 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D6C4E46B0C; Tue, 18 Apr 2006 23:43:09 -0400 (EDT) Date: Wed, 19 Apr 2006 04:43:09 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: cokane@cokane.org In-Reply-To: <346a80220604181526m80f6566s72a85bd62f0f7e18@mail.gmail.com> Message-ID: <20060419043726.F40377@fledge.watson.org> References: <444515C8.3030406@centtech.com> <20060418165709.GA17705@central.0xfce3.net> <44452532.40703@centtech.com> <20060418.114933.69380798.imp@bsdimp.com> <346a80220604181102v3597a1edp3e05fa663b87e15c@mail.gmail.com> <20060418193018.GB694@turion.vk2pj.dyndns.org> <444545D3.5010405@centtech.com> <20060418203333.GA19094@central.0xfce3.net> <44454D96.3030004@centtech.com> <44456323.9070306@bitfreak.org> <346a80220604181526m80f6566s72a85bd62f0f7e18@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Darren Pilgrim , freebsd-hackers@freebsd.org Subject: Re: [PATCH] Fancy rc startup style RFC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2006 03:43:11 -0000 On Tue, 18 Apr 2006, Coleman Kane wrote: > I understand your concerns regarding the "pollution" of rc messages with > excess baggage such as ANSI-color sequences and attributes. The patches have > been set up in such a way as to provide the "fancy" capability only on > demand, and the "fancy w/ color" only as another toggle. I think that having > a more defined status interface would be very beneficial (and using colors > and other attributes supported by advanced terminal types seems to be what > people would like). > > For instance, right now we just have the name of the service printed if it > is started, otherwise an ugly (in my eyes) dump of its stderr is displayed > on-screen. If we instead defined an API that defined a "Service Name" > "Service Description" "Service Status" and "Error Code" then we could have a > more manageable service structure (IMHO). I think this work toward making > the service status messages prettier CAN ONLY BE GOOD. Even if "pretty > colors" are deemed "too fancy" by the freebsd gods in the end. > > As for your "buggy escape handling" of third-party terminals: 1) Don't > enable the feature and it won't be a problem, or 2) Don't use crappy > third-party terminal software that will die when it recieves ^[[0;31;40m > rather than setting the attributes to NormalText-Red-on-Black. In fact, I > haven't heard of one for some time. If adding color, please... (1) Confirm that the results "just work" with /var/log/console.log turned on. (2) Confirm that the results "just work" with dmesg -a. It has always struck me that what we have right now is the easiest to implement model for logging service startup, but the least useful from the perspective of consumers: we have script output that varies by application, component, etc. It would be nice to have either, and possibly both, of consistently user friendly output, or entirely machine-parseable content that could be used to generate user friendly output. I've wondered for a while if it wouldn't be useful to consider having a flag in syslogd to indicate that syslog should store log entries in the target logfile in binary format, so that log messages could be reviewed, sorted, searched, etc, by facility, criticality, source process, etc... Robert N M Watson