bug-fileutils
[Top][All Lists]
Advanced

[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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]