problem about /bin/true
Hi All, I have a small problem when I tried to install latest 2.6 kernel on my desktop. When compiling and installing the mkinitrd program referenced to /bin/true and gae out an error No module /bin/true for linux 2.6.version. I do not really understand why the version of this binary is important. Further when I am installing 2.6 kernel on a system which already has 2. how can it expect to find module that has been compiled for 2.6. This is very confusing. Any suggestions in this regard would be very helpful. Thanks and Best Regards, KK ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
I found a little bug of uname command
Good Morning: Sir/Lady. I am chinese user of RedHat 9. My kernel version is 2.4.20-8 on an i686. Today I found a little bug of uname command. I read manual of uname. If I used uname -v, the system will print the kernel version. But I found the system did not print the kernel version but program produced time. I thought maybe this is a little bug. Because I am a new user of Linux, there are a lot of thing I did not know . But I think Linux is very powerful and interesting OS and I love it. I believe it will be more powerful in future!! Thank you for reading. If I make a mistake, please forgive me! :) Your Sincerely HuiXue. China Sichuan UESTC ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
sort -n -u buggy ???
Sort command seems to be buggy : $ sort --version sort (GNU coreutils) 5.94 Copyright (C) 2006 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License http://www.gnu.org/licenses/gpl.html. There is NO WARRANTY, to the extent permitted by law. Written by Mike Haertel and Paul Eggert. $ cat foo 83.154.241.254 83.155.32.254 83.155.65.254 $ sort -n -u foo 83.154.241.254 83.155.32.254 Best regards, Arnauld ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort -n -u buggy ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [It is odd that you used the obsolete bug-textutils mailing list alias, even though you are using the latest coreutils 5.94.] According to Arnauld Michelizza on 5/2/2006 3:46 AM: Sort command seems to be buggy : $ cat foo 83.154.241.254 83.155.32.254 83.155.65.254 $ sort -n -u foo 83.154.241.254 83.155.32.254 Thanks for the report. However, this is expected behavior, and a very similar question has been asked in the past: http://lists.gnu.org/archive/html/bug-coreutils/2006-03/msg00036.html - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEV1qP84KuGfSFAYARAp6/AJwMIAJnTZlXVzhUi4ZHOOjBwy2AMgCfSQWg jYhHmXUFZiZRkKnndE3SfrQ= =8HT1 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: I found a little bug of uname command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to george_xuehui on 5/2/2006 2:20 AM: Good Morning: Sir/Lady. I am chinese user of RedHat 9. My kernel version is 2.4.20-8 on an i686. Today I found a little bug of uname command. I read manual of uname. If I used uname -v, the system will print the kernel version. But I found the system did not print the kernel version but program produced time. I thought maybe this is a little bug. Because I am a new user of Linux, there are a lot of thing I did not know . But I think Linux is very powerful and interesting OS and I love it. I believe it will be more powerful in future!! Thank you for reading. If I make a mistake, please forgive me! :) Thanks for the report. However, you did not provide very many details as to what actually happened, and what you expected. Capturing the output on your screen is useful. I suggest reading http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for ideas on better bug reporting. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEV1ui84KuGfSFAYARAiUzAJ4+uX3qlNEufmwFJRgPvVvlt8x7ewCgrvOH tDh1MsQGjF2JsZ8NFEHvD7w= =kYo9 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: problem about /bin/true
Krishna Kumar [EMAIL PROTECTED] writes: When compiling and installing the mkinitrd program referenced to /bin/true and gae out an error No module /bin/true for linux 2.6.version. This sounds like a problem with mkinitrd or with your module system, not with coreutils, so you might try asking on the mailing list for the program that actually has the bug. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: I found a little bug of uname command
george_xuehui [EMAIL PROTECTED] writes: If I used uname -v, the system will print the kernel version. But I found the system did not print the kernel version but program produced time. Many systems, including mine, use a time stamp to denote the kernel version. That's probably what happened to you. If so, uname is operating correctly. For example: 515-penguin $ uname -a Linux penguin 2.4.27-2-686 #1 Wed Aug 17 10:34:09 UTC 2005 i686 GNU/Linux 516-penguin $ uname -v #1 Wed Aug 17 10:34:09 UTC 2005 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: patch: contrib/compare_tests
Andrew Pinski wrote: I was lazy today and decided to use compare_tests. Guess what, it doesn't work on recent coreutils/sort (i.e. the one on FC5). From the texinfo doc: On older systems, `sort' supports an obsolete origin-zero syntax `+POS1 [-POS2]' for specifying sort keys. This obsolete behavior can be enabled or disabled with the `_POSIX2_VERSION' environment variable (*note Standards conformance::), but portable scripts should avoid commands whose behavior depends on this variable. For example, use `sort ./+2' or `sort -k 3' rather than the ambiguous `sort +2'. This is the same problem as tail and head. Someone should tell Coreutils that again they broking stuff that should work no matter what environment variable is set. Also Redhat (and all other distros) should think about bycotting GNU Coreutils until they fix this bug. Coreutils is just implementing the decisions of the Austin Common Standards Revision Group. If someone posted here that e.g. g++ rejected code that was not valid C++0x the response would be exactly the same, fix your code not g++ is buggy for not accepting this broken code and should be boycotted. Brian ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: patch: contrib/compare_tests
Andrew Pinski wrote: I was lazy today and decided to use compare_tests. Guess what, it doesn't work on recent coreutils/sort (i.e. the one on FC5). From the texinfo doc: On older systems, `sort' supports an obsolete origin-zero syntax `+POS1 [-POS2]' for specifying sort keys. This obsolete behavior can be enabled or disabled with the `_POSIX2_VERSION' environment variable (*note Standards conformance::), but portable scripts should avoid commands whose behavior depends on this variable. For example, use `sort ./+2' or `sort -k 3' rather than the ambiguous `sort +2'. This is the same problem as tail and head. Someone should tell Coreutils that again they broking stuff that should work no matter what environment variable is set. Also Redhat (and all other distros) should think about bycotting GNU Coreutils until they fix this bug. Coreutils is just implementing the decisions of the Austin Common Standards Revision Group. If someone posted here that e.g. g++ rejected code that was not valid C++0x the response would be exactly the same, fix your code not g++ is buggy for not accepting this broken code and should be boycotted. Not really since these utils have been around long before and closed source companies are not willing to change this utils for a long time. Also this is a widely supported extension unlike most of the extensions that are added to G++ (or really most of them are bugs in G++ that are not known unlike this which was a feature). Now this is just stupid argueing about this over and over, just fix Coreutils to be like all other OS's utils and forgot about the standard here. -- Pinski ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
