http://blog.gmane.org/gmane.comp.gnu.core-utils.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24357 <pre>Hi, md5sum was made line buffered sometime back. However, cksum was left out of that patch. I tried running the following test on my machine for cksum, on the lines of test for md5sum, given in bug archives at: http://lists.gnu.org/archive/html/bug-coreutils/2009-10/msg00190.html. The test failed. Shouldn't cksum too be made line buffered? anoop&lt; at &gt;Aspire:~$ find / -type f 2&gt;/dev/null | xargs -P2 -n 50 cksum 2&gt;/dev/null | sed -n '/^[0-9]\{1,\} [0-9]\{1,\}/!p' decs/snd-soc-da7210.ko 24-generic/kernel/drivers/staging/comedi/drivers/pcm3724.ko /modules/3.2.0-24-generic/kernel/drivers/staging/comedi/drivers/pcmad.ko a/video/gspca/gspca_spca1528.ko el/drivers/staging/comedi/drivers/c6xdigio.ko /dvb-usb-gl861.ko nel/drivers/media/common/tuners/tda18271.ko vers/media/rc/ite-cir.ko ^C anoop&lt; at &gt;Aspire:~$ ^C Thanks, Anoop </pre> Anoop Sharma 2012-05-25T19:23:34 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24353 <pre>From 89c055b385a9d4f4804af6b7b3fbe67651471613 Mon Sep 17 00:00:00 2001 From: Ippolitov A. Igor &lt;iippolitov&lt; at &gt;gmail.com&gt; Date: Tue, 22 May 2012 17:58:23 +0400 Subject: [PATCH] tee: add a flag to ignore SIGPIPE * src/tee.c: added ignore_sigpipes variable and -p and --ignore-sigpipes options If we call tee like: program | tee file1 file2 | head -3 just to be sure there some output from program started. Or like: program | tee &gt;(head -1) file1 file2 We'll get SIGPIPE on writing to a file. It can be undesirable behaviour: file1 and file2 would be incomplete. Running with -i won't correct this. "-p|--ignore-sigpipes" options will make tee ignore any sigpipe it can receive. So file1 and file2 would have complete output. --- src/tee.c | 19 ++++++++++++++++++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/src/tee.c b/src/tee.c index 2d82577..0021174 100644 --- a/src/tee.c +++ b/src/tee.c &lt; at &gt;&lt; at &gt; -43,10 +43,14 &lt; at &gt;&lt; at &gt; static bool append; /* If true, ignore interrupts. */ static bool ignore_in</pre> Igor Ippolitov 2012-05-22T14:00:39 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24345 <pre>BUG DESCRIPTION: If you pass multiple arguments to du -s and the first of those argument is . (the current directory), then du will only output the size of the first argument. This bug is reproducible in version 8.13 on Ubuntu 12.04 LTS (this is currently the latest version for Ubuntu 12.04 LTS) as follows. However, it works properly in version 7.4 on Ubuntu 10.04.3 LTS. An acquaintance has confirmed that the bug also occurs with du 8.16 and 8.17 (currently the latest coreutils version) on Arch Linux. EXAMPLE, DU DOESN'T WORK: chris&lt; at &gt;shmion:~/foo$ mkdir foo bar ; ls -al total 16 drwxrwxr-x 4 chris chris 4096 May 19 23:24 . drwxr-xr-x 42 chris chris 4096 May 19 22:04 .. drwxrwxr-x 2 chris chris 4096 May 19 23:24 bar drwxrwxr-x 2 chris chris 4096 May 19 23:24 foo chris&lt; at &gt;shmion:~/foo$ strace -odu.log du -s . foo bar 20 . chris&lt; at &gt;shmion:~/foo$ lsb_release -d Description: Ubuntu 12.04 LTS chris&lt; at &gt;shmion:~/foo$ du --version | head -n 1 du (GNU coreutils) 8.13 chris&lt; at &gt;shmion:~/foo$ cat du.log execve("/usr/bin</pre> Chris Marusich 2012-05-20T07:41:24 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24343 <pre>Dear Sir, By using the following sort command to sort the input file due, the output due is showing as : sort -dfi -k1.11,1.39 -odue due 123180024 BIJJALA ESWARA RAO 1580.50 061233693 BIJJALA JANARDHAN RAO 2280.00 123812394 BIJJALA VENKATESWAR RAO 1682.50 123349123 BIRJALA JANARDHAN RAO 2794.20 123712310 B.KRISHNA MURTHY 2362.50 123234123 B MUTHAIAH 1727.00 038123230 B NAGESWAR RAO 1625.00 121237123 BODA VIJAYA 2827.00 041237267 BODDU APPAIAH 485.60 123123361 BODDU SRINIVASA RAO 4540.00 012316123 BODDU VEERA SWAMY 1527.50 Sorting was on name order (i.e. position 11 to 39) After 4 records i.e after BIRJALA JANARDHAN RAO, we find B.KRISHNA MURTHY where as B.KRISHNA MUTHY, B MUTHAIAH, B NAGESWAR RAO come first in sorted order , kindly guide us. "The information contained in this electronic message and any attachments to this message ar</pre> e.sambasivarao 2012-05-19T04:40:11 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24339 <pre>See http://st.suckless.org/ * src/dircolors.hin: Add st and st-256color. Reported-by: Jeroen Roovers &lt;jer&lt; at &gt;gentoo.org&gt; Signed-off-by: Mike Frysinger &lt;vapier&lt; at &gt;gentoo.org&gt; --- src/dircolors.hin | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/dircolors.hin b/src/dircolors.hin index 4606d1a..316c212 100644 --- a/src/dircolors.hin +++ b/src/dircolors.hin &lt; at &gt;&lt; at &gt; -52,6 +52,8 &lt; at &gt;&lt; at &gt; TERM screen-w TERM screen.Eterm TERM screen.rxvt TERM screen.linux +TERM st +TERM st-256color TERM terminator TERM vt100 TERM xterm </pre> Mike Frysinger 2012-05-17T04:00:11 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24337 <pre>Hi, in coreutils 8.17 (and in current git), `fmt.c` contains the following help line: -g, --goal=WIDTH goal width (default of 93% of width) The percent is interpreted (at least by `msgfmt`) as the start of a `%o` format string, thus translations are forced to have an "o" after `93%` which makes things quite difficult. ;) Changing `93%` by `93%%` should do the job. Thanks, </pre> Ivan Vilata i Balaguer 2012-05-16T22:48:37 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24335 <pre>rehello, That's ok, my problem come from new line. echo "è" | base64 is: "è\n" | base64 and:echo -n "è" | base64 works better. base64 (GNU coreutils) 8.5 Thanks Thomas. </pre> Marsaleix Thomas 2012-05-16T13:25:26 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24334 <pre>Hello, Base64 encode 'è' with '6Ao='. After différents test I find '6A==', In base16, 'è'==E8. in binary string, 'è'=11101000 (== 256) 111010=(decimal:) 58=(base64:)6 000000=(decimal:) 0=(base64:)0 base64 (GNU coreutils) 8.5 Cordialement Thomas. </pre> Marsaleix Thomas 2012-05-16T12:58:35 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24331 <pre>Hello, Coreutils 8.17 introduced a small change in the message catalogue which causes considerable problems to translators. The part which causes problems is: #: src/fmt.c:285 #, c-format msgid "" " -t, --tagged-paragraph indentation of first line different from second\n" " -u, --uniform-spacing one space between words, two after sentences\n" " -w, --width=WIDTH maximum line width (default of 75 columns)\n" " -g, --goal=WIDTH goal width (default of 93% of width)\n" msgstr "" Apparently, msgfmt interprets "% o" in the help text of the --goal option as a format specifier. This means that the translations will be rejected unless the translation also contains the same sequence: % being followed by a space, being followed by a small o. All the best, Primož </pre> Primoz PETERLIN 2012-05-15T19:57:07 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24321 <pre>Hello, coreutils-8.17 contains this message: #: src/fmt.c:285 #, c-format msgid "" " -t, --tagged-paragraph indentation of first line different from second\n" " -u, --uniform-spacing one space between words, two after sentences\n" " -w, --width=WIDTH maximum line width (default of 75 columns)\n" " -g, --goal=WIDTH goal width (default of 93% of width)\n" The message is detected by xgettext as C formatted string because of the percentage character. The problem is such string does not pass through msgfmt tool while compiling the catalog because the '% ' is not a valid printf sequence. Solution is to suppress the auto-detection by adding /*xgettext:no-c-format*/ before the fputs() line in the source code. </pre> Petr Pisar 2012-05-14T19:27:42 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24319 <pre>This message in the 8.17 message file is written using fputs(), but it is anyway marked as c-format. This is a problem since the % sign in the description of --goal is taken as a formatting directive (of an unsigned int written in octal, with the "space" flag). This causes problems when translating. The effect of the validation of the translation complains if the word following the percent sign doesn't start with an "o", or other letter which is "compatible" in printf's sense. (And in Swedish I would like it to start with an "a".) #: src/fmt.c:285 #, c-format msgid "" " -t, --tagged-paragraph indentation of first line different from second\n" " -u, --uniform-spacing one space between words, two after sentences\n" " -w, --width=WIDTH maximum line width (default of 75 columns)\n" " -g, --goal=WIDTH goal width (default of 93% of width)\n" </pre> Göran Uddeborg 2012-05-14T18:15:59 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24317 <pre> hi! the entry: #: src/fmt.c:285 #, c-format msgid "" " -t, --tagged-paragraph indentation of first line different from second\n" " -u, --uniform-spacing one space between words, two after sentences\n" " -w, --width=WIDTH maximum line width (default of 75 columns)\n" " -g, --goal=WIDTH goal width (default of 93% of width)\n" has unescaped %. the sequence "% o" will be interpreted by printf and it would expect an argument... and obviously the msgfmt will choke as well. toomas </pre> Toomas Soome 2012-05-14T17:22:19 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24310 <pre>Hi, I've been running parfait [1] on GNU coreutils and it found the following problems: Error: Buffer overrun Buffer overflow (CWE 120): In array dereference of word_limit[-1] with index '-1' Array size is 1000 elements (of 28 bytes each), -1 is -1 at line 590 of components/coreutils/coreutils-8.5/src/fmt.c in function 'get_paragraph'. Read outside array bounds (CWE 125): In array dereference of word_limit[-1] with index '-1' Array size is 1000 elements (of 28 bytes each), -1 is -1 at line 590 of components/coreutils/coreutils-8.5/src/fmt.c in function 'get_paragraph'. Error: Null pointer dereference (CWE 476) Read from null pointer 's' at line 3389 of components/coreutils/coreutils-8.5/src/sort.c in function 'main'. Function 'parse_field_count' may return constant 'NULL' at line 3130, called at line 3387. Null pointer introduced at line 3130 in function 'parse_field_count'. Error: Null pointer dereference (CWE 476) Read from n</pre> Rich Burridge 2012-05-14T12:25:09 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24296 <pre>coreutils-8.16 works fine (confirmed), and i don't recall seeing this bug before, so looks like a regression with 8.17 easy to show: $ sudo ln -s dev /foo $ ls --color=auto / ... foo wrongly shows up in blinky text indicating it's a broken symlink ... $ ls --color=auto /. ... foo correctly shows up with normal coloring indicating it's a symlink ... $ cd / ; ls --color=auto ... foo correctly shows up with normal coloring indicating it's a symlink ... -mike </pre> Mike Frysinger 2012-05-11T18:11:54 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24290 <pre>Hi. Using cp, one can for example execute cp foo/bar.txt /tmp/foo/ to have /tmp/foo/bar.txt in place after a successful copy operation, provided the directory /tmp/foo exists. If it does not, one has to mkdir it beforehand naturally. I thought that using `install -D` would remedy this, however found that, in coreutils up to including 8.16, install -D foo/bar.txt /tmp/foo/ is not implemented - the program returns the error install: target `/tmp/foo/' is not a directory: No such file or directory On the other hand, the following command succeeds: install -D foo/bar.txt /fmp/foo/bar.txt Specifying the file's basename again on the target side argument (/tmp/foo/bar.txt) seems redundant, given install is "just a spruced-up cp". Would you consider enhancing install to support "/tmp/foo/"? thanks, Jan </pre> Jan Engelhardt 2012-05-11T01:15:11 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24277 <pre>Hello, there has been work by others about adding support for the OCFS2 "reflink" ioctl() call, which is similiar to the btrfs "clone" call, and creates a copy-on-write copy of the original, thus allowing to "copy" even gigabyte sized files within a tiny fraction of a second, and without using much additional file system space. See: http://lists.gnu.org/archive/html/coreutils/2011-08/msg00046.html http://lists.gnu.org/archive/html/bug-coreutils/2010-04/msg00185.html I have updated those patches to work against coreutils 8.16, removed those bugs, that I spotted. In particular, if the destination file exists, the "reflink" ist automatically tried again after removing it, and if not all attributes are copied, it is made sure, that the following open() system call does not truncate the just created copy. I strongly suggest including that patch in the coreutils package, even though the interface to use to different system calls to achieve the same thing is awkward. But, as laid out in the</pre> Kai Petzke 2012-05-09T14:28:27 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24266 <pre>Section 5 of the "INSTALL" file for coreutils says that "make installcheck" will repeat the self-checks, but using the binaries in their final installed locations. I cannot figure out what "make installcheck" is doing, but surely it is not doing that. It doesn't seem to even visit the final installed location of the binaries at all. I tried this against versions 8.16 (tarball), 8.14 (tarball), and the git HEAD, on both openSUSE 12.1 and on Cygwin. I do all the work as non-root, and for ./configure, I always specified a --prefix that specifies a not-currently-existent directory name within my home directory (and no other options) Thanks, Jeff </pre> Jeff Janes 2012-05-08T19:23:26 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24262 <pre>(From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670477 ) Hello, The misc/nice test currently fails on hurd-i386 because the nice support there is not precise enough: the Mach kernel, which handles scheduling priorities, has only 32 priority levels, and not 40, so conversion is used, but that becomes not precise enough for the misc/nice test. Apart from that, the nice tool works fine. Could you disable that test on hurd-i386? Samuel </pre> Samuel Thibault 2012-05-08T18:39:49 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24261 <pre>Hello, (From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670478 ) cp/parent-perm-race tries to copy a fifo with the --copy-contents option. The problem is that cp still uses O_NOFOLLOW in that case, strace shows: open("mode/fifo", O_RDONLY|O_NOFOLLOW) O_NOFOLLOW is actually normally meant for security, to avoid attacks through symlink redirection. In that case, the Hurd thus disables translators too, to avoid any rogue translator that would achieve the same kind attack as symlink redirection. But then --copy-contents can not work, since the fifo thus can not work (it's a translator that implements it). I don't think either the Hurd or coreutils will want to change their behavior, so could the test be disabled on GNU/Hurd? Samuel </pre> Samuel Thibault 2012-05-08T18:38:16 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24257 <pre>GNU sort doesn't like a really large value for the -S option. To recreate: First create a 5GB file of random data. $ /usr/bin/dd if=/dev/urandom of=input bs=1048576 count=5000 You can successfully sort it with: $ export LC_ALL='C' $ /usr/bin/sort input &gt;output But if you add a large -S option, you get: $ export LC_ALL='C' $ /usr/bin/sort -S 4G &lt;input &gt;output /usr/bin/sort: -S argument `4G' too large Reproduced with: sort version 8.13 on Ubuntu 12.04 LTS sort version 8.16 on Solaris 11 Thanks. </pre> Rich Burridge 2012-05-08T16:01:25 http://comments.gmane.org/gmane.comp.gnu.core-utils.bugs/24245 <pre>Hi, i am getting an error in compilation process in Linux environment,this error is like conflicting types for ablkcnt_ta and previous declaration of blkcnt_t was here in Linux envioronment.please give me the instructions to solve this problem. thanks&amp;regards mahesh </pre> mahesh gadde 2012-05-07T11:38:19 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gnu.core-utils.bugs