At 6:02 PM -0400 9/24/02, Garrett Wollman wrote: ><<On Tue, 24 Sep 2002, Bill Fenner <[EMAIL PROTECTED]> said: > > > When's the first time the FreeBSD sort(1) man page mentioned that > > this syntax was deprecated? Can we at least start from there? > >It does not appear to have ever been properly documented. > >I don't object to maintaining backwards compatibility for a few more >releases (even if the application writers are the ones at fault), >since many more people read the manual pages than read the Standard. >However, I would point out that this isn't the first time we broke a >traditional syntax in favor of reducing restrictions on argument >names: see the recent history of chown(8).
In the case of 'sort', I would rather see us ease into the change a bit more. We already have enough going on with 5.0-current that we don't need the extra excitement of this particular change. I can readily live with the fact that 5.0-release will not be 100% posix compliant. I know I have all kinds of scripts squirreled away which have 'sort +n' commands in them, and I have zero real files that are named +n. This change gives me nothing but broken scripts, and I would rather see us have an "almost posix" sort, and with the option to set an environment variable to remove support for +N. That way, the people who *want* to debug a bunch of scripts can set that environment variable, instead of forcing the rest of us to run around setting an environment variable to protect us from broken scripts. In some sense I don't mind the change, but I really think we are now past the point where we can keep throwing incompatible changes into 5.0-release. We have enough broken ports on 5.0-current, we do not need more incompatible changes to break even more ports to give us even more work to do. Just my 2 cents... -- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
