Re: coreutils-5.94 imminent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 2/9/2006 1:56 AM: I'm hoping to release coreutils-5.94 soon. If anyone sees something on the trunk that they want but that's not yet in 5.94, please speak up now. So far, my policy has been to apply only bug fixes. Whatever happened to this thread: http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00285.html The question was whether mv a b/ failing when a is a directory and b does not exist, which is a regression from 5.2.1, should be fixed in 5.94. The thread spans month boundaries, but never seemed to reach any solid conclusions. However, I am inclined to believe that rename(a, b/) is ambiguous of whether it should succeed in the same situation, and that mv a b/ should succeed if the underlying rename(2) can do so. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8JF584KuGfSFAYARAkBuAJ47EBEGTWZCP3A9BLQRUFA2odvyGACfQyEh 3i3Shc08kRDwTESaCcyEvB4= =O/5I -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Minor patch
Hello,
Here's a little patch about some memory leaks found with valgrind, on
sort, tail and uptime.
Best regards,
Charles Longeau
Index: src/sort.c
===
RCS file: /sources/coreutils/coreutils/src/sort.c,v
retrieving revision 1.335
diff -u -r1.335 sort.c
--- src/sort.c 14 Dec 2005 23:59:23 - 1.335
+++ src/sort.c 30 Jan 2006 00:06:12 -
@@ -2293,7 +2293,8 @@
gkey.month = gkey.reverse = false;
gkey.skipsblanks = gkey.skipeblanks = false;
- files = xnmalloc (argc, sizeof *files);
+ if (argc 1)
+files = xnmalloc (argc-1, sizeof *files);
for (;;)
{
@@ -2599,6 +2600,8 @@
else
sort (files, nfiles, outfile);
+ free(temp_dirs);
+
if (have_read_stdin fclose (stdin) == EOF)
die (_(close failed), -);
Index: src/tail.c
===
RCS file: /sources/coreutils/coreutils/src/tail.c,v
retrieving revision 1.248
diff -u -r1.248 tail.c
--- src/tail.c 24 Jan 2006 10:32:32 - 1.248
+++ src/tail.c 30 Jan 2006 00:06:12 -
@@ -1675,6 +1675,8 @@
if (forever)
tail_forever (F, n_files, sleep_interval);
+ free(F);
+
if (have_read_stdin close (STDIN_FILENO) 0)
error (EXIT_FAILURE, errno, -);
exit (ok ? EXIT_SUCCESS : EXIT_FAILURE);
Index: src/uptime.c
===
RCS file: /sources/coreutils/coreutils/src/uptime.c,v
retrieving revision 1.54
diff -u -r1.54 uptime.c
--- src/uptime.c 3 Dec 2005 23:24:46 - 1.54
+++ src/uptime.c 30 Jan 2006 00:06:12 -
@@ -166,6 +166,7 @@
error (EXIT_FAILURE, errno, %s, filename);
print_uptime (n_users, utmp_buf);
+ free(utmp_buf);
}
void
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Maybe a bug
DecimalHi, I used du in 2 formats, and the number os bytes doesn't correspond to the number os megabytes. Shouldn't i have another value for the 2du -sb ? The value for the du -sm is the correct value. Jorge Bastos flecha:/home/alojamento/inducar.pt# du -sb . 80066621. flecha:/home/alojamento/inducar.pt# du -sm . 120 . ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-5.94 imminent
Shouldn't it be made consistent? IMHO, the command mv a b/ means move the file or directory named a into the directory named b, so if b does not exist or is not a directory, it should fail. If you want to make mv deviate from this behavior, then at least shouldn't it behave the same on all platforms, without depending on the implementation of rename()? Jim Meyering wrote: Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 2/9/2006 1:56 AM: I'm hoping to release coreutils-5.94 soon. If anyone sees something on the trunk that they want but that's not yet in 5.94, please speak up now. So far, my policy has been to apply only bug fixes. Whatever happened to this thread: http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00285.html Thanks for bringing that up. In spite of saying I wanted to fix it for 5.94, I decided to let it wait. The probable fix and tests seem complicated/risky enough that I'd prefer to release 5.94 now. For example, the tests will have to be dependent on how rename works, and will have to ensure that e.g., rm -rf a b; touch a; mv a b/ still fails on systems with a rename syscall that honors trailing slashes. I'd rather see such changes made to the trunk first, and get some exposure through a test release. Besides, no one volunteered to do the work ;-) The code changes are trivial. Writing tests and changing documentation will take more time. The fact that changing this part of mv induces no failure (on Linux) in the test suite is a sure indication we need more tests. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Maybe a bug
Jorge Bastos - Decimal [EMAIL PROTECTED] writes: I used du in 2 formats, and the number os bytes doesn't correspond to the number os megabytes. As du --help explains, du -b is not the same thing as du --block-size=1. It also sets the --apparent-size option, which explains the discrepancy you observed. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Minor patch
Charles Longeau [EMAIL PROTECTED] writes: Here's a little patch about some memory leaks found with valgrind, on sort, tail and uptime. The changes that you propose will slow the programs down slightly and make them slightly bigger. The changes won't save any memory, since the programs in question are all about to exit. Isn't there a way to pacify valgrind without adversely affecting the programs? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Minor patch
Paul Eggert [EMAIL PROTECTED] wrote: Charles Longeau [EMAIL PROTECTED] writes: Here's a little patch about some memory leaks found with valgrind, on sort, tail and uptime. Thanks for the report, but those aren't really leaks. The changes that you propose will slow the programs down slightly and make them slightly bigger. The changes won't save any memory, since the programs in question are all about to exit. Isn't there a way to pacify valgrind without adversely affecting the programs? IMHO, there is no need to pacify valgrind. It already makes it clear that those blocks of memory are not `lost'. For example, with uptime, here's valgrind's summary: $ valgrind uptime /var/run/utmp ... 8:37pm up 8 days 22:45, 22 users, load average: 0.05, 0.05, 0.06 ==16639== ==16639== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1) ==16639== malloc/free: in use at exit: 24,576 bytes in 1 blocks. ==16639== malloc/free: 18 allocs, 17 frees, 52,298 bytes allocated. ==16639== For counts of detected errors, rerun with: -v ==16639== searching for pointers to 1 not-freed blocks. ==16639== checked 80,896 bytes. ==16639== ==16639== LEAK SUMMARY: ==16639==definitely lost: 0 bytes in 0 blocks. ==16639== possibly lost: 0 bytes in 0 blocks. ==16639==still reachable: 24,576 bytes in 1 blocks. ==16639== suppressed: 0 bytes in 0 blocks. ==16639== Reachable blocks (those to which a pointer was found) are not shown. ==16639== To see them, rerun with: --show-reachable=yes The block in question is the `still reachable' one. I've debated for years whether to free such memory. On one hand, it's not technically necessary, but on the other, doing so reassures people who take the time to perform an audit. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: od swap support?
Paul Eggert wrote: Paul A. Clarke [EMAIL PROTECTED] writes: Is there any interest in adding a flag to od to support byteswapping? Would dd conv=swab | od suffice? No. dd conv=swab only swaps byte pairs, thus 32bit or 64bit structured data will not appear correctly unswapped: (GenuineIntel)# dd conv=swab if=endiana | od -tx4 0+1 records in 0+1 records out 000 63646162 004 (Power5) od -tx4 endiana 000 61626364 004 However, you have a point in that perhaps this enhancement should instead be targeted at the dd command instead of od. Thoughts? Regards, Paul ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils-5.94 released [stable]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The GNU coreutils package contains the following programs: [ basename cat chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold ginstall groups head hostid hostname id join kill link ln logname ls md5sum mkdir mkfifo mknod mv nice nl nohup od paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir seq sha1sum shred sleep sort split stat stty su sum sync tac tail tee test touch tr true tsort tty uname unexpand uniq unlink uptime users vdir wc who whoami yes The coreutils package replaces/unifies the fileutils, sh-utils, and textutils packages. This is a stable release, in spite of the `feature changes' below. For a summary of changes since 5.93, see below. Thanks to everyone else who contributed changes (attributions are in the ChangeLog files), reported problems, and helped by fielding questions on the mailing list. Here are the compressed sources: ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.94.tar.gz (7.6MB) ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.94.tar.bz2 (4.9MB) Here are the xdelta-style diffs: ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.93-5.94.xdelta (645KB) Here are the GPG detached signatures[*]: ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.94.tar.gz.sig ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.94.tar.bz2.sig Here are the MD5 and SHA1 checksums: fbb01f04e57edd8ae003db3bcd49f86a coreutils-5.94.tar.gz 11985c8345371546da8ff13f7efae359 coreutils-5.94.tar.bz2 7a891edca98aed8c1ddedf1d8cbb5f4b coreutils-5.93-5.94.xdelta 243a9c1b65877246e7d9d21d87c21cb35e90ef63 coreutils-5.94.tar.gz c39add02995304e1cf3dfc8543702f22155fba50 coreutils-5.94.tar.bz2 0a4ef4e0da3cfade03c1bd141e9a5e8e466ddb0b coreutils-5.93-5.94.xdelta [*] You can use either of the above signature files to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify coreutils-5.94.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver wwwkeys.pgp.net --recv-keys D333CBA1 and rerun the `gpg --verify' command. NEWS * Major changes in release 5.94 (2006-02-13) [stable] ** Feature changes df now considers none and proc file systems to be dummies and therefore does not normally display them. Also, inaccessible file systems (which can be caused by shadowed mount points or by chrooted bind mounts) are now dummies, too. stat's --format=FMT option now works the way it did before 5.3.0: FMT is automatically newline terminated. The first stable release containing this change was 5.92. stat accepts the new option --printf=PFMT, where PFMT is *not* automatically newline terminated. Backslash escapes in PFMT *are* interpreted. stat: backslash escapes are interpreted in a format string specified via --printf=FMT, but not one specified via --format=FMT. That includes octal (\ooo, at most three octal digits), hexadecimal (\xhh, one or two hex digits), and the standard sequences (\a, \b, \f, \n, \r, \t, \v, \, \\). ** Bug fixes When `cp -RL' encounters the same directory more than once in the hierarchy beneath a single command-line argument, it no longer confuses them with hard-linked directories. fts-using tools (chmod, chown, chgrp, du) no longer fail due to a double-free bug -- it could be triggered by making a directory inaccessible while e.g., du is traversing the hierarchy under it. fts-using tools (chmod, chown, chgrp, du) no longer misinterpret a very long symlink chain as a dangling symlink. Before, such a misinterpretation would cause these tools not to diagnose an ELOOP error. sort would fail for large inputs (~50MB) on systems with a buggy mkstemp function. sort and tac now use the replacement mkstemp function, and hence are no longer subject to limitations (of 26 or 32, on the maximum number of files from a given template) on HP-UX 10.20, SunOS 4.1.4, Solaris 2.5.1 and OSF1/Tru64 V4.0FV5.1. tail -f once again works on a file with the append-only attribute (affects at least Linux ext2, ext3, xfs file systems) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD8Yfn/dLerNMzy6ERAraAAKDBodLL2w/Dk4urlM6luQX/TW0uHwCgjdHK YZZ80B4jtypxQucwvCls3KY= =mb22 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
