* Paul Eggert writes: >> From: [EMAIL PROTECTED] (Alfred M. Szmidt) Date: Sun, 17 Mar 2002 >> 19:16:26 +0100 >> >> I sort of dislike having an macro for each feature, it would result >> in a lot of them (unknown user bits, translators, author field, >> etc). But I suppose that I could live with this, if any system ever >> adds these options they will work without any weird changes.
> 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? Just check if HOST_OPERATING_SYSTEM equals GNU and be done with it. Or just define something like HAVE_GNU_EXTENTIONS right after the case statement for GNU in aclocal.m4 (UTILS_HOST_OS). And if at some later point other systems start supporting any of these extensions one can change them accordingly. >> I have mixed feelings about this because this is very useful >> information for the user, and any program that actually parses the >> output of ls is broken IMHO. > 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. > 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. We are talking about the long listing format and not a plain `ls' right? > I think it'd be OK to muck with "dir" and "vdir", though. People > could get the behavior that you want with "vdir" or "dir -l", say. Don't think I have ever used those commands. >> Would it be OK to use one switch for the showing the unknown bits >> and translator information (--gnu, I know it's a bad name) or >> should one use two switches >> (--show-translators/--show-unknown-user-bits)? > I think one switch would be OK, at least at first. You might want > to call it --hurd-extensions, perhaps? I prefer --gnu-extensions over --hurd-extensions. -- Alfred M. Szmidt _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
