date dosen't convert date from day-of-year
Hi I have used 'date' command in Debian Sarge to compute the actual date from the day-of-year value. I have sent the (wrong) date e.q. 2007-01-48 and the date has given me back the correct feb 17 00:00:00 CET 2007 Now the date complains for bad date and gives nothing back! Please, could there be some option to compute the right date from day-of-year again? Or should I use some other command? Sincerely Peter ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Building universal binaries makes 'check' fail (comment on my last message)
Hello, regarding the mail i sent a couple of minutes ago: The universal binary of 'md5sum' is apparently broken. $gmd5sum cmd_output_tail.bz2 a5999a019ecdc31e67211cfc5d18e0df cmd_output_tail.bz2 $openssl md5 cmd_output_tail.bz2 MD5(cmd_output_tail.bz2)= 6a6c49484d78df32581f1f9dd8d00a18 Regards, Elias Pipping ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date dosen't convert date from day-of-year
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Mgr. Peter Tuharsky on 2/27/2007 2:00 AM: Hi I have used 'date' command in Debian Sarge to compute the actual date from the day-of-year value. I have sent the (wrong) date e.q. 2007-01-48 and the date has given me back the correct feb 17 00:00:00 CET 2007 That was in older versions of coreutils. Now the date complains for bad date and gives nothing back! This is intentional. There are too many places where the old behavior of accepting invalid dates led to surprising behavior. Please, could there be some option to compute the right date from day-of-year again? Or should I use some other command? $ date -u -d '2007-01-01 +48 days' Sun Feb 18 00:00:00 UTC 2007 - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFF5C2N84KuGfSFAYARAhIpAJj0MExSj4f5dBV4nFNqwpKMLnQdAJ9CzZah 3uBdH4Te0e5xfIPvS34sdg== =Wtxo -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Should df --portability allow thousands separators?
Paul Eggert [EMAIL PROTECTED] wrote: Peter D. [EMAIL PROTECTED] writes: When an inconsistent set of environment variables and command line options is given then sending a polite informative version of programming error to standard error is useful. However, sending most sensible output to standard out will cause the least grief. I also would prefer avoiding a diagnostic if possible. Also, it seems confusing to pay attention to part of an environment variable, but ignore the rest. How about using the following rule instead? If -P is used, ignore the DF_BLOCK_SIZE, BLOCK_SIZE, and BLOCKSIZE environment variables. This is easier to document and understand (at least for me). Here's a proposed patch to do that. Thanks. That's fine with me. I've committed it. Choosing between a complete patch and an off-the-cuff one is always easy :) But we still need a test case or two for this, so I've added one: diff --git a/ChangeLog b/ChangeLog index 0175406..56580a0 100644 --- a/ChangeLog +++ b/ChangeLog @@ -5,6 +5,12 @@ affected by DF_BLOCK_SIZE, BLOCK_SIZE, or BLOCKSIZE. * src/df.c (main): Implement this. +2007-02-27 Jim Meyering [EMAIL PROTECTED] + + Add a test for the above. + * tests/misc/df-P: New file. + * tests/misc/Makefile.am (TESTS): Add df-P. + 2007-02-25 Jim Meyering [EMAIL PROTECTED] * Makefile.maint (announcement): Adjust so that it works with diff --git a/tests/misc/Makefile.am b/tests/misc/Makefile.am index 4372850..5ecd451 100644 --- a/tests/misc/Makefile.am +++ b/tests/misc/Makefile.am @@ -39,6 +39,7 @@ TESTS_ENVIRONMENT = \ # will execute the test script rather than the standard utility. TESTS = \ + df-P \ pwd-unreadable-parent \ cut \ wc-files0-from \ diff --git a/tests/misc/df-P b/tests/misc/df-P new file mode 100644 index 000..3a5ec9b --- /dev/null +++ b/tests/misc/df-P @@ -0,0 +1,60 @@ +#!/bin/sh +# Ensure that df -P is not affected by BLOCK_SIZE settings + +# Copyright (C) 2007 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA +# 02110-1301, USA. + +if test $VERBOSE = yes; then + set -x + df --version +fi + +. $srcdir/../envvar-check +. $srcdir/../lang-default + +pwd=`pwd` +t0=`echo $0|sed 's,.*/,,'`.tmp; tmp=$t0/$$ +trap 'status=$?; cd $pwd chmod -R u+rwx $t0 rm -rf $t0 exit $status' 0 +trap '(exit $?); exit $?' 1 2 13 15 + +framework_failure=0 +mkdir -p $tmp || framework_failure=1 +cd $tmp || framework_failure=1 + +if test $framework_failure = 1; then + echo $0: failure in testing framework 12 + (exit 1); exit 1 +fi + +fail=0 + + df -P . t1 || fail=1 +BLOCK_SIZE=1M df -P . t2 || fail=1 + +# Since disk utilization may be changing, compare only df's header line. +# That records the block size. E.g., for 1M, it would be: +# Filesystem 1048576-blocks Used Available Capacity Mounted on +# while for 1K, it would be +# Filesystem 1024-blocks Used Available Capacity Mounted on + +head -n1 t1 exp || fail=1 +head -n1 t2 out || fail=1 + +cmp out exp || fail=1 +test $fail = 1 diff out exp 2 /dev/null + +(exit $fail); exit $fail ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
chroot bug with MD disks (software raid disks)
hello. I have just seen a strange behaviour with chroot on a system using CentOS 4.4, with root being /dev/md2, and trying to chroot to another drive array which is /dev/md22. When doing this with the following command: chroot /my_folder_with_md22 then, the chroot indicates that the mounted device is not md22 but md12: # mount /dev/md12 on / type ext3 (rw) I also have a md12 array on this system. It seems that chroot is mixing things up. However, if I place a file on the /dev/md22 array, and then chroot to it, the file is really present there, but the mount command still reports to be using the /dev/md12 array. It's the first time I use this command, so I might also do something wrong, but it doesn't seem so. Thanks in advance for any bug confirmation. Regards, Daniel ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: kilo is k and not K
Alfred M. Szmidt wrote: Standards should never be followed blindly, and standards should be broken when one thinks one has good reasons. SI also conflicts with POSIX in this case. Not to mention that SI does not define prefixes for all possible units, only SI units, and a byte is not a SI unit. So SI-wise, there is nothing wrong about using k or K as a prefix symbol for `kilo'. From (coreutils)Block size: `k' `K' `KiB' kibibyte: 2^10 = 1024. `K' is special: the SI prefix is `k' and the IEC 60027-2 prefix is `Ki', but tradition and POSIX use `k' to mean `KiB'. Well put. Personally I can't stand the fact that someone decided to make up such a silly sounding word as kibi because they don't like the fact that the contextualized definition of Kilo-Byte was slightly at odds with the SI use of the Kilo prefix. It was well established that a Kilo-Byte was 1024 bytes and was abbreviated as KB well before this silly 'kibi' nonsense started. SI does not define what a kilo-byte is, computer scientists do, and they defined it as 1024. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: kilo is k and not K
SI does not define what a kilo-byte is, computer scientists do, and they defined it as 1024. Being a CS, I like consistency, and I also happen to like kilo-byte == 1000 bytes. :-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: choice of file system build-dir can change how coreutils works
James Youngman [EMAIL PROTECTED] wrote: On 2/21/07, Andreas Schwab [EMAIL PROTECTED] wrote: Paul Eggert [EMAIL PROTECTED] writes: This should be a rarer problem, I think, since O_NOFOLLOW is typically implemented by the operating system, not by the file system, so it typically either works on all file systems, or works on no file systems. Even then, the kernel might be different from the one you are building for. Yes, you can't assume that O_NOFOLLOW is available as a feature just because the build system defined it. Findutils does this:- ... /* Linux kernels 2.1.126 and earlier ignore the O_NOFOLLOW flag. */ ... /* FreeBSD 3.0-CURRENT and later support it */ Thanks for the suggestion, but I'm hesitant to add even that little bit of overhead in support of people who build on a more modern system and hope the resulting binaries will function properly on systems as old as those. FreeBSD is up to 6.x and Linux to 2.6. I don't know about FreeBSD, but in Linux-land, I'm pretty sure even the security-_un_conscious hobbyist (who builds packages like coreutils from source) moved off of pre-2.2 Linux a long time ago. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Building universal binaries makes 'check' fail
In http://lists.gnu.org/archive/html/bug-coreutils/2007-02/msg00290.html Elias Pipping [EMAIL PROTECTED] writes: The actual problem (while these binaries work flawlessly for me) is that 'make check' fails (see cmd_output_tail) Most likely the problem is that 'configure' is probing your build architecture, and is coming up answers appropriate for that architecture, but then you are running on a different architecture. Given that md5sum fails, the first suspect would be WORDS_BIGENDIAN in lib/config.h. That is, I suspect that WORDS_BIGENDIAN should have different values on your different architectures. To help debug this, can you please try modifying your lib/config.h by replacing these lines: /* Define to 1 if your processor stores words with the most significant byte first (like Motorola and SPARC, unlike Intel and VAX). */ /* #undef WORDS_BIGENDIAN */ with these lines: /* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most significant byte first (like Motorola and SPARC, unlike Intel and VAX). */ #if defined __BIG_ENDIAN__ # define WORDS_BIGENDIAN 1 #elif ! defined __LITTLE_ENDIAN__ /* #undef WORDS_BIGENDIAN */ #endif and then do a make clean; make? Then you can do a make check on both architectures. I will CC: this to bug-gnulib and bug-autoconf to give people a heads-up on this issue. In general the build != execute problem is a severe one with lots of issues, but for the particular combination of Power Mac and Intel this may be the only issue for coreutils. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.8 does not compile
The same goes for sha1sum btw - I guess all the hashing programs are affected, although i have no way to check the rest. $gsha1sum coreutils-6.8.tar.bz2 3a0f19f9df04d22f51a8f36a25169a91f0a97256 coreutils-6.8.tar.bz2 $openssl sha1 coreutils-6.8.tar.bz2 SHA1(coreutils-6.8.tar.bz2)= 83b221bfb030489c3c9abf705592f9a78ea0fbec Regards, Elias Pipping ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Building universal binaries makes 'check' fail
Hello, since I only own one machine (a ppc mac) that's the only platform i can test on. Modifying config.h the way you described has these effects, though: * make check completes without any errors * the output of md5sum matches the output of openssl's md5. Regards, Elias Pipping On Feb 28, 2007, at 12:32 AM, Paul Eggert wrote: In http://lists.gnu.org/archive/html/bug-coreutils/2007-02/ msg00290.html Elias Pipping [EMAIL PROTECTED] writes: The actual problem (while these binaries work flawlessly for me) is that 'make check' fails (see cmd_output_tail) Most likely the problem is that 'configure' is probing your build architecture, and is coming up answers appropriate for that architecture, but then you are running on a different architecture. Given that md5sum fails, the first suspect would be WORDS_BIGENDIAN in lib/config.h. That is, I suspect that WORDS_BIGENDIAN should have different values on your different architectures. To help debug this, can you please try modifying your lib/config.h by replacing these lines: /* Define to 1 if your processor stores words with the most significant byte first (like Motorola and SPARC, unlike Intel and VAX). */ /* #undef WORDS_BIGENDIAN */ with these lines: /* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most significant byte first (like Motorola and SPARC, unlike Intel and VAX). */ #if defined __BIG_ENDIAN__ # define WORDS_BIGENDIAN 1 #elif ! defined __LITTLE_ENDIAN__ /* #undef WORDS_BIGENDIAN */ #endif and then do a make clean; make? Then you can do a make check on both architectures. I will CC: this to bug-gnulib and bug-autoconf to give people a heads-up on this issue. In general the build != execute problem is a severe one with lots of issues, but for the particular combination of Power Mac and Intel this may be the only issue for coreutils. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
