> 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. > 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. Also, I worry that the resulting 'ls' output would be wider than 80 columns too often. 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. > 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? _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
