Re: LSCOLORS warning is silly
On Mon, Feb 25, 2002 at 02:38:45AM -0500, Mike Barcroft wrote: Doug Barton [EMAIL PROTECTED] writes: Mike Barcroft wrote: Deprecated features should generate warnings. Ok, then let's call it Undocumented legacy support. I agree that features we don't want to support anymore should generate warnings that encourage users to change. However, there is so little cost to support the old flags that there is no reason to ever discontinue that support. it's two lines of code. You can see them in the diff. The code is even properly documented to indicate it's purpose. It can't get any better than that. I don't have any objections to making this a supported legacy mode, but I think deprecated features (things we *want* to go away) should produce warnings. I'd prefer not to support N different ways of specifying colours, and want to hold onto making the deprecated version include warnings. Sorry, Joe msg35241/pgp0.pgp Description: PGP signature
Re: LSCOLORS warning is silly
On Mon, 25 Feb 2002, Josef Karthauser wrote: On Mon, Feb 25, 2002 at 02:38:45AM -0500, Mike Barcroft wrote: Doug Barton [EMAIL PROTECTED] writes: Mike Barcroft wrote: Deprecated features should generate warnings. Ok, then let's call it Undocumented legacy support. I agree that features we don't want to support anymore should generate warnings that encourage users to change. However, there is so little cost to support the old flags that there is no reason to ever discontinue that support. it's two lines of code. You can see them in the diff. The code is even properly documented to indicate it's purpose. It can't get any better than that. I don't have any objections to making this a supported legacy mode, but I think deprecated features (things we *want* to go away) should produce warnings. I'd prefer not to support N different ways of specifying colours, and want to hold onto making the deprecated version include warnings. I could understand your argument if there were A) many different ways, or B) support for the one legacy method was complicated. But neither of these are true. Including a warning for something that is easy to support and costs us nothing is pointlessly pedantic. Do you have a technical reason for your position? -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LSCOLORS warning is silly
Josef Karthauser wrote: On Mon, Feb 25, 2002 at 02:38:45AM -0500, Mike Barcroft wrote: Doug Barton [EMAIL PROTECTED] writes: Mike Barcroft wrote: Deprecated features should generate warnings. Ok, then let's call it Undocumented legacy support. I agree that features we don't want to support anymore should generate warnings that encourage users to change. However, there is so little cost to support the old flags that there is no reason to ever discontinue that support. it's two lines of code. You can see them in the diff. The code is even properly documented to indicate it's purpose. It can't get any better than that. I don't have any objections to making this a supported legacy mode, but I think deprecated features (things we *want* to go away) should produce warnings. I'd prefer not to support N different ways of specifying colours, and want to hold onto making the deprecated version include warnings. Just make the damn thing not work with the deprecated setup, remove the warnings, and handle the complaints. You're going to be handling the complaint either way. Or get rid of the warning, and avoid the complaints, and remove the deprecated support code later, after most of the user base is using new configuration data because of a turnover or use of the documentation. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
LSCOLORS warning is silly
A couple months ago an improvement was added to the color support of ls
to use a wider variety of colors, indicated by alphabet characters
instead of numbers. While I think this is a good change, it included a
warning when users have the old style numeric flags in their LSCOLORS
variable. I think this is a mistake, and needlessly places another
barrier for users coming into -current. Since the support for the old
style color flags is practically free, I'd like to suggest that rather
than warning the user, we simply continue to support the old flags, and
indicate that they are deprecated in the man page.
I'd like to commit the attached patch. Let me know what you think.
--
We have known freedom's price. We have shown freedom's power.
And in this great conflict, ... we will see freedom's victory.
- George W. Bush, President of the United States
State of the Union, January 28, 2002
Do YOU Yahoo!?
? ls.1.gz
Index: ls.1
===
RCS file: /home/ncvs/src/bin/ls/ls.1,v
retrieving revision 1.62
diff -u -r1.62 ls.1
--- ls.19 Jan 2002 13:29:39 - 1.62
+++ ls.125 Feb 2002 05:24:12 -
@@ -496,6 +496,8 @@
is the foreground color and
.Ar b
is the background color.
+The old style of numbers as color designators are still supported,
+although deprecated.
.Pp
The color designators are as follows:
.Pp
Index: print.c
===
RCS file: /home/ncvs/src/bin/ls/print.c,v
retrieving revision 1.53
diff -u -r1.53 print.c
--- print.c 25 Feb 2002 01:36:59 - 1.53
+++ print.c 25 Feb 2002 05:24:13 -
@@ -481,7 +481,6 @@
int j;
int len;
char c[2];
- short legacy_warn = 0;
if (cs == NULL)
cs = ;/* LSCOLORS not set */
@@ -500,13 +499,6 @@
/* Legacy colours used 0-7 */
if (c[j] = '0' c[j] = '7') {
colors[i].num[j] = c[j] - '0';
- if (!legacy_warn) {
- fprintf(stderr,
- warn: LSCOLORS should use
- characters a-h instead of 0-9 (
- see the manual page)\n);
- }
- legacy_warn = 1;
} else if (c[j] = 'a' c[j] = 'h')
colors[i].num[j] = c[j] - 'a';
else if (c[j] = 'A' c[j] = 'H') {
Re: LSCOLORS warning is silly
Doug Barton [EMAIL PROTECTED] writes: A couple months ago an improvement was added to the color support of ls to use a wider variety of colors, indicated by alphabet characters instead of numbers. While I think this is a good change, it included a warning when users have the old style numeric flags in their LSCOLORS variable. I think this is a mistake, and needlessly places another barrier for users coming into -current. Since the support for the old style color flags is practically free, I'd like to suggest that rather than warning the user, we simply continue to support the old flags, and indicate that they are deprecated in the man page. Deprecated features should generate warnings. See the Committers Guide (8.3) for details. The change to the manual is correct though. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LSCOLORS warning is silly
Mike Barcroft wrote: Doug Barton [EMAIL PROTECTED] writes: A couple months ago an improvement was added to the color support of ls to use a wider variety of colors, indicated by alphabet characters instead of numbers. While I think this is a good change, it included a warning when users have the old style numeric flags in their LSCOLORS variable. I think this is a mistake, and needlessly places another barrier for users coming into -current. Since the support for the old style color flags is practically free, I'd like to suggest that rather than warning the user, we simply continue to support the old flags, and indicate that they are deprecated in the man page. Deprecated features should generate warnings. Ok, then let's call it Undocumented legacy support. I agree that features we don't want to support anymore should generate warnings that encourage users to change. However, there is so little cost to support the old flags that there is no reason to ever discontinue that support. it's two lines of code. You can see them in the diff. The code is even properly documented to indicate it's purpose. It can't get any better than that. Let me restate the more important point... there are already 843 things that need to be changed/updated/dealt with in moving from 4.x to 5.0. Most of them are even necessary. If we want to encourage users to adopt 5.0 (at whatever phase of the game) we should not place silly barriers in front of them. It took me over an hour today to track down broken stuff that developed between my last -current update of 12/2/01 till today. And I track development better than most of the people who will use the first 5.0 snapshot. This is one more annoyance I don't need, and I think most of our userbase will feel the same way. If this were an expensive thing to support, I would have stuck with the man page update only. But it's not. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LSCOLORS warning is silly
Doug Barton [EMAIL PROTECTED] writes: Mike Barcroft wrote: Deprecated features should generate warnings. Ok, then let's call it Undocumented legacy support. I agree that features we don't want to support anymore should generate warnings that encourage users to change. However, there is so little cost to support the old flags that there is no reason to ever discontinue that support. it's two lines of code. You can see them in the diff. The code is even properly documented to indicate it's purpose. It can't get any better than that. I don't have any objections to making this a supported legacy mode, but I think deprecated features (things we *want* to go away) should produce warnings. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
