Re: conformance vs. compatibility
[EMAIL PROTECTED] said this stuff: After 10 years of being merely `obsolescent', head -N has finally been officially declared to be `obsolete'. I have yet to see a pointer to where the historic usage has been declared obsolete, outside of personal declarations that it has been officially declared obsolete elsewhere. Surely, you can't mean to imply that merely because it has been withdrawn from the posix guidelines, it has become obsolete. This would be a misinterpretation of posix in general. The authors of the posix guidelines have simply opted to not discuss it further, just as they don't discuss 'head -c'. That is, aside from an informational note, mentioning that they have intentionally left the '-c' option out --- which, coincidentally, doesn't make it obsolete, either. If i'm mistaken, please do point me to this official declaration. If you have no official declaration, at least point me to an excerpt in the posix publication stating, definitively, that when a feature is withdrawn from posix, it becomes officially obsolete for posix-conforming implementations. ari ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: conformance vs. compatibility
ari [EMAIL PROTECTED] writes: [EMAIL PROTECTED] said this stuff: After 10 years of being merely `obsolescent', head -N has finally been officially declared to be `obsolete'. I have yet to see a pointer to where the historic usage has been declared obsolete, outside of personal declarations that it has been officially declared obsolete elsewhere. head -10 was marked as obsolescent in the 1992 edition of the POSIX standard, and POSIX withdrew the requirement to support head -10 in the 2001 edition of the standard. If you don't think that makes head -10 obsolete then I guess we'll just have to agree to disagree about what the word obsolete means. People can reasonably disagree about whether it was wise for POSIX to make head -10 obsolete, and about whether it was wise of coreutils to give the coreutils installer and/or the user the ability to disable support for head -10. But those are different issues. There's no real dispute that head -10 is obsolete. If this really bugs you, then the proper way to change things back to the way they used to be is to change POSIX. You can start this process by filing a defect report with the Austin Common Standards Revision Group; see http://www.opengroup.org/austin/. Features become obsolete all the time in the GNU world. For example, GCC 3.3 removed support for unescaped newlines in C strings. This broke a few programs, but it's not really a big deal in the overall scheme of things, and there are some real advantages to sticking with the standard usage. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Bad config.h on cross-build configure...
David Daney [EMAIL PROTECTED] wrote: $ mipsel-linux-gcc --version mipsel-linux-gcc (GCC) 3.3.1 ... $ ../coreutils-5.0/configure --build=i686-linux --host=mipsel-linux --target=mipsel-linux Results in the following lines in config.h: ... #define UTILS_OPEN_MAX cross compiling run-test in open-max.m4 Any time you configure in a cross-compiling environment, you should pre-seed configure's cache with the var=val pairs corresponding to all `run'-tests (i.e. all tests that involve running a just-compiled-and-linked program). Then, when you run `./configure --cache=pre-seeded-cache', none of those programs will be (or need to be) run. Some of the run-tests are able to fall back on less-efficient, but guaranteed-to-work defaults. It's better to determine the precise values for those tests that are appropriate for your target system. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
[suggestion] install and symlinks
Hi there, As install can take care of the code in an installed files, by stripping it, it could take care of the symlinks when installing them. For now, install copies the symlinks as cp does, so the target directory will contain one copy of the target file per symlink. Provided that the link *was* valid, of course. But none of these files won't ever reflect any change in the target file that should have been the symlink's target. So, what about having the install program treating symlinks by the same way as cp -d does ? The thing could be: If the target symlink *will* point on something when in the target directory, so we can copy it into that directory. Best regards -- Hervé Autret ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: conformance vs. compatibility
[EMAIL PROTECTED] (Paul Jarc) writes: I think it ought to be possible for the user building coreutils to say what version of conformance they want - say, with a ./configure argument - and this should override the unistd.h definition. That might be reasonable. The coreutils maintainer should have the final say about this, though. He's probably tired of the whole subject, though, so I suspect he won't make this change unless someone proposes a nice patch to do it. Your other arguments about whether long-option syntax like --foo is conforming are not that convincing. At any rate they were settled long ago, I suspect, when RMS proposed the current long-option syntax to conform to POSIX as a pure extension, replacing the old long-option syntax. Personally I'd rather not reopen that can of worms; life is too short! ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: memleaks
Dennis Smit [EMAIL PROTECTED] wrote: I've been playing with valgrind and the gnu coreutils and found that some of these utils have small memleaks, i would love to fix them and send patches. Are you people intrested in such patches ? Yes. Please base any changes on the very latest versions in CVS: http://savannah.gnu.org/projects/coreutils/ ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: conformance vs. compatibility
Good point. The README is a bit obsolete anyway, as it talks about POSIX.2. Here's a proposed patch. 2003-11-04 Paul Eggert [EMAIL PROTECTED] * README: Document _POSIX2_VERSION. --- README.~1.12.~Tue Jul 29 13:55:00 2003 +++ READMETue Nov 4 10:50:42 2003 Thank you, Paul. I've just applied that. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: conformance vs. compatibility
Paul Eggert [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Paul Jarc) writes: I think it ought to be possible for the user building coreutils to say what version of conformance they want - say, with a ./configure argument - and this should override the unistd.h definition. That might be reasonable. The coreutils maintainer should have the final say about this, though. He's probably tired of the whole subject, though, so I suspect he won't make this change unless someone proposes a nice patch to do it. That's accurate. Thanks for writing so much on this thread. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
