[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Fileutils and GNU/Hurd extentions.
From: |
Paul Eggert |
Subject: |
Re: GNU Fileutils and GNU/Hurd extentions. |
Date: |
Sun, 17 Mar 2002 23:43:28 -0800 (PST) |
> From: address@hidden (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?