Re: ls(1) options affecting -l long format
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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Tue, 24 Aug 1999, Sheldon Hearn wrote: 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. Why not change -o's behavior too? I find the current behavior unintuitive and kind of annoying. If I specify -o, I want to see the file flags; "ls -o" producing the same output as "ls" is just ... weird. As you can see, my argument is as rational and well-supported as yours is. ;-) -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ls(1) options affecting -l long format
On Tue, 24 Aug 1999, Sheldon Hearn wrote: 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. Why not change -o's behavior too? I find the current behavior unintuitive and kind of annoying. If I specify -o, I want to see the file flags; ls -o producing the same output as ls is just ... weird. As you can see, my argument is as rational and well-supported as yours is. ;-) -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999, Sheldon Hearn wrote: The OpenGroup Single UNIX Specification is quite clear on the following issue: -g, -n and -o all imply -l. Of course, the OpenGroup spec uses -g for something we don't offer. Our -g is a backward compatibility option. Yes, I agree that that's what it means. So my point here relates to -n and -o. As I mentioned on the PR associated with the addition of the -n option, taking it to imply -l does nothing but reduce user-interface flexibility. It prevents me from using this in my .profile alias ls='ls -n' This makes no sense. to mean "When I ask for a long listing, show numeric ID's instead of names. If I don't ask for a long listing, don't give me one." The reason I say it doesn't make sense is that you shouldn't be asking for a long listing with ls -l if you want numeric ids, you should be using ls -n. Instead of your alias, you should just be using ls -n where you'd otherwise use ls -l. As far as I'm concerned, we should _not_ be following the OpenGroup spec's mandate on this issue. I think that -o and -n should continue to operate as they do in FreeBSD's and NetBSD's ls, to allow the kind of flexibility suggested above. Ideally, the OpenGroup spec should change. :-) The above is not flexibility; it's just different behavior. We need to follow their specifications so things can be portable. So what's my question? How hard should we be trying to stick to the OpenGroup spec? Whatever we decide should apply to both -n and -o. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Brian Fundakowski Feldman / "Any sufficiently advanced bug is\ [EMAIL PROTECTED] | indistinguishable from a feature." | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 01:00:05 MST, "Brian F. Feldman" wrote: The reason I say it doesn't make sense is that you shouldn't be asking for a long listing with ls -l if you want numeric ids, you should be using ls -n. Instead of your alias, you should just be using ls -n where you'd otherwise use ls -l. That's good enough for me. :-) If there are no objections (other than the obvious backward issue of compatibility) in the next few days, I'll bring Chris's change in (with a style fix), as well as teaching -o to imply -l. I'm not to phased with backward compatibility on this one, since I think it's always been understood that the output of ls isn't really intended for scripts (that's what find and test are for). The OpenGroup spec actually makes a point of that in its manpage. Thanks for your input. Later, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 11:36:00 +0200, Sheldon Hearn wrote: If there are no objections (other than the obvious backward issue of compatibility) in the next few days, I'll bring Chris's change in (with a style fix), as well as teaching -o to imply -l. Eeek, I've been confused. Our -o and the OpenGroup spec's -o are completely different. :-) 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. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 13:13:14 +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. The diff for this change is available from: http://www.freebsd.org/~sheldonh/ls.diff.n_implies_l Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999, Sheldon Hearn wrote: The OpenGroup Single UNIX Specification is quite clear on the following issue: -g, -n and -o all imply -l. Of course, the OpenGroup spec uses -g for something we don't offer. Our -g is a backward compatibility option. Yes, I agree that that's what it means. So my point here relates to -n and -o. As I mentioned on the PR associated with the addition of the -n option, taking it to imply -l does nothing but reduce user-interface flexibility. It prevents me from using this in my .profile alias ls='ls -n' This makes no sense. to mean When I ask for a long listing, show numeric ID's instead of names. If I don't ask for a long listing, don't give me one. The reason I say it doesn't make sense is that you shouldn't be asking for a long listing with ls -l if you want numeric ids, you should be using ls -n. Instead of your alias, you should just be using ls -n where you'd otherwise use ls -l. As far as I'm concerned, we should _not_ be following the OpenGroup spec's mandate on this issue. I think that -o and -n should continue to operate as they do in FreeBSD's and NetBSD's ls, to allow the kind of flexibility suggested above. Ideally, the OpenGroup spec should change. :-) The above is not flexibility; it's just different behavior. We need to follow their specifications so things can be portable. So what's my question? How hard should we be trying to stick to the OpenGroup spec? Whatever we decide should apply to both -n and -o. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- Brian Fundakowski Feldman / Any sufficiently advanced bug is\ gr...@freebsd.org | indistinguishable from a feature. | FreeBSD: The Power to Serve!\-- Rich Kulawiec / To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 01:00:05 MST, Brian F. Feldman wrote: The reason I say it doesn't make sense is that you shouldn't be asking for a long listing with ls -l if you want numeric ids, you should be using ls -n. Instead of your alias, you should just be using ls -n where you'd otherwise use ls -l. That's good enough for me. :-) If there are no objections (other than the obvious backward issue of compatibility) in the next few days, I'll bring Chris's change in (with a style fix), as well as teaching -o to imply -l. I'm not to phased with backward compatibility on this one, since I think it's always been understood that the output of ls isn't really intended for scripts (that's what find and test are for). The OpenGroup spec actually makes a point of that in its manpage. Thanks for your input. Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 11:36:00 +0200, Sheldon Hearn wrote: If there are no objections (other than the obvious backward issue of compatibility) in the next few days, I'll bring Chris's change in (with a style fix), as well as teaching -o to imply -l. Eeek, I've been confused. Our -o and the OpenGroup spec's -o are completely different. :-) 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. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ls(1) options affecting -l long format
On Mon, 23 Aug 1999 13:13:14 +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. The diff for this change is available from: http://www.freebsd.org/~sheldonh/ls.diff.n_implies_l Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
