Date: Tue, 24 Aug 1999 11:44:34 +0200 From: Sheldon Hearn <sheldonh@uunet.co.za> To: freebsd-hackers@FreeBSD.ORG Subject: Re: ls(1) options affecting -l long format Message-ID: <68717.935487874@axl.noc.iafrica.com> In-Reply-To: Your message of "Mon, 23 Aug 1999 14:23:21 %2B0200." <51362.935411001@axl.noc.iafrica.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 Aug 1999 14:23:21 +0200, Sheldon Hearn wrote: > > The -n option will imply -l, but -o will be a no-op unless at least one > > of -n and -l is specified. Manpage changes will be included in the deal. I've been playing with the ls(1) that this patch produces and now that I've had some time with it, I can honestly say I really don't like it. i've had trouble formulating an objection beyond "it doesn't feel like UNIX" which is why this mail was delayed. Our ls(1) can not, for the moment, be completely compliant with the OpenGroup Single UNIX Specification. We have at least two BSD-specific options that conflict with OpenGroup spec options. We also have a precedent for options which affect but do not imply a long listing (-o). I believe we should stick with that precedent and leave -n as it is. I think that the small gain of partial OpenGroup compliance does not weigh in heavily enough against the loss of internal consistency the patch introduces into ls(1). I also believe that the OpenGroup spec offers sufficient warning against relying on ls(1) on one platform to behave the same way as ls(1) on another: " Because systems that conform to the Single UNIX Specification, Version " 2 may have extensions, the file modes field in output produced by ls -l " may vary among conforming systems. In particular, certain file types " and executable bits may vary. Applications can pass the information in " this field directly to a user printout or prompt; but instead of taking " actions based on the file modes field, a portable application should " generally use the test utility instead. " " The output of ls with the -l and related options (such as mode and " time information) contains information that logically could be used " by utilities such as chmod and touch to restore files to a known " state. However, this information is presented in a format that cannot be " used directly by those utilities, or be easily translated into a format " that can be used. I've seen correspondance from Garrett Wollman elsewhere, which seemed to indicate that he supports this view. I'd appreciate feedback because, at this stage, I don't think I'll be bringing in this change. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?68717.935487874>