>>>Exactly.  No-one really needs an even more verbose "ls" output.  Though
>>>parsing ls output is never really what one ought to be doing, it is too
>>>likely to undergo random changes to make it "look better".
>>
>>what if...what if someone were to use up another option letter for ls
>>and allow the user to specify a "format" (sort in the same way that
>>date and ps allow user specified formatting)?  hmm...-O looks unused.  :)
>
>I think that that leads us down a very dangerous path.  Well, actually, 
>it leads us further down a path that we're already on.

dangerous?  as in "fraught with peril", or simply "much too complex to
consider"?

>Right now, we have (at least) date and ps that (in effect) apply 
>user-defined formatting instructions to a structure dump.  You propose 
>to add another.  Maybe what we really need is raw structure dumps, plus 
>a generalized (controlled by /etc/struct?) translator into the 
>individual fields, plus a prettyprinter.

i was about to reply that there really aren't that that many
structures that anyone needs dumped, and then i remembered id.  then i
considered that if you add the capability of looking at more
structures, more structures will appear that need looking at.

date wins in this regard, since it's only utilizing a routine in libc
for all the formatting work it might be asked to do.  ps does its own
thing.  ls currently does its own thing, but we *could* plop a routine
in libc (or libutil, or libformat) that formatted the contents of a
struct stat according so some string...  :)

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."