ari <[EMAIL PROTECTED]> writes: > 'POSIXLY_CORRECT' may be specified if strict posix compliance must > be followed. I see no reason why this cannot be the case with the > 'head' and 'tail' functions.
My feeling is that POSIXLY_CORRECT is not something that users would normally want to set, whereas the choice of POSIX standards is something that users have to deal with on occasion (unfortunately). That is why coreutils has the _POSIX2_VERSION environment variable. Setting _POSIX2_VERSION=199209 in your environment causes 'head', 'tail', etc. to behave the way that you'd like. It's up to your the coreutils installer (typically a software distribution maintainer) to specify the default value for _POSIX2_VERSION. If they don't specify a default value, coreutils defaults to the older standard. So the compatibility problems that you mention occur only when the coreutils installer has indicated a desire to conform to the new standard by default (even when that is incompatible with the old standard). If you like, you can always ask your coreutils installer to build coreutils so that it defaults to the old standard instead of to the new one. > - Posix was designed to increase portability. Strict "conformance" in > this manner cripples portability instead. It hurts some kinds of portability and helps others. It depends on what you want. Admittedly it is a judgment call. > - In "IEEE Std 1003.1" (2003 Edition), the 'head' manual page states > (under the "APPLICATION USAGE" header): > > The obsolescent - number form is withdrawn in this version. > Applications should use the -n number option. > > Note the use of "should" here. If applications using 'head' are not > _required_ to use the '-n number' option, then the actual program > should definitely support it. That doesn't follow. For example, an application can stop using "head -3" and can instead use "sed 3q". The application is not required to use "head -n 3". > That is, unless one would like to create a system that requires > strict posix compliance of all executables present. I think we all agree that coreutils shouldn't require that all its users strictly conform to POSIX. However, coreutils does have a goal of conforming to POSIX itself. > - GNU utilities support many options that are not covered in posix. True, but these options aren't under dispute, as they follow the syntactic guidelines of POSIX. There is a consistency argument for sticking to the guidelines. > One may argue that 'tail -35' does not result in a multi-digit > option of 35, but rather a null option, with argument of 35. That's not how the guidelines work. If 'tail' were to follow the guidelines, then 'tail -35', 'tail -3 -5', 'tail -5 -3', and 'tail -53' would all be equivalent. I don't think anybody'd like that. > To illustrate my position further, let's examine another way that > these programs "violate" posix standards: long options. I don't see why they "violate" the standards. A plain "--" argument cannot possibly be an option (since it is a standard delimiter), and therefore "-" cannot possibly be an option name. Long options therefore are not part of the standard option syntax at all; they are a pure extension. I suspect this is by design, as RMS was involved in the original POSIX specification effort, and RMS likes long options. > I fail to see why the GNU utilities should be configured to > break posix "compliance" for the convenience of long options, > yet not for the requirement of portability. It's a judgment call. Long options are clearly useful. It's less clearly useful to support options that have been officially obsolescent for more than a decade, and have been officially obsolete for almost two years. > While these features may be considered obsolescent by some, they are > certainly not obsolete. One can argue about de facto, but clearly they are obsolete de jure. At some point developers should get used to writing portable code that does not use the features. Reasonable people can disagree on when that point should be. In the "All progress depends on the unreasonable man" department, I've been running with _POSIX2_VERSION=200112 in my environment for many months. Any programs that want to be portable to my environment have to be fixed to not rely on these obsolete features. It's not been much of a problem, really. (I use Debian, if that matters.) _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils