Subject: Re: stat(1)
To: Steven M. Bellovin <email@example.com>
From: Andrew Brown <firstname.lastname@example.org>
Date: 12/29/2001 11:25:51
>>>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
>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" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."