Re: [PATCH] Fancy rc startup style RFC
On 05/25/06 15:15, Eric Anderson wrote: Coleman Kane wrote: On Wed, May 24, 2006 at 12:29:28PM -0500, Eric Anderson wrote, and it was proclaimed: Eric Anderson wrote: Coleman Kane wrote: On Mon, May 01, 2006 at 12:29:20PM -0700, Brooks Davis wrote: On Mon, May 01, 2006 at 02:16:04PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. True, however I still see a difference between FAILED and WARNING. For instance, as an example: a FAILED RAID is different than a RAID with a WARNING. For that level of detail, the ability to provide additional output seems like the appropriate solution. Yes, true, but you'd still want to show something (I would think) in the [ ]'s to keep it consistent. My feeling is that anything short of complete success should report WARNING and a message unless it actually totally failed in which case FAILED or ERROR (I slightly perfer ERROR) should be used. -- Brooks What situations are we determining get flagged as ERROR versus FAILED? Is FAILED considered to be 'I was able to run the command, but it returned an error code', versus ERROR being 'I could not even run the command!' like bad path, file not found, etc... This point still kind of confuses me (and needs to be well defined). I am an advocate of having three distinct messages: OK, SKIPPED, ERROR. And not even bothering with the different types of ERROR/FAILED other than having extra reporting output. I'm ok with just OK, SKIPPED, ERROR.. If there's ever a need for more, it's easy to add it. Eric Is this still planned to make it into -CURRENT? Thanks, Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. Yeah, I've been working on it in my spare time. I am investigating some avenues regarding status reporting from the rc scripts to the console. Also been slow getting some hardware together to put cokane.org back up and online. Mostly real-life just got in the way of freebsd for a little while. -- coleman kane Ok - just making sure it had not been forgotten. :) Thanks Coleman! Eric Any progress on this? Maybe another committer could take a look at it if you are too busy? Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Coleman Kane wrote: On Wed, May 24, 2006 at 12:29:28PM -0500, Eric Anderson wrote, and it was proclaimed: Eric Anderson wrote: Coleman Kane wrote: On Mon, May 01, 2006 at 12:29:20PM -0700, Brooks Davis wrote: On Mon, May 01, 2006 at 02:16:04PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. True, however I still see a difference between FAILED and WARNING. For instance, as an example: a FAILED RAID is different than a RAID with a WARNING. For that level of detail, the ability to provide additional output seems like the appropriate solution. Yes, true, but you'd still want to show something (I would think) in the [ ]'s to keep it consistent. My feeling is that anything short of complete success should report WARNING and a message unless it actually totally failed in which case FAILED or ERROR (I slightly perfer ERROR) should be used. -- Brooks What situations are we determining get flagged as ERROR versus FAILED? Is FAILED considered to be 'I was able to run the command, but it returned an error code', versus ERROR being 'I could not even run the command!' like bad path, file not found, etc... This point still kind of confuses me (and needs to be well defined). I am an advocate of having three distinct messages: OK, SKIPPED, ERROR. And not even bothering with the different types of ERROR/FAILED other than having extra reporting output. I'm ok with just OK, SKIPPED, ERROR.. If there's ever a need for more, it's easy to add it. Eric Is this still planned to make it into -CURRENT? Thanks, Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. Yeah, I've been working on it in my spare time. I am investigating some avenues regarding status reporting from the rc scripts to the console. Also been slow getting some hardware together to put cokane.org back up and online. Mostly real-life just got in the way of freebsd for a little while. -- coleman kane Ok - just making sure it had not been forgotten. :) Thanks Coleman! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Eric Anderson wrote: Coleman Kane wrote: On Mon, May 01, 2006 at 12:29:20PM -0700, Brooks Davis wrote: On Mon, May 01, 2006 at 02:16:04PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. True, however I still see a difference between FAILED and WARNING. For instance, as an example: a FAILED RAID is different than a RAID with a WARNING. For that level of detail, the ability to provide additional output seems like the appropriate solution. Yes, true, but you'd still want to show something (I would think) in the [ ]'s to keep it consistent. My feeling is that anything short of complete success should report WARNING and a message unless it actually totally failed in which case FAILED or ERROR (I slightly perfer ERROR) should be used. -- Brooks What situations are we determining get flagged as ERROR versus FAILED? Is FAILED considered to be 'I was able to run the command, but it returned an error code', versus ERROR being 'I could not even run the command!' like bad path, file not found, etc... This point still kind of confuses me (and needs to be well defined). I am an advocate of having three distinct messages: OK, SKIPPED, ERROR. And not even bothering with the different types of ERROR/FAILED other than having extra reporting output. I'm ok with just OK, SKIPPED, ERROR.. If there's ever a need for more, it's easy to add it. Eric Is this still planned to make it into -CURRENT? Thanks, Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Wed, May 24, 2006 at 12:29:28PM -0500, Eric Anderson wrote, and it was proclaimed: Eric Anderson wrote: Coleman Kane wrote: On Mon, May 01, 2006 at 12:29:20PM -0700, Brooks Davis wrote: On Mon, May 01, 2006 at 02:16:04PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. True, however I still see a difference between FAILED and WARNING. For instance, as an example: a FAILED RAID is different than a RAID with a WARNING. For that level of detail, the ability to provide additional output seems like the appropriate solution. Yes, true, but you'd still want to show something (I would think) in the [ ]'s to keep it consistent. My feeling is that anything short of complete success should report WARNING and a message unless it actually totally failed in which case FAILED or ERROR (I slightly perfer ERROR) should be used. -- Brooks What situations are we determining get flagged as ERROR versus FAILED? Is FAILED considered to be 'I was able to run the command, but it returned an error code', versus ERROR being 'I could not even run the command!' like bad path, file not found, etc... This point still kind of confuses me (and needs to be well defined). I am an advocate of having three distinct messages: OK, SKIPPED, ERROR. And not even bothering with the different types of ERROR/FAILED other than having extra reporting output. I'm ok with just OK, SKIPPED, ERROR.. If there's ever a need for more, it's easy to add it. Eric Is this still planned to make it into -CURRENT? Thanks, Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. Yeah, I've been working on it in my spare time. I am investigating some avenues regarding status reporting from the rc scripts to the console. Also been slow getting some hardware together to put cokane.org back up and online. Mostly real-life just got in the way of freebsd for a little while. -- coleman kane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
Hi,
Sorry for replying to an old message, but nobody has
responded to this particular question, so I give it
a try ...
Coleman Kane [EMAIL PROTECTED] wrote:
One unfortunate thing about /bin/sh: [from the sh(1) manpage]
Only one of the -e and -n options may be specified.
This means that we may not be able to use the -n to chain multiple echos on
one line...
You can use the backslash sequence '\c' with echo -e, which
has the same effect as the -n option. See sh(1).
Another possibility is to use dd(1) to strip off the new-
line (dd(1) lives in /bin, so it's available during boot).
A shell function like this does it:
echo-en()
{
x=$*
echo -e $x | dd bs=$((${#x}-1)) count=1 2/dev/null
}
Although it's a bit less efficient because dd(1) is an
external binary, it's more flexible since it can be used
for all kinds of cutting and trimming (note that cut(1)
resides in /usr/bin).
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
When your hammer is C++, everything begins to look like a thumb.
-- Steve Haflich, in comp.lang.c++
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
Hey all, My webserver went down earlier this week, and I have moved my mail. I am in the arduous process of getting a new replacement. I apologize for the delay however, on the rc.subr colorization project, and hope to have the newest updates available again soon. -- Coleman Kane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Coleman Kane wrote: On Mon, May 01, 2006 at 12:29:20PM -0700, Brooks Davis wrote: On Mon, May 01, 2006 at 02:16:04PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. True, however I still see a difference between FAILED and WARNING. For instance, as an example: a FAILED RAID is different than a RAID with a WARNING. For that level of detail, the ability to provide additional output seems like the appropriate solution. Yes, true, but you'd still want to show something (I would think) in the [ ]'s to keep it consistent. My feeling is that anything short of complete success should report WARNING and a message unless it actually totally failed in which case FAILED or ERROR (I slightly perfer ERROR) should be used. -- Brooks What situations are we determining get flagged as ERROR versus FAILED? Is FAILED considered to be 'I was able to run the command, but it returned an error code', versus ERROR being 'I could not even run the command!' like bad path, file not found, etc... This point still kind of confuses me (and needs to be well defined). I am an advocate of having three distinct messages: OK, SKIPPED, ERROR. And not even bothering with the different types of ERROR/FAILED other than having extra reporting output. I'm ok with just OK, SKIPPED, ERROR.. If there's ever a need for more, it's easy to add it. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpYQgn2NtubX.pgp Description: PGP signature
Re: [PATCH] Fancy rc startup style RFC
Brooks Davis wrote: On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. True, however I still see a difference between FAILED and WARNING. For instance, as an example: a FAILED RAID is different than a RAID with a WARNING. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. True, however I still see a difference between FAILED and WARNING. For instance, as an example: a FAILED RAID is different than a RAID with a WARNING. For that level of detail, the ability to provide additional output seems like the appropriate solution. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpEIdQf0xPWV.pgp Description: PGP signature
Re: [PATCH] Fancy rc startup style RFC
Brooks Davis wrote: On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. True, however I still see a difference between FAILED and WARNING. For instance, as an example: a FAILED RAID is different than a RAID with a WARNING. For that level of detail, the ability to provide additional output seems like the appropriate solution. Yes, true, but you'd still want to show something (I would think) in the [ ]'s to keep it consistent. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Mon, May 01, 2006 at 02:16:04PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. True, however I still see a difference between FAILED and WARNING. For instance, as an example: a FAILED RAID is different than a RAID with a WARNING. For that level of detail, the ability to provide additional output seems like the appropriate solution. Yes, true, but you'd still want to show something (I would think) in the [ ]'s to keep it consistent. My feeling is that anything short of complete success should report WARNING and a message unless it actually totally failed in which case FAILED or ERROR (I slightly perfer ERROR) should be used. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpGZpW4qASAi.pgp Description: PGP signature
Re: [PATCH] Fancy rc startup style RFC
On Mon, May 01, 2006 at 12:29:20PM -0700, Brooks Davis wrote: On Mon, May 01, 2006 at 02:16:04PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Mon, May 01, 2006 at 02:13:22PM -0500, Eric Anderson wrote: Brooks Davis wrote: On Sun, Apr 30, 2006 at 10:23:32PM -0500, Eric Anderson wrote: Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. FAILED vs ERROR seems confusing. I'd be inclined toward WARNING vs FAILED or ERROR. True, however I still see a difference between FAILED and WARNING. For instance, as an example: a FAILED RAID is different than a RAID with a WARNING. For that level of detail, the ability to provide additional output seems like the appropriate solution. Yes, true, but you'd still want to show something (I would think) in the [ ]'s to keep it consistent. My feeling is that anything short of complete success should report WARNING and a message unless it actually totally failed in which case FAILED or ERROR (I slightly perfer ERROR) should be used. -- Brooks What situations are we determining get flagged as ERROR versus FAILED? Is FAILED considered to be 'I was able to run the command, but it returned an error code', versus ERROR being 'I could not even run the command!' like bad path, file not found, etc... This point still kind of confuses me (and needs to be well defined). I am an advocate of having three distinct messages: OK, SKIPPED, ERROR. And not even bothering with the different types of ERROR/FAILED other than having extra reporting output. Of course, I am still willing to implement what the consensus is. -- Coleman Kane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? TODO: One thing I am trying to figure out is how to get the terminal to report its width, in columns (which is something that VT100+ supports). I just don't know how to do it from a script. TODO: Get better reporting from the rc.d/* scripts (and whatever other services we track). Right now, if verbose is on, many services respond with OK when they aren't initialized, and some respond with SKIP/SKIPPED/FAILED. E.g.: pcvt will show SKIP, but geli2 will show OK. Neither of these two are enabled for me though. You may get it from here: http://www.cokane.org/files/rc_fancy-cokane5.patch Further: I am very open to suggestions regarding the rc.d/* system and its reporting mechanisms. I am even thinking that it might be a good idea to offer an overhauled set of scripts that forces functionality into the following framework: rc job offers result code (from which the OK,SKIP,ERROR, etc... are picked) rc job offers short ( 20 char) status message. This could be printed in a nice fashion just after the Running start XXX, Running stop YYY, which we currently display. rc job (or rc itself) offers name of job (geli2, moused, etc...). Thus, the lines are nice, consistent, and fluid. The short status message above would most likely be truncated to 20 chars (or so.). Hopefully, some of this can then start to be put into an rc-reporter such that I could run a command that could give me a nice report of rc/init: moused FAILEDshort message Gentoo has a nice script named rc-status that does similar. Though I am not too fond of its output format (job name at left, status at right edge, hard to find out what failed in a multiline report). Try this latest version, and drop a line back with your thoughts, criticisms, etc -- Coleman Kane [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Coleman Kane wrote: On Mon, Apr 24, 2006 at 09:45:09AM -0500, Eric Anderson wrote: Eric Anderson wrote: Actually, some other things got changed somewhere in the history, that broke some things and assumptions I was making. This patch has them fixed, and I've tested it with all the different options: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-9 It's missing the defaults/rc.conf diffs, but you should already know those. Eric I have a new patch (to 7-CURRENT) of the fancy_rc updates. This allows the use of: rc_fancy=YES--- Turns on fancy reporting (w/o color) rc_fancy_color=YES --- Turns on fancy reporting (w/ color), needs rc_fancy=YES rc_fancy_colour=YES --- Same as above for you on the other side of the pond. rc_fancy_verbose=YES -- Turn on more verbose activity messages. This will cause what appear to be false positives, where an unused service is OK instead of SKIP. You can also customize the colors, the widths of the message brackets (e.g. [ OK ] vs. [ OK ]), the screen width, and the contents of the message (OK versus GOOD versus BUENO). Also, we have the following message combinations: OK --- Universal good message SKIP,SKIPPED --- Two methods for conveying the same idea? ERROR,FAILED --- Ditto above, for failure cases Should we just have 3 different messages, rather than 5 messages in 3 categories? Yes, that's something that started with my first patch, and never got ironed out. I think it should be: OK SKIPPED FAILED and possibly also: ERROR The difference between FAILED and ERROR would be that FAILED means the service did not start at all, and ERROR means it started but had some kind of error response. TODO: One thing I am trying to figure out is how to get the terminal to report its width, in columns (which is something that VT100+ supports). I just don't know how to do it from a script. I looked into that too, without finding a good way to do that. TODO: Get better reporting from the rc.d/* scripts (and whatever other services we track). Right now, if verbose is on, many services respond with OK when they aren't initialized, and some respond with SKIP/SKIPPED/FAILED. E.g.: pcvt will show SKIP, but geli2 will show OK. Neither of these two are enabled for me though. I agree here, and started looking into many of the scripts there now. There are a lot that need tweaking, but in the long run, I think it would be very nice and clean, and allow for some nice reporting and logging. You may get it from here: http://www.cokane.org/files/rc_fancy-cokane5.patch Further: I am very open to suggestions regarding the rc.d/* system and its reporting mechanisms. I am even thinking that it might be a good idea to offer an overhauled set of scripts that forces functionality into the following framework: rc job offers result code (from which the OK,SKIP,ERROR, etc... are picked) rc job offers short ( 20 char) status message. This could be printed in a nice fashion just after the Running start XXX, Running stop YYY, which we currently display. rc job (or rc itself) offers name of job (geli2, moused, etc...). Thus, the lines are nice, consistent, and fluid. The short status message above would most likely be truncated to 20 chars (or so.). Hopefully, some of this can then start to be put into an rc-reporter such that I could run a command that could give me a nice report of rc/init: moused FAILEDshort message Gentoo has a nice script named rc-status that does similar. Though I am not too fond of its output format (job name at left, status at right edge, hard to find out what failed in a multiline report). Try this latest version, and drop a line back with your thoughts, criticisms, etc Thanks again for taking hold of this and driving it further! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [PATCH] Fancy rc startup style RFC - v6
[EMAIL PROTECTED] wrote: On Thu, Apr 20, 2006 at 10:32:33PM -0500, Eric Anderson wrote: Other than that, do we have general consensus that these do what they claim? Any outstanding issues that haven't been addressed? One request: Please remove the two seperate rc.conf lines, and replace with just one: rc_fancy= YES | NO | COL[O|OU]R So that it works line the sendmail_enable option (YES/NO/NONE) Then include any other tunables in rc_fancy_flags Definitely not a good idea to use that as a model: man rc.sendmail .. sendmail_enable (str) If set to ``YES'', run the sendmail(8) daemon at system boot time. If set to ``NO'', do not run a sendmail(8) daemon to listen for incoming network mail. This does not preclude a sendmail(8) daemon listening on the SMTP port of the loopback interface. The ``NONE'' option is deprecated and should not be used. It will be removed in a future release. .. Yes/no options should just be yes/no. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
On 4/23/06, Sean Winn [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Thu, Apr 20, 2006 at 10:32:33PM -0500, Eric Anderson wrote: Other than that, do we have general consensus that these do what they claim? Any outstanding issues that haven't been addressed? One request: Please remove the two seperate rc.conf lines, and replace with just one: rc_fancy= YES | NO | COL[O|OU]R So that it works line the sendmail_enable option (YES/NO/NONE) Then include any other tunables in rc_fancy_flags Definitely not a good idea to use that as a model: man rc.sendmail .. sendmail_enable (str) If set to ``YES'', run the sendmail(8) daemon at system boot time. If set to ``NO'', do not run a sendmail(8) daemon to listen for incoming network mail. This does not preclude a sendmail(8) daemon listening on the SMTP port of the loopback interface. The ``NONE'' option is deprecated and should not be used. It will be removed in a future release. .. Yes/no options should just be yes/no. Correct, I concur. This is especially true since the 'configuration check' function is checkyesno and looks for YES or NO values. In fact, I think that sendmail was the only one two use this convention. This was brought in to appease those who use qmail (or other mailservers) with an easy method of turning off sendmail's local 'spool' service, to instead use qmail (or whatever else you like...). I remember the convention not being very pleasant for those involved. -- coleman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
On Thu, Apr 20, 2006 at 10:32:33PM -0500, Eric Anderson wrote: This looks good. I only wonder about two things now: - Should we also have a line for the actual colors used too? Or is that going too crazy? - Does it meet style(9)? I'm wondering about line lengths now. Other than that, do we have general consensus that these do what they claim? Any outstanding issues that haven't been addressed? Eric It looks like freebsd.org (actually SpamCop) might finally be blocking gmail now :(... I sent the following and it got bounced: There was a small defect in the recent version of this script that caused the line width to be too big on the syscons console. I modified it and posted it at: http://www.cokane.org/files/rc_fancy-cokane3.patch -- coleman kane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
On 4/21/06, David Barbero [EMAIL PROTECTED] wrote: Eric Anderson escribió: After to apply the patch, so that it works is necessary to put in rc.conf rc_fancy=YES , when put this single entry, the system gives errors saying that correctly this entry in rc.conf is not correctly defined, adding single rc_fancy_color=YES gives the same error. If the two entry meetings are added it don't show the error. I believe that serious advisable that these two entry did not depend the one on the other and worked separately. Well, obviously the _color option depends on the rc_fancy option being enabled, otherwise it doesn't make sense, however you can of course have rc_fancy enabled with rc_fancy_color disabled. yes, this is obvious, but i say rc_fancy depends on the rc_fancy_color, disabled or no, in rc.conf, if you don't put a entry for rc_fancy_color in rc.conf, the boot menssage show error. Yep, that's a bug. I think it's fixed in v7, available here: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7 along with a few other suggestions from others. Ok, i will probe this patch in a few days and tell you for this. Probably Sunday can say something, right now I am of business trip and I do not have my PC of tests here... Another one of the failures that I have seen is that with this patch they show all the services, they are or not formed to start, I believe that single they would have to appear the services that are formed to start and not all those that can start. If the service is run on bootup, it shows it. It was still being run before, there was just no output previously. It would be pretty easy to have an option to not print these, maybe an rc_fancy_verbose option. Is this desirable to most? I think a _verbose option don't for now, but can will be interesting. In any case I talked about that if you don't start a service (Ex: geli_enable=NO in rc.conf) at boot time, in your patch this service it's show, and IMHO, if the service don't start at bootup, then don't show startup. In addition the services that are not formed to start appear like [ OK ], in the case of appearing these, I believe that they would have to leave with another denomination that is not [ OK ]. I'm not sure what you mean here. Can you give me an example? Sorry for my English :) Yes, of course. in rc.conf: geli_enable=NO inetd_enable=NO And when yo reboot, the bootup menssage show: geli service [OK] inetd service [OK] And I believe that this menssage don't show on startup, or in the case of show the messange, this don't show the [OK], in that case, show [SKIP], for example. Another failure that I have seen is that when leaving the message syslogd this sample failure, but this service starts without problems, but shows it as if it gave failure... My syslogd looks clean, and doesn't give a false failure. I'm not sure how to look into this - can you confirm that it truly is passing, but giving the wrong message, or is it that the rc subsystem thinks it's failing but appears to work ok? My syslogd work properly whitout any error, but give a false positive, I will be probe the last patch and I will try to see if I locate the failure, but will have Sunday... I see other fail in show the fancy_* when I have activated vidcontrol to 1024x764, but this is but so that it is pretty that an operation failure, IMHO is not important... Thanks for all the feedback and testing! :) Eric Regards There was a small defect in the recent version of this script that caused the line width to be too big on the syscons console. I modified it and posted it at: http://www.cokane.org/files/rc_fancy-cokane3.patch --coleman kane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
On Thu, Apr 20, 2006 at 10:32:33PM -0500, Eric Anderson wrote: Other than that, do we have general consensus that these do what they claim? Any outstanding issues that haven't been addressed? One request: Please remove the two seperate rc.conf lines, and replace with just one: rc_fancy= YES | NO | COL[O|OU]R So that it works line the sendmail_enable option (YES/NO/NONE) Then include any other tunables in rc_fancy_flags ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
Coleman Kane wrote: On 4/20/06, *Eric Anderson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: David Barbero wrote: --- snip --- Yep, that's a bug. I think it's fixed in v7, available here: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7 along with a few other suggestions from others. Another one of the failures that I have seen is that with this patch they show all the services, they are or not formed to start, I believe that single they would have to appear the services that are formed to start and not all those that can start. If the service is run on bootup, it shows it. It was still being run before, there was just no output previously. It would be pretty easy to have an option to not print these, maybe an rc_fancy_verbose option. Is this desirable to most? In addition the services that are not formed to start appear like [ OK ], in the case of appearing these, I believe that they would have to leave with another denomination that is not [ OK ]. I'm not sure what you mean here. Can you give me an example? Another failure that I have seen is that when leaving the message syslogd this sample failure, but this service starts without problems, but shows it as if it gave failure... My syslogd looks clean, and doesn't give a false failure. I'm not sure how to look into this - can you confirm that it truly is passing, but giving the wrong message, or is it that the rc subsystem thinks it's failing but appears to work ok? In principle this is what I have seen at first sight on the patch. Thanks for all the feedback and testing! Eric I have modified the patch as follows: Made a bunch of the settings tunable by the user (message text and field widths). It is availalbe at http://www.cokane.org/files/rc_fancy-cokane2.patch This looks good. I only wonder about two things now: - Should we also have a line for the actual colors used too? Or is that going too crazy? - Does it meet style(9)? I'm wondering about line lengths now. Other than that, do we have general consensus that these do what they claim? Any outstanding issues that haven't been addressed? is the information correct? for example: Running start savecore [FAILED] Running start virecover[FAILED] the above didn't fail, they just had nothing to do. there is a danger with false negatives, it tends to confuse the uninitiated, there is a also a problem with false positives: Running start geli2[ OK ] Running start mixer[ OK ] these do nothing, no geli2 nor mixer. The problem is one of interpretation, what does OK realy mean? one of the things i dislike with Linux is the amount of information printed when booting, it just wisks by, and when things don't work it's not clear what caused it! just to show that you are not alone: Apr 19 12:24:33 gto postgres[43823]: [2-1] FATAL: the database system is starting up danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
Eric Anderson escribió: After to apply the patch, so that it works is necessary to put in rc.conf rc_fancy=YES , when put this single entry, the system gives errors saying that correctly this entry in rc.conf is not correctly defined, adding single rc_fancy_color=YES gives the same error. If the two entry meetings are added it don't show the error. I believe that serious advisable that these two entry did not depend the one on the other and worked separately. Well, obviously the _color option depends on the rc_fancy option being enabled, otherwise it doesn't make sense, however you can of course have rc_fancy enabled with rc_fancy_color disabled. yes, this is obvious, but i say rc_fancy depends on the rc_fancy_color, disabled or no, in rc.conf, if you don't put a entry for rc_fancy_color in rc.conf, the boot menssage show error. Yep, that's a bug. I think it's fixed in v7, available here: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7 along with a few other suggestions from others. Ok, i will probe this patch in a few days and tell you for this. Probably Sunday can say something, right now I am of business trip and I do not have my PC of tests here... Another one of the failures that I have seen is that with this patch they show all the services, they are or not formed to start, I believe that single they would have to appear the services that are formed to start and not all those that can start. If the service is run on bootup, it shows it. It was still being run before, there was just no output previously. It would be pretty easy to have an option to not print these, maybe an rc_fancy_verbose option. Is this desirable to most? I think a _verbose option don't for now, but can will be interesting. In any case I talked about that if you don't start a service (Ex: geli_enable=NO in rc.conf) at boot time, in your patch this service it's show, and IMHO, if the service don't start at bootup, then don't show startup. In addition the services that are not formed to start appear like [ OK ], in the case of appearing these, I believe that they would have to leave with another denomination that is not [ OK ]. I'm not sure what you mean here. Can you give me an example? Sorry for my English :) Yes, of course. in rc.conf: geli_enable=NO inetd_enable=NO And when yo reboot, the bootup menssage show: geli service [OK] inetd service [OK] And I believe that this menssage don't show on startup, or in the case of show the messange, this don't show the [OK], in that case, show [SKIP], for example. Another failure that I have seen is that when leaving the message syslogd this sample failure, but this service starts without problems, but shows it as if it gave failure... My syslogd looks clean, and doesn't give a false failure. I'm not sure how to look into this - can you confirm that it truly is passing, but giving the wrong message, or is it that the rc subsystem thinks it's failing but appears to work ok? My syslogd work properly whitout any error, but give a false positive, I will be probe the last patch and I will try to see if I locate the failure, but will have Sunday... I see other fail in show the fancy_* when I have activated vidcontrol to 1024x764, but this is but so that it is pretty that an operation failure, IMHO is not important... Thanks for all the feedback and testing! :) Eric Regards -- Linux is for people who hate Windows, BSD is for people who love UNIX Social Engineer - Because there is no patch for human stupidity ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
Eric Anderson escribió: Thanks to Rick Petty for pointing me in the right direction (man page!), here's the latest, and I think solid patch (for RELENG-6): http://www.googlebit.com/freebsd/patches/rc_fancy.patch-6 Eric Hi all. I have found several anomalies operations in the patch. After to apply the patch, so that it works is necessary to put in rc.conf rc_fancy=YES , when put this single entry, the system gives errors saying that correctly this entry in rc.conf is not correctly defined, adding single rc_fancy_color=YES gives the same error. If the two entry meetings are added it don't show the error. I believe that serious advisable that these two entry did not depend the one on the other and worked separately. Another failure with which I have been is that after apply the patch and to take the normal system, without the entry rc_fancy * the system does not show such messages exactly, leave several points between the lines of the services. Ej: starting sendmail . . . starting apache and it would have to see itself of the following way: starting sendmail starting apache Another one of the failures that I have seen is that with this patch they show all the services, they are or not formed to start, I believe that single they would have to appear the services that are formed to start and not all those that can start. In addition the services that are not formed to start appear like [ OK ], in the case of appearing these, I believe that they would have to leave with another denomination that is not [ OK ]. Another failure that I have seen is that when leaving the message syslogd this sample failure, but this service starts without problems, but shows it as if it gave failure... In principle this is what I have seen at first sight on the patch. Regards. -- Linux is for people who hate Windows, BSD is for people who love UNIX Social Engineer - Because there is no patch for human stupidity ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
While stranded on the shoulder of the Information Superhiway and trying to flag down some passing bytes [EMAIL PROTECTED] said Bits don't fail me now, and continued with: Date: Wed, 19 Apr 2006 13:03:57 -0400 From: Coleman Kane [EMAIL PROTECTED] Subject: Re: [PATCH] Fancy rc startup style RFC On 4/19/06, Mike Meyer [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], Coleman Kane [EMAIL PROTECTED] typed: On 4/19/06, Mike Meyer [EMAIL PROTECTED] wrote: How about we all discuss good choices for default colors? Depends on the goal: do you want the default to work for everyone, or do you want the default to be prettier and/or better for most people but absolutely suck for a few? I was thinking perhaps of having a predefined set of templates (with the option and documentation to add your own). Perhaps implement one that creates the traffic-light style that seems to make intuitive sense to many americans (Bold Red: error, Bold Green: Success, Bold Yellow: warning/notice), and also have another perdefined one that uses a different color set. Traffic-light style is also designed to be useable by completely color-blind people - which is rare. By that if you notice traffic lights are always in the same order, green, yellow, red so that all you have to do is be able to see the luminance value in the abscence of any chroma information.. That's the problem with web-sites which depend on chroma value, and often have colors which are easily discernable by normally sighted people, but the luminance is very close which can make things almost invisible. I have a noticed a traffic-sign problem which another person also wrote to the local newspaper - and the traffic division is looking to change the signs. In Florida bright days are indeed very bright. There are signs that use lights to spell out the message with what someone feels the most important part in 'red'. The signs have a black background. On a bright day I see NO TURN ON or TO PEDS as the word RED in the first message is invisible to me, and the YIELD in the second has the same effect. There is also a sign that I came up to that used the universal sign for turn. I started to turn and my wife had me stop because the circle with bar through it was in RED and I could not see it. On overcast days or at night these signs are easily viewable. For those of you who remember the late 1980s when IBM came out with OS/2 and MS came out with a new Windows, the complaints were the default screens on OS/2 were drab while the Windows had bright colors. IBM is very good at designing things for people with disabilites and the OS/2 default screen was designed to be readable by someone with total color-blindness - which as I said is rare. The way to check if a web-site is readable by all it to use a monochrome monitor [ exceedingly hard to find nowdays ], and at least some government sites are now required to be that way. Color can be a great way to emphasize items IF the chroma and luminance values are carefully chosen. If not you can take away a lot of functionality. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
In [EMAIL PROTECTED], Bill Vermillion [EMAIL PROTECTED] typed: The way to check if a web-site is readable by all it to use a monochrome monitor [ exceedingly hard to find nowdays ], and at least some government sites are now required to be that way. This is part of section 508, and *all* web sites run by organizations that receive US government monies are supposed to comply with it. The government doesn't do a lot to enforce this, though. FWIW, the last time I checked, the question of whether or not a web site that wasn't covered by section 508 was covered by the ADA was still up in the air, hinging on whether or not a web site constituted a public place (but it's been a while since I checked). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
David Barbero wrote: Eric Anderson escribió: Thanks to Rick Petty for pointing me in the right direction (man page!), here's the latest, and I think solid patch (for RELENG-6): http://www.googlebit.com/freebsd/patches/rc_fancy.patch-6 Eric Hi all. I have found several anomalies operations in the patch. After to apply the patch, so that it works is necessary to put in rc.conf rc_fancy=YES , when put this single entry, the system gives errors saying that correctly this entry in rc.conf is not correctly defined, adding single rc_fancy_color=YES gives the same error. If the two entry meetings are added it don't show the error. I believe that serious advisable that these two entry did not depend the one on the other and worked separately. Well, obviously the _color option depends on the rc_fancy option being enabled, otherwise it doesn't make sense, however you can of course have rc_fancy enabled with rc_fancy_color disabled. Another failure with which I have been is that after apply the patch and to take the normal system, without the entry rc_fancy * the system does not show such messages exactly, leave several points between the lines of the services. Ej: starting sendmail . . . starting apache and it would have to see itself of the following way: starting sendmail starting apache Yep, that's a bug. I think it's fixed in v7, available here: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7 along with a few other suggestions from others. Another one of the failures that I have seen is that with this patch they show all the services, they are or not formed to start, I believe that single they would have to appear the services that are formed to start and not all those that can start. If the service is run on bootup, it shows it. It was still being run before, there was just no output previously. It would be pretty easy to have an option to not print these, maybe an rc_fancy_verbose option. Is this desirable to most? In addition the services that are not formed to start appear like [ OK ], in the case of appearing these, I believe that they would have to leave with another denomination that is not [ OK ]. I'm not sure what you mean here. Can you give me an example? Another failure that I have seen is that when leaving the message syslogd this sample failure, but this service starts without problems, but shows it as if it gave failure... My syslogd looks clean, and doesn't give a false failure. I'm not sure how to look into this - can you confirm that it truly is passing, but giving the wrong message, or is it that the rc subsystem thinks it's failing but appears to work ok? In principle this is what I have seen at first sight on the patch. Thanks for all the feedback and testing! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Bill Vermillion wrote: While stranded on the shoulder of the Information Superhiway and trying to flag down some passing bytes [EMAIL PROTECTED] said Bits don't fail me now, and continued with: Date: Wed, 19 Apr 2006 13:03:57 -0400 From: Coleman Kane [EMAIL PROTECTED] Subject: Re: [PATCH] Fancy rc startup style RFC On 4/19/06, Mike Meyer [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], Coleman Kane [EMAIL PROTECTED] typed: On 4/19/06, Mike Meyer [EMAIL PROTECTED] wrote: How about we all discuss good choices for default colors? Depends on the goal: do you want the default to work for everyone, or do you want the default to be prettier and/or better for most people but absolutely suck for a few? I was thinking perhaps of having a predefined set of templates (with the option and documentation to add your own). Perhaps implement one that creates the traffic-light style that seems to make intuitive sense to many americans (Bold Red: error, Bold Green: Success, Bold Yellow: warning/notice), and also have another perdefined one that uses a different color set. Traffic-light style is also designed to be useable by completely color-blind people - which is rare. By that if you notice traffic lights are always in the same order, green, yellow, red so that all you have to do is be able to see the luminance value in the abscence of any chroma information.. That's the problem with web-sites which depend on chroma value, and often have colors which are easily discernable by normally sighted people, but the luminance is very close which can make things almost invisible. I have a noticed a traffic-sign problem which another person also wrote to the local newspaper - and the traffic division is looking to change the signs. In Florida bright days are indeed very bright. There are signs that use lights to spell out the message with what someone feels the most important part in 'red'. The signs have a black background. On a bright day I see NO TURN ON or TO PEDS as the word RED in the first message is invisible to me, and the YIELD in the second has the same effect. There is also a sign that I came up to that used the universal sign for turn. I started to turn and my wife had me stop because the circle with bar through it was in RED and I could not see it. On overcast days or at night these signs are easily viewable. For those of you who remember the late 1980s when IBM came out with OS/2 and MS came out with a new Windows, the complaints were the default screens on OS/2 were drab while the Windows had bright colors. IBM is very good at designing things for people with disabilites and the OS/2 default screen was designed to be readable by someone with total color-blindness - which as I said is rare. The way to check if a web-site is readable by all it to use a monochrome monitor [ exceedingly hard to find nowdays ], and at least some government sites are now required to be that way. Color can be a great way to emphasize items IF the chroma and luminance values are carefully chosen. If not you can take away a lot of functionality. Bill - thanks for all the info here. I feel it's important for this to work for users with all kinds of vision differences, so can you confirm (or not) whether the b/w version (rc_fancy=YES, but rc_fancy_color=NO) looks readable to you? (please use patch 7) Thanks! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
Coleman Kane wrote: On 4/20/06, *Eric Anderson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: David Barbero wrote: --- snip --- Yep, that's a bug. I think it's fixed in v7, available here: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7 along with a few other suggestions from others. Another one of the failures that I have seen is that with this patch they show all the services, they are or not formed to start, I believe that single they would have to appear the services that are formed to start and not all those that can start. If the service is run on bootup, it shows it. It was still being run before, there was just no output previously. It would be pretty easy to have an option to not print these, maybe an rc_fancy_verbose option. Is this desirable to most? In addition the services that are not formed to start appear like [ OK ], in the case of appearing these, I believe that they would have to leave with another denomination that is not [ OK ]. I'm not sure what you mean here. Can you give me an example? Another failure that I have seen is that when leaving the message syslogd this sample failure, but this service starts without problems, but shows it as if it gave failure... My syslogd looks clean, and doesn't give a false failure. I'm not sure how to look into this - can you confirm that it truly is passing, but giving the wrong message, or is it that the rc subsystem thinks it's failing but appears to work ok? In principle this is what I have seen at first sight on the patch. Thanks for all the feedback and testing! Eric I have modified the patch as follows: Made a bunch of the settings tunable by the user (message text and field widths). It is availalbe at http://www.cokane.org/files/rc_fancy-cokane2.patch This looks good. I only wonder about two things now: - Should we also have a line for the actual colors used too? Or is that going too crazy? - Does it meet style(9)? I'm wondering about line lengths now. Other than that, do we have general consensus that these do what they claim? Any outstanding issues that haven't been addressed? Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
On 4/20/06, Eric Anderson [EMAIL PROTECTED] wrote: Coleman Kane wrote: I have modified the patch as follows: Made a bunch of the settings tunable by the user (message text and field widths). It is availalbe at http://www.cokane.org/files/rc_fancy-cokane2.patch This looks good. I only wonder about two things now: - Should we also have a line for the actual colors used too? Or is that going too crazy? Definately... I think having the ability to specify colorsets as profiles will be a must-have. Read the LSCOLORS description in ls(1). - Does it meet style(9)? I'm wondering about line lengths now. One unfortunate thing about /bin/sh: [from the sh(1) manpage] Only one of the -e and -n options may be specified. This means that we may not be able to use the -n to chain multiple echos on one line... Other than that, do we have general consensus that these do what they claim? Any outstanding issues that haven't been addressed? Eric --coleman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
On 4/20/06, Eric Anderson [EMAIL PROTECTED] wrote: David Barbero wrote: --- snip --- Yep, that's a bug. I think it's fixed in v7, available here: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7 along with a few other suggestions from others. Another one of the failures that I have seen is that with this patch they show all the services, they are or not formed to start, I believe that single they would have to appear the services that are formed to start and not all those that can start. If the service is run on bootup, it shows it. It was still being run before, there was just no output previously. It would be pretty easy to have an option to not print these, maybe an rc_fancy_verbose option. Is this desirable to most? In addition the services that are not formed to start appear like [ OK ], in the case of appearing these, I believe that they would have to leave with another denomination that is not [ OK ]. I'm not sure what you mean here. Can you give me an example? Another failure that I have seen is that when leaving the message syslogd this sample failure, but this service starts without problems, but shows it as if it gave failure... My syslogd looks clean, and doesn't give a false failure. I'm not sure how to look into this - can you confirm that it truly is passing, but giving the wrong message, or is it that the rc subsystem thinks it's failing but appears to work ok? In principle this is what I have seen at first sight on the patch. Thanks for all the feedback and testing! Eric I have modified the patch as follows: Made a bunch of the settings tunable by the user (message text and field widths). It is availalbe at http://www.cokane.org/files/rc_fancy-cokane2.patch -- Coleman Kane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Tue, 2006-Apr-18 18:26:33 -0400, Coleman Kane wrote: 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. I have a number of genuine DEC VT510 terminals that I could probably give away to anyone who wants to disprove this :-) -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Tue, 2006-Apr-18 15:02:27 -0500, Eric Anderson wrote:
Peter Jeremy wrote:
+padding=
+paddingsize=$(($columns - 15 - $2 - $namesize))
+until [ 0 = ${paddingsize} ]; do
+padding= $padding
+paddingsize=$(($paddingsize - 1))
+done
This particular block of code appears unnecessary (since $padding is
unused).
I must be missing something, because I'm pretty sure it's used.. What
did I miss?
Actually, I had a closer look and I was wrong, sorry. I missed the
'[ $2 = 0 ]' test. The code might be more legible (and is definitely
more efficient) if the above code was moved into the else clause for
that test.
Also '[ $2 = 0 ]' should probably be written as '[ 0$2 -eq 0 ]', or
similar, so that it doesn't blow up if there is no $2.
--
Peter Jeremy
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: Message: 20 Date: Tue, 18 Apr 2006 15:07:31 -0700 From: Darren Pilgrim [EMAIL PROTECTED] Eric Anderson wrote: If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. Let me add to that. About 10% of the male population has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. That's one of the reasons why fire-trucks in this area are lime-green, as red trucks disappear into the blackness at night. If you add color make sure it is a user selectable option and not turned on by default. IMO everything you need to admin a system needs to be able to run on something as lowly as a pure serial terminal as the above poster notes. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Bill Vermillion wrote: Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: Message: 20 Date: Tue, 18 Apr 2006 15:07:31 -0700 From: Darren Pilgrim [EMAIL PROTECTED] Eric Anderson wrote: If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. Let me add to that. About 10% of the male population has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. That's one of the reasons why fire-trucks in this area are lime-green, as red trucks disappear into the blackness at night. If you add color make sure it is a user selectable option and not turned on by default. IMO everything you need to admin a system needs to be able to run on something as lowly as a pure serial terminal as the above poster notes. Ok. So I've received mass amounts of mail regarding this, and most of it has been positively in favor of having the option to enable the rc_fancy, and then an additional option to turn on coloring, with the default to be non-colored but still rc_fancy=YES which should work ok on serial and other terminals (it did for me). I completely agree about all the coloring comments, and terminal issues. I personally think it should be an available option, easily enabled or disabled at will. I've put up an updated version, with many changes. This version includes optional coloring (with rc_fancy_color=YES in rc.conf), better checking, cleaner coding, and no loops. This version is *much* more refined than the others - thanks for all the hints everyone! http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5 Also - could I check the kern.console sysctl and decide if it's starting using a console or not, and then automatically override the rc.conf settings if it is booting to a serial console? Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Eric Anderson wrote: Bill Vermillion wrote: Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: Message: 20 Date: Tue, 18 Apr 2006 15:07:31 -0700 From: Darren Pilgrim [EMAIL PROTECTED] Eric Anderson wrote: If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. Let me add to that. About 10% of the male population has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. That's one of the reasons why fire-trucks in this area are lime-green, as red trucks disappear into the blackness at night. If you add color make sure it is a user selectable option and not turned on by default. IMO everything you need to admin a system needs to be able to run on something as lowly as a pure serial terminal as the above poster notes. Ok. So I've received mass amounts of mail regarding this, and most of it has been positively in favor of having the option to enable the rc_fancy, and then an additional option to turn on coloring, with the default to be non-colored but still rc_fancy=YES which should work ok on serial and other terminals (it did for me). I completely agree about all the coloring comments, and terminal issues. I personally think it should be an available option, easily enabled or disabled at will. I've put up an updated version, with many changes. This version includes optional coloring (with rc_fancy_color=YES in rc.conf), better checking, cleaner coding, and no loops. This version is *much* more refined than the others - thanks for all the hints everyone! http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5 Looks like this version does something strange - from an xterm, the spacing is correct, but from console, it doesn't do anything with the \033[71G in the echo. I've played with term types, but can't seem to make it act the same under console as it does in an xterm. Anyone know the issue? Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC - v6
Eric Anderson wrote: Eric Anderson wrote: Bill Vermillion wrote: Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: Message: 20 Date: Tue, 18 Apr 2006 15:07:31 -0700 From: Darren Pilgrim [EMAIL PROTECTED] Eric Anderson wrote: If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. Let me add to that. About 10% of the male population has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. That's one of the reasons why fire-trucks in this area are lime-green, as red trucks disappear into the blackness at night. If you add color make sure it is a user selectable option and not turned on by default. IMO everything you need to admin a system needs to be able to run on something as lowly as a pure serial terminal as the above poster notes. Ok. So I've received mass amounts of mail regarding this, and most of it has been positively in favor of having the option to enable the rc_fancy, and then an additional option to turn on coloring, with the default to be non-colored but still rc_fancy=YES which should work ok on serial and other terminals (it did for me). I completely agree about all the coloring comments, and terminal issues. I personally think it should be an available option, easily enabled or disabled at will. I've put up an updated version, with many changes. This version includes optional coloring (with rc_fancy_color=YES in rc.conf), better checking, cleaner coding, and no loops. This version is *much* more refined than the others - thanks for all the hints everyone! http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5 Looks like this version does something strange - from an xterm, the spacing is correct, but from console, it doesn't do anything with the \033[71G in the echo. I've played with term types, but can't seem to make it act the same under console as it does in an xterm. Anyone know the issue? Thanks to Rick Petty for pointing me in the right direction (man page!), here's the latest, and I think solid patch (for RELENG-6): http://www.googlebit.com/freebsd/patches/rc_fancy.patch-6 Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On 4/19/06, Eric Anderson [EMAIL PROTECTED] wrote: Eric Anderson wrote: Bill Vermillion wrote: Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: Message: 20 Date: Tue, 18 Apr 2006 15:07:31 -0700 From: Darren Pilgrim [EMAIL PROTECTED] Eric Anderson wrote: If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. This point can be debated... read some literature from Edward Tufte... colors are a good way to cram more information into a space without actually compromising the capacity of that space. Let me add to that. About 10% of the male population has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. That's one of the reasons why fire-trucks in this area are lime-green, as red trucks disappear into the blackness at night. If you add color make sure it is a user selectable option and not turned on by default. IMO everything you need to admin a system needs to be able to run on something as lowly as a pure serial terminal as the above poster notes. Ok. So I've received mass amounts of mail regarding this, and most of it has been positively in favor of having the option to enable the rc_fancy, and then an additional option to turn on coloring, with the default to be non-colored but still rc_fancy=YES which should work ok on serial and other terminals (it did for me). I completely agree about all the coloring comments, and terminal issues. I personally think it should be an available option, easily enabled or disabled at will. I've put up an updated version, with many changes. This version includes optional coloring (with rc_fancy_color=YES in rc.conf), better checking, cleaner coding, and no loops. This version is *much* more refined than the others - thanks for all the hints everyone! http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5 Looks like this version does something strange - from an xterm, the spacing is correct, but from console, it doesn't do anything with the \033[71G in the echo. I've played with term types, but can't seem to make it act the same under console as it does in an xterm. Anyone know the issue? Eric Try: \033[71C Hmm... I see 71 spaces how about we just stick to the padding... I would like to not go overboard by using a lot of other escape sequences that have less experience out in the wild (and thus, less testing and are more likely to fail). Colors and attributes seem to be the overwhelming majority of reasons using the escape codes. Cursor control and other macros are probably less common. You can change the \033 --- \e if you like, or leave it. We should settle ourselves on a standard for this however... maybe make a /etc/rc.fancy that has macros for all of this stuff. Also, I second the comment regarding making this tunable. Of course the console will default to 7-bit ASCII text, printable characters only (or whatever charset you have chosen). One of the big reasons for Linux's prettification of its console, and support for fb console, is that there are a good number of Linux installations out there where the primary application is desktop and workstation. As for me, I primarily run FreeBSD as a desktop/workstation and therefore enjoy the opportunity to make the console more readable. We discuss the bare necessities for servers and what's necessary for administering a server, I think that my (and others') workstation needs and desires are important to the development of FreeBSD too. We should be embracing the adoption of the platform for workstation and desktop use as well, and actually take the advice of those users to heart. I would hope that if this featureset can get into the base system, then tunables get into the Console section of sysinstall (allowing this to be turned on at install time) and that the screenshots generated from that entice people who like things like colorful error messages to gain more interest in the platform (and yes, FreeBSD is ugly is a common crtique I have heard). Maybe that will finally push some others to get FB console working (KGI?)... My point is that we should let
Re: [PATCH] Fancy rc startup style RFC - v6
On Wednesday 19 April 2006 16:39, Eric Anderson wrote: Eric Anderson wrote: Eric Anderson wrote: Bill Vermillion wrote: Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: Message: 20 Date: Tue, 18 Apr 2006 15:07:31 -0700 From: Darren Pilgrim [EMAIL PROTECTED] Eric Anderson wrote: If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. Let me add to that. About 10% of the male population has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. That's one of the reasons why fire-trucks in this area are lime-green, as red trucks disappear into the blackness at night. If you add color make sure it is a user selectable option and not turned on by default. IMO everything you need to admin a system needs to be able to run on something as lowly as a pure serial terminal as the above poster notes. Ok. So I've received mass amounts of mail regarding this, and most of it has been positively in favor of having the option to enable the rc_fancy, and then an additional option to turn on coloring, with the default to be non-colored but still rc_fancy=YES which should work ok on serial and other terminals (it did for me). I completely agree about all the coloring comments, and terminal issues. I personally think it should be an available option, easily enabled or disabled at will. I've put up an updated version, with many changes. This version includes optional coloring (with rc_fancy_color=YES in rc.conf), better checking, cleaner coding, and no loops. This version is *much* more refined than the others - thanks for all the hints everyone! http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5 Looks like this version does something strange - from an xterm, the spacing is correct, but from console, it doesn't do anything with the \033[71G in the echo. I've played with term types, but can't seem to make it act the same under console as it does in an xterm. Anyone know the issue? Thanks to Rick Petty for pointing me in the right direction (man page!), here's the latest, and I think solid patch (for RELENG-6): http://www.googlebit.com/freebsd/patches/rc_fancy.patch-6 Eric Looks really good to me :) Regards, Pieter de Goeje ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
In [EMAIL PROTECTED], Coleman Kane [EMAIL PROTECTED] typed: On 4/19/06, Eric Anderson [EMAIL PROTECTED] wrote: Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. This point can be debated... Only the last point, and only because it involves a quantity that's very difficult to measure. read some literature from Edward Tufte... I've read Tufte. I've gotten him to sign my copy of some of his books at his seminars. I wish (vehemently!) that more web authors would read Tufte. colors are a good way to cram more information into a space without actually compromising the capacity of that space. True, but that's not his point. His point is that the colors aren't always visible (another thing I wish more web authors were aware of). The text layout and status messages should work well in environments where the colors aren't visible, because there are times when that's the kind of environment they'll be in. That said, colors can make checking for exceptions much easier - if you can see them. So I don't have any problem with adding colors. However, they should be off by default (at least initially), and the messages and layout should be tested that way until they work well without colors. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On 4/19/06, Mike Meyer [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], Coleman Kane [EMAIL PROTECTED] typed: On 4/19/06, Eric Anderson [EMAIL PROTECTED] wrote: Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. This point can be debated... Only the last point, and only because it involves a quantity that's very difficult to measure. read some literature from Edward Tufte... I've read Tufte. I've gotten him to sign my copy of some of his books at his seminars. I wish (vehemently!) that more web authors would read Tufte. colors are a good way to cram more information into a space without actually compromising the capacity of that space. True, but that's not his point. His point is that the colors aren't always visible (another thing I wish more web authors were aware of). The text layout and status messages should work well in environments where the colors aren't visible, because there are times when that's the kind of environment they'll be in. That said, colors can make checking for exceptions much easier - if you can see them. So I don't have any problem with adding colors. However, they should be off by default (at least initially), and the messages and layout should be tested that way until they work well without colors. I want to make a nicely configurable console message system that includes colors and formatting settable by the user (with a few sane defaults). I am familiar with the trouble of using red for errors (if you've ever seen red on a B+W TV you'll know too). How about we all discuss good choices for default colors? And, I think I am going to assemble some sort of framework sh script for this after all. Either it gets ammended to rc.subr, or it sits alone as its own dedicated module (that can be sourced by rc.*). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
In [EMAIL PROTECTED], Coleman Kane [EMAIL PROTECTED] typed: On 4/19/06, Mike Meyer [EMAIL PROTECTED] wrote: How about we all discuss good choices for default colors? Depends on the goal: do you want the default to work for everyone, or do you want the default to be prettier and/or better for most people but absolutely suck for a few? I like the former. Which means the defaults need to be black and white. Given a sufficiently flexible system for picking colors, we can use bold/underline/reversed as colors. That might work well under that constraint. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Wed, Apr 19, 2006 at 05:57:21PM +1000, Peter Jeremy wrote:
On Tue, 2006-Apr-18 15:02:27 -0500, Eric Anderson wrote:
Peter Jeremy wrote:
+ padding=
+ paddingsize=$(($columns - 15 - $2 - $namesize))
+ until [ 0 = ${paddingsize} ]; do
+ padding= $padding
+ paddingsize=$(($paddingsize - 1))
+ done
This particular block of code appears unnecessary (since $padding is
unused).
I must be missing something, because I'm pretty sure it's used.. What
did I miss?
Actually, I had a closer look and I was wrong, sorry. I missed the
'[ $2 = 0 ]' test. The code might be more legible (and is definitely
more efficient) if the above code was moved into the else clause for
that test.
Also '[ $2 = 0 ]' should probably be written as '[ 0$2 -eq 0 ]', or
similar, so that it doesn't blow up if there is no $2.
Or better use ${2:-0} if that's what you mean. The idiom of
prepending stuff to a variable in a string to deal with the unassigned
variables has always seemed to me like it was a hold over from some
truly ancent shell without modern features. The '[ x$var = x ]'
idiom is even worse. Test has only had -z and -n for a decade or two...
-- Brooks
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgpkcS02eh9o4.pgp
Description: PGP signature
Re: Re: [PATCH] Fancy rc startup style RFC
From: Bill Vermillion [EMAIL PROTECTED] has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. The problem with Linux colors is that they have been designed to be used on the white background which is the xterm's default (and which I hate as it's tough on my eyes). Since I usually use the black background, I disable them too. When I have time and patience to mess around, I set the LS_COLORS and such variables to the complementary bitmasks of what they've been, and that fixes the problem with contrast on the black background. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On 4/19/06, Mike Meyer [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], Coleman Kane [EMAIL PROTECTED] typed: On 4/19/06, Mike Meyer [EMAIL PROTECTED] wrote: How about we all discuss good choices for default colors? Depends on the goal: do you want the default to work for everyone, or do you want the default to be prettier and/or better for most people but absolutely suck for a few? I was thinking perhaps of having a predefined set of templates (with the option and documentation to add your own). Perhaps implement one that creates the traffic-light style that seems to make intuitive sense to many americans (Bold Red: error, Bold Green: Success, Bold Yellow: warning/notice), and also have another perdefined one that uses a different color set. BTW, I know that blue and red are bad colors. How to the emphasized or emboldened versions of these colors match up? I like the former. Which means the defaults need to be black and white. Given a sufficiently flexible system for picking colors, we can use bold/underline/reversed as colors. That might work well under that constraint. I am merely talking about predefined color choices... of course if rc_fancy_color=NO then fancyiness will be B+W. I'd like to know if there are better choices than Red/Green/Yellow. To me Red/Green/Yellow make sense to a lot of people because of their relation to our driving system here in the states. Maybe something like Error=Yellow, Good=Blue, Warn/Notice=Green is a better choice across the board. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: [PATCH] Fancy rc startup style RFC
In [EMAIL PROTECTED], Sergey Babkin [EMAIL PROTECTED] typed: From: Bill Vermillion [EMAIL PROTECTED] has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. The problem with Linux colors is that they have been designed to be used on the white background which is the xterm's default (and which I hate as it's tough on my eyes). Since I usually use the black background, I disable them too. So where do linux's blasted ls colors come from? It prints some file type as green. Green on white is simply bad news, whether or not you have vision problems. I always have to go disable them (and some linux distros make them *hard* to disable). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: [PATCH] Fancy rc startup style RFC
Ang utong ko ay sasabog sa sarap! exclaimed Sergey Babkin while reading this message on Wed, Apr 19, 2006 at 12:18 and then responded with: From: Bill Vermillion [EMAIL PROTECTED] has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. The problem with Linux colors is that they have been designed to be used on the white background which is the xterm's default (and which I hate as it's tough on my eyes). Since I usually use the black background, I disable them too. When I have time and patience to mess around, I set the LS_COLORS and such variables to the complementary bitmasks of what they've been, and that fixes the problem with contrast on the black background. Well I run in 80x24 text mode almost all the time, and when I need some graphics/web stuff I hit the KVM and move to an XP machine. I use vidcontrol to set my screen /home/bv/.profile:vidcontrol green black /home/bv/.profile:vidcontrol -b blue /home/bv/.profile:vidcontrol -c blink That gives me green on black, with a blue border defining the edge of the screen. With my vision it works very well. I got to something with white on black and I find it too bright to use, except on dying monitors :-) [I've had some clients with really bad server monitors - typically SCO. On those I'd set the white to bright white to make them readable] Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Bill Vermillion wrote: Ang utong ko ay sasabog sa sarap! exclaimed Sergey Babkin while reading this message on Wed, Apr 19, 2006 at 12:18 and then responded with: From: Bill Vermillion [EMAIL PROTECTED] has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. The problem with Linux colors is that they have been designed to be used on the white background which is the xterm's default (and which I hate as it's tough on my eyes). Since I usually use the black background, I disable them too. When I have time and patience to mess around, I set the LS_COLORS and such variables to the complementary bitmasks of what they've been, and that fixes the problem with contrast on the black background. Well I run in 80x24 text mode almost all the time, and when I need some graphics/web stuff I hit the KVM and move to an XP machine. I use vidcontrol to set my screen /home/bv/.profile:vidcontrol green black /home/bv/.profile:vidcontrol -b blue /home/bv/.profile:vidcontrol -c blink That gives me green on black, with a blue border defining the edge of the screen. With my vision it works very well. I got to something with white on black and I find it too bright to use, except on dying monitors :-) [I've had some clients with really bad server monitors - typically SCO. On those I'd set the white to bright white to make them readable] Ok - first, let me remind everyone that this is for startup/shutdown of scripts and such, not for ls and other things. I'd also like to remind everyone that the default for the whole thing can be OFF, so you won't even know the option exists if you don't want to know about it. If it is on, then the default is b/w like the current setup is, and currently no information is suppressed so there is no loss of helpful information on boot, only additional information (OK, FAILED, SKIP, etc). If someone doesn't like the colors, doesn't like the 'fancy' bootup, then they merely have to do nothing at all. This is a similar feature as rc_info is, and there's no issue there, because it's off by default. Same with the color daemon at the boot menu. I think it should be off by default, until enough people demand it on (if that happens at all), and then it should be b/w by default, with the option to make it color. My main goal was to implement this with as little reworking of the current system as possible, yet still reap rewards of easy readability when the system boots. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Apr 19, 2006, at 2:07 PM, Eric Anderson wrote: Ok - first, let me remind everyone that this is for startup/ shutdown of scripts and such, not for ls and other things. I'd also like to remind everyone that the default for the whole thing can be OFF, so you won't even know the option exists if you don't want to know about it. If it is on, then the default is b/w like the current setup is, and currently no information is suppressed so there is no loss of helpful information on boot, only additional information (OK, FAILED, SKIP, etc). If someone doesn't like the colors, doesn't like the 'fancy' bootup, then they merely have to do nothing at all. This is a similar feature as rc_info is, and there's no issue there, because it's off by default. Same with the color daemon at the boot menu. I think it should be off by default, until enough people demand it on (if that happens at all), and then it should be b/w by default, with the option to make it color. My main goal was to implement this with as little reworking of the current system as possible, yet still reap rewards of easy readability when the system boots. I hate to even suggest this, but perhaps we should add a desktop vs server option when installing freebsd. It wouldn't effect packages used, but might change a few defaults such as this new fancy startup. People using terminals and such would still get their black and white startup and everyone else would get the nice color startup. Anyone using a desktop or sys admins who have video cards in their servers and never tend to debug anything would like it. I think PC-BSD and DesktopBSD show there is a demand for FreeBSD on the desktop. It might be time we acknowledge that. Adding color doesn't minimize the power to serve. As much as I love FreeBSD, sometimes its difficult to get others to try it simply because the project is so difficult about desktop usage. People often try out a new OS on a desktop before using it on production servers. Few people just risk it like I did a few years ago. In my case, I just didn't want linux. Lucas Holt [EMAIL PROTECTED] FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory site) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Wed, Apr 19, 2006 at 10:46:09AM -0400, Coleman Kane wrote: My point is that we should let our purist values get in the way of others' enhanced experience using the system. My view is: We take the patch, as long as it doesn't interfere with the internal machinations of rc too much. There are good aesthetic and functional arguments on either side. Given the excellent work on rc to date, we have clean abstractions in rc itself, so fitting colour-aesthetics in does not have a high maintenance cost. I agree strongly with the functional arguments however and think that this stuff shouldn't be turned on by default. I think that it should be available in the base system for those who wish it. I feel that this should be both for aesthetic reasons and for promoting FreeBSD to the ultimate end, that is, to potential users, who may find it easier to relate to FreeBSD if the console messages are in colour, no matter how irrational that may seem to some! Regards, BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Thu, Apr 20, 2006 at 12:43:43AM +0100, Bruce M Simpson wrote: On Wed, Apr 19, 2006 at 10:46:09AM -0400, Coleman Kane wrote: My point is that we should let our purist values get in the way of others' enhanced experience using the system. My view is: We take the patch, as long as it doesn't interfere with the internal machinations of rc too much. There are good aesthetic and functional arguments on either side. Given the excellent work on rc to date, we have clean abstractions in rc itself, so fitting colour-aesthetics in does not have a high maintenance cost. I agree with this line of reasoning. So long as things are kept modular and don't cause maintance headaches when working on the internals I'd like to see this sort of work encouraged and encorporated into the tree. While there's something to be said for console output that shows everthing there's also something to be said for console output that only shows whats actually important. Giving people room to explore other options could yeild something much better than what we currently have. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpuR810TJzAt.pgp Description: PGP signature
Re: [PATCH] Fancy rc startup style RFC
On 2006-04-19, Brooks Davis wrote: On Thu, Apr 20, 2006 at 12:43:43AM +0100, Bruce M Simpson wrote: On Wed, Apr 19, 2006 at 10:46:09AM -0400, Coleman Kane wrote: My point is that we should let our purist values get in the way of others' enhanced experience using the system. My view is: We take the patch, as long as it doesn't interfere with the internal machinations of rc too much. There are good aesthetic and functional arguments on either side. Given the excellent work on rc to date, we have clean abstractions in rc itself, so fitting colour-aesthetics in does not have a high maintenance cost. I agree with this line of reasoning. So long as things are kept modular and don't cause maintance headaches when working on the internals I'd like to see this sort of work encouraged and encorporated into the tree. While there's something to be said for console output that shows everthing there's also something to be said for console output that only shows whats actually important. Giving people room to explore other options could yeild something much better than what we currently have. Perhaps the default setup, while having all the pretty stuff turned off, could include one or two lines as close to the bottom of the output as possible that simply listed the new options so those who wanted them would know how to get the features and the rest of us would be gently reminded of what we were missing without damaging the output that we prefer. Greg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: [PATCH] Fancy rc startup style RFC
They all laughed on Wed, Apr 19, 2006 at 13:32 when Mike Meyer said: In [EMAIL PROTECTED], Sergey Babkin [EMAIL PROTECTED] typed: From: Bill Vermillion [EMAIL PROTECTED] has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. The problem with Linux colors is that they have been designed to be used on the white background which is the xterm's default (and which I hate as it's tough on my eyes). Since I usually use the black background, I disable them too. So where do linux's blasted ls colors come from? It prints some file type as green. Green on white is simply bad news, whether or not you have vision problems. I always have to go disable them (and some linux distros make them *hard* to disable). I just checked in on one Linux machine I admin - SuSE 9.2 - and the colors are set with the variable LS_OPTIONS. I've set LS_OPTIONS to '-N --color=none -T 0' And looking at the .bashrc there is also a test for the binary dircolors, and then looks for user files .dir_colors I also notice that as shipped the .bashrc has a comment line that says If LS_COLROS is set but empty the terminal has no colors. It is spelled COLROS not COLORS - but that's just cosmetic and sloppy. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [PATCH] Fancy rc startup style RFC
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brooks Davis Sent: Thursday, 20 April 2006 9:58 AM To: Bruce M Simpson; [EMAIL PROTECTED]; Eric Anderson; freebsd-hackers@freebsd.org Subject: Re: [PATCH] Fancy rc startup style RFC On Thu, Apr 20, 2006 at 12:43:43AM +0100, Bruce M Simpson wrote: On Wed, Apr 19, 2006 at 10:46:09AM -0400, Coleman Kane wrote: My point is that we should let our purist values get in the way of others' enhanced experience using the system. My view is: We take the patch, as long as it doesn't interfere with the internal machinations of rc too much. There are good aesthetic and functional arguments on either side. Given the excellent work on rc to date, we have clean abstractions in rc itself, so fitting colour-aesthetics in does not have a high maintenance cost. I agree with this line of reasoning. So long as things are kept modular and don't cause maintance headaches when working on the internals I'd like to see this sort of work encouraged and encorporated into the tree. While there's something to be said for console output that shows everthing there's also something to be said for console output that only shows whats actually important. Giving people room to explore other options could yeild something much better than what we currently have. -- Brooks My 0.02c worth - one of the Unix precepts for command line tools is silence = no error This is to consciously aid and abet the pipelining of programs Which is a major strength of Unix.. From The Art of Unix Programming http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2877684 Also http://www.catb.org/~esr/writings/taoup/html/ch11s01.html The whole site is a good read. And Albert speaks well too (see sig below) mjt -- Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein --- The information transmitted in this e-mail is for the exclusive use of the intended addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. E-mails may not be secure, may contain computer viruses and may be corrupted in transmission. Please carefully check this e-mail (and any attachment) accordingly. No warranties are given and no liability is accepted for any loss or damage caused by such matters. --- ***This Email has been scanned for Viruses by MailMarshal.*** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] Fancy rc startup style RFC
Hi everyone! I've made a patch to /etc/rc.subr that makes the startup/shutdown rc scripting look similar to other OS's (many different linux distros, HP-UX, etc), but without color. The patch shouldn't break anything, and is only enabled if you have this in your /etc/rc.conf: rc_fancy=YES Several of the /etc/rc.d/* scripts send output to stdout, so that could be cleaned up a bit if needed, but for now I tried to keep the patch as minimal as possible. This is still a first pass, so please give feedback. The patch can be grabbed from here: http://www.googlebit.com/freebsd/patches/rc_fancy.patch Enjoy! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Hi, * Thus spake Eric Anderson ([EMAIL PROTECTED]): I've made a patch to /etc/rc.subr that makes the startup/shutdown rc scripting look similar to other OS's (many different linux distros, HP-UX, etc), but without color. The patch shouldn't break anything, and is only enabled if you have this in your /etc/rc.conf: rc_fancy=YES Several of the /etc/rc.d/* scripts send output to stdout, so that could be cleaned up a bit if needed, but for now I tried to keep the patch as minimal as possible. This is still a first pass, so please give feedback. A short try on my notebook shows some errors. I don't want to let this email getting too big, so I put the dmesg -a output online. http://generic.0xfce3.net/dmesg-fancy.txt BTW, the patch applied cleanly. best regards, Gordon -- Gordon Bergling GBergling at 0xfce3.net http://www.0xFCE3.net/ PGP Fingerprint: 7732 9BB1 5013 AE8B E42C 28E0 93B9 D32B C76F 02A0 RIPE-HDL: MDTP-RIPE Minimal Electronic Music ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Gordon Bergling wrote: Hi, * Thus spake Eric Anderson ([EMAIL PROTECTED]): I've made a patch to /etc/rc.subr that makes the startup/shutdown rc scripting look similar to other OS's (many different linux distros, HP-UX, etc), but without color. The patch shouldn't break anything, and is only enabled if you have this in your /etc/rc.conf: rc_fancy=YES Several of the /etc/rc.d/* scripts send output to stdout, so that could be cleaned up a bit if needed, but for now I tried to keep the patch as minimal as possible. This is still a first pass, so please give feedback. A short try on my notebook shows some errors. I don't want to let this email getting too big, so I put the dmesg -a output online. http://generic.0xfce3.net/dmesg-fancy.txt BTW, the patch applied cleanly. Thanks for the feedback! Looks like I made an erroneous assumption that the wc, expr, and printf tools found in /usr/bin and /bin would be available through boot, but that isn't the case on systems with those file systems separate from /. I'm not sure how to resolve some of these issues, since I don't know of a way to do those functions in csh without them. I'm open to suggestions here from anyone. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
In message: [EMAIL PROTECTED] Eric Anderson [EMAIL PROTECTED] writes: : Gordon Bergling wrote: : Hi, : : * Thus spake Eric Anderson ([EMAIL PROTECTED]): : I've made a patch to /etc/rc.subr that makes the startup/shutdown rc : scripting look similar to other OS's (many different linux distros, : HP-UX, etc), but without color. : : The patch shouldn't break anything, and is only enabled if you have this : in your /etc/rc.conf: : : rc_fancy=YES : : Several of the /etc/rc.d/* scripts send output to stdout, so that could : be cleaned up a bit if needed, but for now I tried to keep the patch as : minimal as possible. : : This is still a first pass, so please give feedback. : : A short try on my notebook shows some errors. : I don't want to let this email getting too big, so I put the dmesg -a : output online. http://generic.0xfce3.net/dmesg-fancy.txt : : BTW, the patch applied cleanly. : : : Thanks for the feedback! Looks like I made an erroneous assumption that : the wc, expr, and printf tools found in /usr/bin and /bin would be : available through boot, but that isn't the case on systems with those : file systems separate from /. I'm not sure how to resolve some of these : issues, since I don't know of a way to do those functions in csh without : them. I'm open to suggestions here from anyone. /bin and /sbin are available through the entire boot. Only things in /usr are suspect because /usr gets mounted early in the boot process, but not as early as /. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On 4/18/06, M. Warner Losh [EMAIL PROTECTED] wrote:
In message: [EMAIL PROTECTED]
Eric Anderson [EMAIL PROTECTED] writes:
: Gordon Bergling wrote:
: Hi,
:
: * Thus spake Eric Anderson ([EMAIL PROTECTED]):
: I've made a patch to /etc/rc.subr that makes the startup/shutdown rc
: scripting look similar to other OS's (many different linux distros,
: HP-UX, etc), but without color.
:
: The patch shouldn't break anything, and is only enabled if you have
this
: in your /etc/rc.conf:
:
: rc_fancy=YES
:
: Several of the /etc/rc.d/* scripts send output to stdout, so that
could
: be cleaned up a bit if needed, but for now I tried to keep the patch
as
: minimal as possible.
:
: This is still a first pass, so please give feedback.
:
: A short try on my notebook shows some errors.
: I don't want to let this email getting too big, so I put the dmesg
-a
: output online. http://generic.0xfce3.net/dmesg-fancy.txt
:
: BTW, the patch applied cleanly.
:
:
: Thanks for the feedback! Looks like I made an erroneous assumption that
: the wc, expr, and printf tools found in /usr/bin and /bin would be
: available through boot, but that isn't the case on systems with those
: file systems separate from /. I'm not sure how to resolve some of these
: issues, since I don't know of a way to do those functions in csh without
: them. I'm open to suggestions here from anyone.
/bin and /sbin are available through the entire boot. Only things in
/usr are suspect because /usr gets mounted early in the boot process,
but not as early as /.
Warner
Nice work!
I too noticed the dependence upon wc, printf, expr. I went ahead and rewrote
these into equivalents in native sh. (attaching new diff).
This diff is against the latest 7-CURRENT rc.subr. I had to manually merge 3
hunks due to some differences.
--
coleman kane
--- rc.subr.orig Tue Apr 18 13:58:14 2006
+++ rc.subr Tue Apr 18 13:57:36 2006
@@ -313,12 +313,16 @@
break
fi
_list=$_nlist
- echo -n ${_prefix:-Waiting for PIDS: }$_list
+ if ! checkyesno rc_fancy; then
+ echo -n ${_prefix:-Waiting for PIDS: }$_list
+ fi
_prefix=,
sleep 2
done
if [ -n $_prefix ]; then
- echo .
+ if ! checkyesno rc_fancy; then
+ echo .
+ fi
fi
}
@@ -564,12 +568,14 @@
# if the precmd failed and force
# isn't set, exit
#
+ rcargsize=`echo $rc_arg`
+ rcargsize=${#rcargsize}
if [ -n $_precmd ]; then
debug run_rc_command: evaluating ${_precmd}().
eval $_precmd $rc_extra_args
_return=$?
[ $_return -ne 0 ] [ -z $rc_force ]
-return 1
+(echo_fancy FAILED `expr 10 + $rcargsize - 1`) return 1
fi
if [ -n $_cmd ]; then
@@ -577,7 +583,7 @@
eval $_cmd $rc_extra_args
_return=$?
[ $_return -ne 0 ] [ -z $rc_force ]
-return 1
+(echo_fancy FAILED `expr 10 + $rcargsize - 1`) return 1
fi
if [ -n $_postcmd ]; then
@@ -585,6 +591,7 @@
eval $_postcmd $rc_extra_args
_return=$?
fi
+ echo_fancy OK 0
return $_return
fi
@@ -600,13 +607,16 @@
;;
start)
+ echo -n Starting ${name}
if [ -z $rc_fast -a -n $rc_pid ]; then
+ echo_fancy SKIP 9
echo 12 ${name} already running? (pid=$rc_pid).
return 1
fi
if [ ! -x ${_chroot}${command} ]; then
info run_rc_command: cannot run ($command).
+ echo_fancy ERROR 9
return 1
fi
@@ -617,6 +627,7 @@
if ! checkyesno $_f; then
warn \$${_f} is not enabled.
if [ -z $rc_force ]; then
+ echo_fancy ERROR 9
return 1
fi
fi
@@ -625,6 +636,7 @@
if [ ! -d ${_f}/. ]; then
warn ${_f} is not a directory.
if [ -z $rc_force ]; then
+ echo_fancy ERROR 9
return 1
fi
fi
@@ -633,6 +645,7 @@
if [ ! -r ${_f} ]; then
warn ${_f} is not readable.
if [ -z $rc_force ]; then
+ echo_fancy ERROR 9
return 1
fi
fi
@@ -646,12 +659,11 @@
eval $_precmd
_return=$?
[ $_return -ne 0 ] [ -z $rc_force ]
-return 1
+(echo_fancy ERROR 9) return 1
fi
# setup the command to run, and run it
#
- echo Starting ${name}.
if [ -n $_chroot ]; then
_doit=\
${_nice:+nice -n $_nice }\
@@ -673,7 +685,7 @@
debug run_rc_command: _doit: $_doit
eval $_doit
_return=$?
- [ $_return -ne 0 ] [ -z $rc_force ] return 1
+ [ $_return -ne 0 ] [ -z $rc_force ] (echo_fancy FAILED 9) return 1
# finally, run postcmd
#
@@ -681,15 +693,19 @@
debug run_rc_command: evaluating ${_postcmd}().
eval $_postcmd
fi
+ echo_fancy OK 9
;;
stop)
+ echo -n Stopping ${name}
if [ -z $rc_pid ]; then
[ -n $rc_fast ] return 0
if [ -n $pidfile ]; then
+ echo_fancy SKIP 9
echo 12 \
${name} not running? (check $pidfile).
else
+ echo_fancy SKIP 9
echo 12 ${name} not running?
fi
Re: [PATCH] Fancy rc startup style RFC
On 4/18/06, Coleman Kane [EMAIL PROTECTED] wrote: On 4/18/06, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Eric Anderson [EMAIL PROTECTED] writes: : : Thanks for the feedback! Looks like I made an erroneous assumption that : the wc, expr, and printf tools found in /usr/bin and /bin would be : available through boot, but that isn't the case on systems with those : file systems separate from /. I'm not sure how to resolve some of these : issues, since I don't know of a way to do those functions in csh without : them. I'm open to suggestions here from anyone. /bin and /sbin are available through the entire boot. Only things in /usr are suspect because /usr gets mounted early in the boot process, but not as early as /. Warner Nice work! I too noticed the dependence upon wc, printf, expr. I went ahead and rewrote these into equivalents in native sh. (attaching new diff). This diff is against the latest 7-CURRENT rc.subr. I had to manually merge 3 hunks due to some differences. -- coleman kane I did some ugly-looking loops to build the space-padding expansion. Does anybody know of a better, more elegant way to accomplish the same thing with sh (and/or stuff in /bin,/sbin)? -- coleman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On 4/18/06, Coleman Kane [EMAIL PROTECTED] wrote: On 4/18/06, M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Eric Anderson [EMAIL PROTECTED] writes: : Gordon Bergling wrote: : Hi, : : * Thus spake Eric Anderson ([EMAIL PROTECTED]): : I've made a patch to /etc/rc.subr that makes the startup/shutdown rc : scripting look similar to other OS's (many different linux distros, : HP-UX, etc), but without color. : : The patch shouldn't break anything, and is only enabled if you have this : in your /etc/rc.conf: : : rc_fancy=YES : : Several of the /etc/rc.d/* scripts send output to stdout, so that could : be cleaned up a bit if needed, but for now I tried to keep the patch as : minimal as possible. : : This is still a first pass, so please give feedback. : : A short try on my notebook shows some errors. : I don't want to let this email getting too big, so I put the dmesg -a : output online. http://generic.0xfce3.net/dmesg-fancy.txt : : BTW, the patch applied cleanly. : : : Thanks for the feedback! Looks like I made an erroneous assumption that : the wc, expr, and printf tools found in /usr/bin and /bin would be : available through boot, but that isn't the case on systems with those : file systems separate from /. I'm not sure how to resolve some of these : issues, since I don't know of a way to do those functions in csh without : them. I'm open to suggestions here from anyone. Also, /bin/sh is used to execute rc NOT /bin/csh. So you are writing in Bourne shell and not C-Shell. -- coleman kane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Coleman Kane wrote: On 4/18/06, *M. Warner Losh* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Eric Anderson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] writes: : Gordon Bergling wrote: : Hi, : : * Thus spake Eric Anderson ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]): : I've made a patch to /etc/rc.subr that makes the startup/shutdown rc : scripting look similar to other OS's (many different linux distros, : HP-UX, etc), but without color. : : The patch shouldn't break anything, and is only enabled if you have this : in your /etc/rc.conf: : : rc_fancy=YES : : Several of the /etc/rc.d/* scripts send output to stdout, so that could : be cleaned up a bit if needed, but for now I tried to keep the patch as : minimal as possible. : : This is still a first pass, so please give feedback. : : A short try on my notebook shows some errors. : I don't want to let this email getting too big, so I put the dmesg -a : output online. http://generic.0xfce3.net/dmesg-fancy.txt : : BTW, the patch applied cleanly. : : : Thanks for the feedback! Looks like I made an erroneous assumption that : the wc, expr, and printf tools found in /usr/bin and /bin would be : available through boot, but that isn't the case on systems with those : file systems separate from /. I'm not sure how to resolve some of these : issues, since I don't know of a way to do those functions in csh without : them. I'm open to suggestions here from anyone. /bin and /sbin are available through the entire boot. Only things in /usr are suspect because /usr gets mounted early in the boot process, but not as early as /. Warner Nice work! I too noticed the dependence upon wc, printf, expr. I went ahead and rewrote these into equivalents in native sh. (attaching new diff). This diff is against the latest 7-CURRENT rc.subr. I had to manually merge 3 hunks due to some differences. Thanks!! I've put the updated version (for 6-STABLE) here: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-2 Gordon - can you give this version a try? Thanks, Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
* Thus spake Eric Anderson ([EMAIL PROTECTED]): Coleman Kane wrote: On 4/18/06, *M. Warner Losh* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Eric Anderson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] writes: : Gordon Bergling wrote: : Hi, : : * Thus spake Eric Anderson ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]): : I've made a patch to /etc/rc.subr that makes the startup/shutdown rc : scripting look similar to other OS's (many different linux distros, : HP-UX, etc), but without color. : : The patch shouldn't break anything, and is only enabled if you have this : in your /etc/rc.conf: : : rc_fancy=YES : : Several of the /etc/rc.d/* scripts send output to stdout, so that could : be cleaned up a bit if needed, but for now I tried to keep the patch as : minimal as possible. : : This is still a first pass, so please give feedback. : : A short try on my notebook shows some errors. : I don't want to let this email getting too big, so I put the dmesg -a : output online. http://generic.0xfce3.net/dmesg-fancy.txt : : BTW, the patch applied cleanly. : : : Thanks for the feedback! Looks like I made an erroneous assumption that : the wc, expr, and printf tools found in /usr/bin and /bin would be : available through boot, but that isn't the case on systems with those : file systems separate from /. I'm not sure how to resolve some of these : issues, since I don't know of a way to do those functions in csh without : them. I'm open to suggestions here from anyone. /bin and /sbin are available through the entire boot. Only things in /usr are suspect because /usr gets mounted early in the boot process, but not as early as /. Warner Nice work! I too noticed the dependence upon wc, printf, expr. I went ahead and rewrote these into equivalents in native sh. (attaching new diff). This diff is against the latest 7-CURRENT rc.subr. I had to manually merge 3 hunks due to some differences. Thanks!! I've put the updated version (for 6-STABLE) here: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-2 Gordon - can you give this version a try? Much better now. :) The [OK] Messages printed correctly. Some [failed] messages are missing a \t I think. But this should be the error of the respective scripts. Nice work so far... ;) best regards, Gordon -- Gordon Bergling GBergling at 0xfce3.net http://www.0xFCE3.net/ PGP Fingerprint: 7732 9BB1 5013 AE8B E42C 28E0 93B9 D32B C76F 02A0 RIPE-HDL: MDTP-RIPE Minimal Electronic Music ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Tue, 2006-Apr-18 14:02:07 -0400, Coleman Kane wrote:
A few comments on the shellscript:
+ rcargsize=`echo $rc_arg`
+ rcargsize=${#rcargsize}
Try rcargsize=$((${#rc_arg} + 1))
- return 1
+ (echo_fancy FAILED `expr 10 + $rcargsize
- 1`) return 1
Try echo_fancy FAILED $((10 + $rcargsize -
1)) return 1
+echo_fancy () {
...
+ namesize=`echo -n $name`
+ namesize=${#namesize}
or namesize=${#name}
+ padding=
+ paddingsize=$(($columns - 15 - $2 - $namesize))
+ until [ 0 = ${paddingsize} ]; do
+ padding= $padding
+ paddingsize=$(($paddingsize - 1))
+ done
This particular block of code appears unnecessary (since $padding is unused).
+ paddingsize=$((60 - $namesize - $rc_argsize))
+ until [ 0 = ${paddingsize} ]; do
+ padding= $padding
+ paddingsize=$(($paddingsize - 1))
+ done
For safety, the conditions should probably be [ 0 -ge ${paddingsize} ]
I don't see any alternative to the until loop. If efficiency turns out
to be a real issue then you could try doing the expansion in multiple
goes. Eg:
until [ 8 -gt ${paddingsize} ]; do
padding=$padding
paddingsize=$(($paddingsize - 8))
done
until [ 0 -ge ${paddingsize} ]; do
padding= $padding
paddingsize=$(($paddingsize - 1))
done
--
Peter Jeremy
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Peter Jeremy wrote:
On Tue, 2006-Apr-18 14:02:07 -0400, Coleman Kane wrote:
A few comments on the shellscript:
+ rcargsize=`echo $rc_arg`
+ rcargsize=${#rcargsize}
Try rcargsize=$((${#rc_arg} + 1))
- return 1
+ (echo_fancy FAILED `expr 10 + $rcargsize - 1`)
return 1
Try echo_fancy FAILED $((10 + $rcargsize - 1))
return 1
+echo_fancy () {
...
+ namesize=`echo -n $name`
+ namesize=${#namesize}
or namesize=${#name}
+ padding=
+ paddingsize=$(($columns - 15 - $2 - $namesize))
+ until [ 0 = ${paddingsize} ]; do
+ padding= $padding
+ paddingsize=$(($paddingsize - 1))
+ done
This particular block of code appears unnecessary (since $padding is unused).
I must be missing something, because I'm pretty sure it's used.. What
did I miss?
+ paddingsize=$((60 - $namesize - $rc_argsize))
+ until [ 0 = ${paddingsize} ]; do
+ padding= $padding
+ paddingsize=$(($paddingsize - 1))
+ done
For safety, the conditions should probably be [ 0 -ge ${paddingsize} ]
I don't see any alternative to the until loop. If efficiency turns out
to be a real issue then you could try doing the expansion in multiple
goes. Eg:
until [ 8 -gt ${paddingsize} ]; do
padding=$padding
paddingsize=$(($paddingsize - 8))
done
until [ 0 -ge ${paddingsize} ]; do
padding= $padding
paddingsize=$(($paddingsize - 1))
done
Thanks for the hints. I was testing the same changes to the
namesize/etc as you suggested, and it does work and is more readable and
more efficient.
I've included your suggestions and put the latest changes here:
http://www.googlebit.com/freebsd/patches/rc_fancy.patch-3
Thanks for all the feedback! Keep it coming! :)
Eric
--
Eric AndersonSr. Systems AdministratorCentaur Technology
Anything that works is better than anything that doesn't.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
* Thus spake Eric Anderson ([EMAIL PROTECTED]):
Peter Jeremy wrote:
On Tue, 2006-Apr-18 14:02:07 -0400, Coleman Kane wrote:
A few comments on the shellscript:
+ rcargsize=`echo $rc_arg`
+ rcargsize=${#rcargsize}
Try rcargsize=$((${#rc_arg} + 1))
- return 1
+ (echo_fancy FAILED `expr 10 +
$rcargsize - 1`) return 1
Try echo_fancy FAILED $((10 + $rcargsize -
1)) return 1
+echo_fancy () {
...
+ namesize=`echo -n $name`
+ namesize=${#namesize}
or namesize=${#name}
+ padding=
+ paddingsize=$(($columns - 15 - $2 - $namesize))
+ until [ 0 = ${paddingsize} ]; do
+ padding= $padding
+ paddingsize=$(($paddingsize - 1))
+ done
This particular block of code appears unnecessary (since $padding is
unused).
I must be missing something, because I'm pretty sure it's used.. What
did I miss?
+ paddingsize=$((60 - $namesize - $rc_argsize))
+ until [ 0 = ${paddingsize} ]; do
+ padding= $padding
+ paddingsize=$(($paddingsize - 1))
+ done
For safety, the conditions should probably be [ 0 -ge ${paddingsize} ]
I don't see any alternative to the until loop. If efficiency turns out
to be a real issue then you could try doing the expansion in multiple
goes. Eg:
until [ 8 -gt ${paddingsize} ]; do
padding=$padding
paddingsize=$(($paddingsize - 8))
done
until [ 0 -ge ${paddingsize} ]; do
padding= $padding
paddingsize=$(($paddingsize - 1))
done
Thanks for the hints. I was testing the same changes to the
namesize/etc as you suggested, and it does work and is more readable and
more efficient.
I've included your suggestions and put the latest changes here:
http://www.googlebit.com/freebsd/patches/rc_fancy.patch-3
Patch -3 is working good here. :)
best regards,
Gordon
PS: next try... fancy_color_rc=YES ;)
--
Gordon Bergling GBergling at 0xfce3.net http://www.0xFCE3.net/
PGP Fingerprint: 7732 9BB1 5013 AE8B E42C 28E0 93B9 D32B C76F 02A0
RIPE-HDL: MDTP-RIPE Minimal Electronic Music
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Gordon Bergling wrote:
* Thus spake Eric Anderson ([EMAIL PROTECTED]):
Peter Jeremy wrote:
On Tue, 2006-Apr-18 14:02:07 -0400, Coleman Kane wrote:
A few comments on the shellscript:
+ rcargsize=`echo $rc_arg`
+ rcargsize=${#rcargsize}
Try rcargsize=$((${#rc_arg} + 1))
- return 1
+(echo_fancy FAILED `expr 10 +
$rcargsize - 1`) return 1
Tryecho_fancy FAILED $((10 + $rcargsize -
1)) return 1
+echo_fancy () {
...
+ namesize=`echo -n $name`
+ namesize=${#namesize}
or namesize=${#name}
+ padding=
+ paddingsize=$(($columns - 15 - $2 - $namesize))
+ until [ 0 = ${paddingsize} ]; do
+ padding= $padding
+ paddingsize=$(($paddingsize - 1))
+ done
This particular block of code appears unnecessary (since $padding is
unused).
I must be missing something, because I'm pretty sure it's used.. What
did I miss?
+ paddingsize=$((60 - $namesize - $rc_argsize))
+ until [ 0 = ${paddingsize} ]; do
+ padding= $padding
+ paddingsize=$(($paddingsize - 1))
+ done
For safety, the conditions should probably be [ 0 -ge ${paddingsize} ]
I don't see any alternative to the until loop. If efficiency turns out
to be a real issue then you could try doing the expansion in multiple
goes. Eg:
until [ 8 -gt ${paddingsize} ]; do
padding=$padding
paddingsize=$(($paddingsize - 8))
done
until [ 0 -ge ${paddingsize} ]; do
padding= $padding
paddingsize=$(($paddingsize - 1))
done
Thanks for the hints. I was testing the same changes to the
namesize/etc as you suggested, and it does work and is more readable and
more efficient.
I've included your suggestions and put the latest changes here:
http://www.googlebit.com/freebsd/patches/rc_fancy.patch-3
Patch -3 is working good here. :)
best regards,
Gordon
PS: next try... fancy_color_rc=YES ;)
If I could figure out how to make sh do colors, I'd do it. :)
Thanks for testing!
Eric
--
Eric AndersonSr. Systems AdministratorCentaur Technology
Anything that works is better than anything that doesn't.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Tuesday 18 April 2006 16:35, Eric Anderson wrote:
Gordon Bergling wrote:
* Thus spake Eric Anderson ([EMAIL PROTECTED]):
Peter Jeremy wrote:
On Tue, 2006-Apr-18 14:02:07 -0400, Coleman Kane wrote:
A few comments on the shellscript:
+rcargsize=`echo $rc_arg`
+rcargsize=${#rcargsize}
Try rcargsize=$((${#rc_arg} + 1))
-return 1
+(echo_fancy FAILED `expr 10 +
$rcargsize - 1`) return 1
Try echo_fancy FAILED $((10 +
$rcargsize -
1)) return 1
+echo_fancy () {
...
+namesize=`echo -n $name`
+namesize=${#namesize}
ornamesize=${#name}
+padding=
+paddingsize=$(($columns - 15 - $2 - $namesize))
+until [ 0 = ${paddingsize} ]; do
+padding= $padding
+paddingsize=$(($paddingsize - 1))
+done
This particular block of code appears unnecessary (since
$padding is unused).
I must be missing something, because I'm pretty sure it's used..
What did I miss?
+paddingsize=$((60 - $namesize - $rc_argsize))
+until [ 0 = ${paddingsize} ]; do
+padding= $padding
+paddingsize=$(($paddingsize - 1))
+done
For safety, the conditions should probably be [ 0 -ge
${paddingsize} ] I don't see any alternative to the until loop.
If efficiency turns out to be a real issue then you could try
doing the expansion in multiple goes. Eg:
until [ 8 -gt ${paddingsize} ]; do
padding=$padding
paddingsize=$(($paddingsize - 8))
done
until [ 0 -ge ${paddingsize} ]; do
padding= $padding
paddingsize=$(($paddingsize - 1))
done
Thanks for the hints. I was testing the same changes to the
namesize/etc as you suggested, and it does work and is more
readable and more efficient.
I've included your suggestions and put the latest changes here:
http://www.googlebit.com/freebsd/patches/rc_fancy.patch-3
Patch -3 is working good here. :)
best regards,
Gordon
PS: next try... fancy_color_rc=YES ;)
If I could figure out how to make sh do colors, I'd do it. :)
Is that all? :)
#!/bin/sh
# Nico Golde nico(at)ngolde.de Homepage: http://www.ngolde.de
# Last change: Mon Feb 16 16:24:41 CET 2004
for attr in 0 1 4 5 7 ; do
echo
printf ESC[%s;Foreground;Background - \n $attr
for fore in 30 31 32 33 34 35 36 37; do
for back in 40 41 42 43 44 45 46 47; do
printf '\033[%s;%s;%sm %02s;%02s ' $attr $fore $back
$fore $back
done
printf '\n'
done
printf '\033[0m'
done
--
Anish Mistry
pgpf0bSZ3O8fs.pgp
Description: PGP signature
Re: [PATCH] Fancy rc startup style RFC
Anish Mistry wrote:
On Tuesday 18 April 2006 16:35, Eric Anderson wrote:
Gordon Bergling wrote:
* Thus spake Eric Anderson ([EMAIL PROTECTED]):
Peter Jeremy wrote:
On Tue, 2006-Apr-18 14:02:07 -0400, Coleman Kane wrote:
A few comments on the shellscript:
+ rcargsize=`echo $rc_arg`
+ rcargsize=${#rcargsize}
Try rcargsize=$((${#rc_arg} + 1))
- return 1
+ (echo_fancy FAILED `expr 10 +
$rcargsize - 1`) return 1
Try echo_fancy FAILED $((10 + $rcargsize -
1)) return 1
+echo_fancy () {
...
+ namesize=`echo -n $name`
+ namesize=${#namesize}
or namesize=${#name}
+ padding=
+ paddingsize=$(($columns - 15 - $2 - $namesize))
+ until [ 0 = ${paddingsize} ]; do
+ padding= $padding
+ paddingsize=$(($paddingsize - 1))
+ done
This particular block of code appears unnecessary (since
$padding is unused).
I must be missing something, because I'm pretty sure it's used..
What did I miss?
+ paddingsize=$((60 - $namesize - $rc_argsize))
+ until [ 0 = ${paddingsize} ]; do
+ padding= $padding
+ paddingsize=$(($paddingsize - 1))
+ done
For safety, the conditions should probably be [ 0 -ge
${paddingsize} ] I don't see any alternative to the until loop.
If efficiency turns out to be a real issue then you could try
doing the expansion in multiple goes. Eg:
until [ 8 -gt ${paddingsize} ]; do
padding=$padding
paddingsize=$(($paddingsize - 8))
done
until [ 0 -ge ${paddingsize} ]; do
padding= $padding
paddingsize=$(($paddingsize - 1))
done
Thanks for the hints. I was testing the same changes to the
namesize/etc as you suggested, and it does work and is more
readable and more efficient.
I've included your suggestions and put the latest changes here:
http://www.googlebit.com/freebsd/patches/rc_fancy.patch-3
Patch -3 is working good here. :)
best regards,
Gordon
PS: next try... fancy_color_rc=YES ;)
If I could figure out how to make sh do colors, I'd do it. :)
Is that all? :)
#!/bin/sh
# Nico Golde nico(at)ngolde.de Homepage: http://www.ngolde.de
# Last change: Mon Feb 16 16:24:41 CET 2004
for attr in 0 1 4 5 7 ; do
echo
printf ESC[%s;Foreground;Background - \n $attr
for fore in 30 31 32 33 34 35 36 37; do
for back in 40 41 42 43 44 45 46 47; do
printf '\033[%s;%s;%sm %02s;%02s ' $attr $fore $back
$fore $back
done
printf '\n'
done
printf '\033[0m'
done
But can you do it without the printf's? That's the key. We don't have
printf until later in the boot process..
Eric
--
Eric AndersonSr. Systems AdministratorCentaur Technology
Anything that works is better than anything that doesn't.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Am 18.04.2006 um 22:56 schrieb Eric Anderson: Anish Mistry wrote: If I could figure out how to make sh do colors, I'd do it. :) Is that all? :) #!/bin/sh # Nico Golde nico(at)ngolde.de Homepage: http://www.ngolde.de # Last change: Mon Feb 16 16:24:41 CET 2004 for attr in 0 1 4 5 7 ; do echo printf ESC[%s;Foreground;Background - \n $attr for fore in 30 31 32 33 34 35 36 37; do for back in 40 41 42 43 44 45 46 47; do printf '\033[%s;%s;%sm %02s;%02s ' $attr $fore $back $fore $back done printf '\n' done printf '\033[0m' done But can you do it without the printf's? That's the key. We don't have printf until later in the boot process.. echo -e is your friend, see sh(1). $ echo -e '\e[0;32;46m' gives green on cyan in my xterm. Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On Tue, Apr 18, 2006, Anish Mistry wrote: printf '\033[%s;%s;%sm %02s;%02s ' $attr $fore $back however, as stated previously in this thread: `printf is /usr/bin/printf'. embedding raw ^[s in the rc script would do, is this acceptable? -- sh pgpeAfaSh4tlK.pgp Description: PGP signature
Re: [PATCH] Fancy rc startup style RFC
Hi I've included your suggestions and put the latest changes here: http://www.googlebit.com/freebsd/patches/rc_fancy.patch-3 Thanks for all the feedback! Keep it coming! :) Works great on my FreeBSD 6-STABLE system too. Excellent. Now, colour please! :^) Aren. pgpnNiwBjSZJJ.pgp Description: PGP signature
Re: [PATCH] Fancy rc startup style RFC
While I personally am not necessarily opposed to this kind of patch, you should be aware that this idea has been proposed in the past, and roundly rejected. The consensus has been that we don't necessarily want FreeBSD to look like other OSes that do this. That said, when you have something that you're ready for a wider review on, please submit it first to freebsd-rc@, then [EMAIL PROTECTED] Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
Eric Anderson wrote: If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On 4/18/06, Darren Pilgrim [EMAIL PROTECTED] wrote: Eric Anderson wrote: If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. 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. -- Coleman Kane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Fancy rc startup style RFC
On 4/18/06, Doug Barton [EMAIL PROTECTED] wrote:
While I personally am not necessarily opposed to this kind of patch, you
should be aware that this idea has been proposed in the past, and roundly
rejected. The consensus has been that we don't necessarily want FreeBSD to
look like other OSes that do this.
I remember a time back when the idea of an /etc/rc.d/ was taboo to bring
up hopefully times are better now!
That said, when you have something that you're ready for a wider review on,
please submit it first to freebsd-rc@, then [EMAIL PROTECTED]
Doug
--
This .signature sanitized for your protection
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
You want colors?!?
You can have them! (attached)
---
Coleman Kane
--- rc.subr.orig Tue Apr 18 18:06:20 2006
+++ rc.subr Tue Apr 18 18:09:24 2006
@@ -313,12 +313,16 @@
break
fi
_list=$_nlist
- echo -n ${_prefix:-Waiting for PIDS: }$_list
+ if ! checkyesno rc_fancy; then
+ echo -n ${_prefix:-Waiting for PIDS: }$_list
+ fi
_prefix=,
sleep 2
done
if [ -n $_prefix ]; then
- echo .
+ if ! checkyesno rc_fancy; then
+ echo .
+ fi
fi
}
@@ -564,12 +568,14 @@
# if the precmd failed and force
# isn't set, exit
#
+ rcargsize=`echo $rc_arg`
+ rcargsize=${#rcargsize}
if [ -n $_precmd ]; then
debug run_rc_command: evaluating ${_precmd}().
eval $_precmd $rc_extra_args
_return=$?
[ $_return -ne 0 ] [ -z $rc_force ]
-return 1
+(echo_fancy FAILED `expr 10 + $rcargsize - 1`) return 1
fi
if [ -n $_cmd ]; then
@@ -577,7 +583,7 @@
eval $_cmd $rc_extra_args
_return=$?
[ $_return -ne 0 ] [ -z $rc_force ]
-return 1
+(echo_fancy FAILED `expr 10 + $rcargsize - 1`) return 1
fi
if [ -n $_postcmd ]; then
@@ -585,6 +591,7 @@
eval $_postcmd $rc_extra_args
_return=$?
fi
+ echo_fancy OK 0
return $_return
fi
@@ -600,13 +607,16 @@
;;
start)
+ echo -n Starting ${name}
if [ -z $rc_fast -a -n $rc_pid ]; then
+ echo_fancy SKIP 9
echo 12 ${name} already running? (pid=$rc_pid).
return 1
fi
if [ ! -x ${_chroot}${command} ]; then
info run_rc_command: cannot run ($command).
+ echo_fancy ERROR 9
return 1
fi
@@ -617,6 +627,7 @@
if ! checkyesno $_f; then
warn \$${_f} is not enabled.
if [ -z $rc_force ]; then
+ echo_fancy ERROR 9
return 1
fi
fi
@@ -625,6 +636,7 @@
if [ ! -d ${_f}/. ]; then
warn ${_f} is not a directory.
if [ -z $rc_force ]; then
+ echo_fancy ERROR 9
return 1
fi
fi
@@ -633,6 +645,7 @@
if [ ! -r ${_f} ]; then
warn ${_f} is not readable.
if [ -z $rc_force ]; then
+ echo_fancy ERROR 9
return 1
fi
fi
@@ -646,12 +659,11 @@
eval $_precmd
_return=$?
[ $_return -ne 0 ] [ -z $rc_force ]
-return 1
+(echo_fancy ERROR 9) return 1
fi
# setup the command to run, and run it
#
- echo Starting ${name}.
if [ -n $_chroot ]; then
_doit=\
${_nice:+nice -n $_nice }\
@@ -673,7 +685,7 @@
debug run_rc_command: _doit: $_doit
eval $_doit
_return=$?
- [ $_return -ne 0 ] [ -z $rc_force ] return 1
+ [ $_return -ne 0 ] [ -z $rc_force ] (echo_fancy FAILED 9) return 1
# finally, run postcmd
#
@@ -681,15 +693,19 @@
debug run_rc_command: evaluating ${_postcmd}().
eval $_postcmd
fi
+ echo_fancy OK 9
;;
stop)
+ echo -n Stopping ${name}
if [ -z $rc_pid ]; then
[ -n $rc_fast ] return 0
if [ -n $pidfile ]; then
+ echo_fancy SKIP 9
echo 12 \
${name} not running? (check $pidfile).
else
+ echo_fancy SKIP 9
echo 12 ${name} not running?
fi
return 1
@@ -702,12 +718,11 @@
eval $_precmd
_return=$?
[ $_return -ne 0 ] [ -z $rc_force ]
-return 1
+ (echo_fancy ERROR 9) return 1
fi
# send the signal to stop
#
- echo Stopping ${name}.
_doit=kill -${sig_stop:-TERM} $rc_pid
if [ -n $_user ]; then
_doit=su -m $_user -c 'sh -c \$_doit\'
@@ -718,7 +733,7 @@
#
eval $_doit
_return=$?
- [ $_return -ne 0 ] [ -z $rc_force ] return 1
+ [ $_return -ne 0 ] [ -z $rc_force ] (echo_fancy FAILED 9) return 1
# wait for the command to exit,
# and run postcmd.
@@ -727,24 +742,27 @@
eval $_postcmd
_return=$?
fi
+ echo_fancy OK 9
;;
reload)
+ echo -n Reloading ${name} config files
if [ -z $rc_pid ]; then
if [ -n $pidfile ]; then
+ echo_fancy SKIPPED 23
echo 12 \
${name} not running? (check $pidfile).
else
+ echo_fancy SKIPPED 23
echo 12 ${name} not running?
Re: [PATCH] Fancy rc startup style RFC
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]
