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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
