> From: [EMAIL PROTECTED] (Alfred M. Szmidt) > Date: Thu, 21 Mar 2002 14:41:09 +0100
> > If some of the features are a logical unit, you can test for one > > feature and assume that the others are present if it is. > What about using HOST_OPERATING_SYSTEM for the time being? I'd prefer not to do it that way. It doesn't accord with the autoconf philosophy, which is to test for features and not for operating systems. > > There are a lot of broken programs, then. GNU Emacs is one of them, > > for example: its dired mode parses 'ls' output. > And these programs should be fixed. That will be a major project. Can you start it by fixing GNU Emacs, at least, and making sure that the fix is installed? This is one of the first things we try to do when making incompatible changes to the core utilities. It is a good sanity check. For example, I recently patched GNU Emacs to be portable to the POSIX 1003.1-2001 changes made to the GNU core utilities. > > Also, I worry that the resulting 'ls' output would be wider than 80 > > columns too often. > The output of `ls -l' is almost always wider than 80 columns anyway. Not on my platform. If I run 'ls -l' on my home directory, the longest line is 74 characters long. Here it is: lrwxrwxrwx 1 eggert eggert 10 Aug 23 1998 +outgo -> Mail/outgo Many people are used to 'ls -l' fitting into 80 columns. It's a longstanding tradition, I'm afraid. > I prefer --gnu-extensions over --hurd-extensions. But that could well confuse people, since there is also a GNU/Linux operating system. Perhaps --gnu-hurd-extensions would be better? _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
