http://permalink.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://permalink.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://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24356 <pre>2012/5/22 Pádraig Brady &lt;P&lt; at &gt;draigbrady.com&gt; I can write a patch that would let you choose, what to do on write errors. Currently, I can't understand, why previous patch (in thread you pointed out) is not in tee. I'm not familiar with POSIX, so I appreciate any guidance in what should I do next. What should I read and implement to make tee continuing writing files faster receiving error on writing to a pipe? </pre> Igor Ippolitov 2012-05-23T13:25:17 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24355 <pre> I just looked at a recent proposal that overlaps with the above nicely: http://lists.gnu.org/archive/html/coreutils/2012-05/msg00070.html cheers, Pádraig. </pre> Pádraig Brady 2012-05-22T17:32:41 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24354 <pre> I checked back and there was a very similar patch nearly 4 years ago. http://lists.gnu.org/archive/html/bug-coreutils/2008-10/msg00067.html I think there was general agreement in the thread on its merits. I wonder though, would a higher level option be more appropriate? I think what's being configured here is whether to exit early on write error, whether it is to one of the files or stdout. Why would you want to treat them differently? Also you could get SIGPIPEs I think if one of the files was &gt;(a process). The default would be to diagnose write errors, and that could be changed with: --write-error={[cont],ignore,exit} cheers, Pádraig. </pre> Pádraig Brady 2012-05-22T17:18:31 http://permalink.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://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24352 <pre> Thanks. I'm about to push that: commit 974848a4866f71c10e854a4d4a2e9b26a4db6a7b Author: Mike Frysinger &lt;vapier&lt; at &gt;gentoo.org&gt; Date: Thu May 17 00:00:11 2012 -0400 dircolors: add st/st-256color terminal types 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;, via Mike Frysinger &lt;vapier&lt; at &gt;gentoo.org&gt; in http://bugs.gnu.org/11498 </pre> Jim Meyering 2012-05-21T15:03:36 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24351 <pre> Wow! That's a good one. Yes, the behavior is intended, though, as I mentioned, there's been some consideration to adding a flag or two that would generate different output here. </pre> Paul Eggert 2012-05-21T07:29:12 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24350 <pre>On second thought, maybe this additional verbiage would be misleading because (1) the same kind of thing can happen even when not using -s, and (2) -c doesn't have to be used with -s to determine the total size of the total disk usage of a given set of files or directories. In any case, even though the varying output for -s is understandable, behavior like the following seems counterintuitive: $ mkdir foo foo/bar $ du foo foo/bar 4foo/bar 8foo $ du foo/bar foo 4foo/bar 4foo Is this intended? Apologies if I'm asking something obvious. On Sun, May 20, 2012 at 10:50 PM, Chris Marusich &lt;cmmarusich&lt; at &gt;gmail.com&gt; wrote: </pre> Chris Marusich 2012-05-21T07:24:05 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24349 <pre>After reviewing the manual more closely, it seems I would have gotten the behavior I expected with du -sl. What do you think about updating the documentation to read as follows? ‘-s’ ‘--summarize’ Display only a summary of the arguments. Unless -l is also specified, not all arguments will necessarily appear in the output (e.g., du -s foo foo/bar will not output a line for foo/bar), and not every size printed next to a directory in the output will necessarily reflect the total size of that directory including its contents (e.g., du -s foo/bar foo will output the total size of foo including its contents minus the size of foo/bar). This behavior is POSIX-compliant and allows us to use -c to get an idea of the total size of all the arguments taken together. The last line could perhaps be optional. I'd just like the docs to have a clear explanation that helps prevent future confusion. On Sun, May 20, 2012 at 5:29 PM, Paul Eggert &lt;eggert&lt; at &gt;cs.ucla.edu&gt; wrote: </pre> Chris Marusich 2012-05-21T05:50:27 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24348 <pre> We could change that "total" to "summary". The --help output (man page) currently doesn't discuss this issue in detail, because it's not really set up for long discussions. There is something in the manual about this, if that helps. </pre> Paul Eggert 2012-05-21T00:29:34 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24347 <pre>Thanks for your reply. I've read the thread and understand that the intended behavior is not to double-count nodes so we can get an accurate feel of the total size of the output of du -s by summing the sizes together. However, the behavior contrasts with the description of -s ("display only a total for each argument" on my system), so perhaps the documentation should be updated? While it may be intuitive not to double-count a given directory, I don't think the current description of -s makes it clear that the size reported for a directory might be greater than 0 but less than the actual size of the directory and all its contents (i.e. in the case where one of its subdirectory was counted earlier). It should be made clear that the numbers before each directory may in fact NOT be the actual size of each directory, because that's what the description for -s seems to say now. On Sun, May 20, 2012 at 2:17 PM, Paul Eggert &lt;eggert&lt; at &gt;cs.ucla.edu&gt; wrote: </pre> Chris Marusich 2012-05-20T22:18:24 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24346 <pre>forcemerge 10282 11526 thanks Thanks, but this behavior is expected and is not a bug. We have been looking into ways of addressing the issue, though there's nothing currently active in this area. For more, please see &lt;http://bugs.gnu.org/10282&gt;. </pre> Paul Eggert 2012-05-20T21:17:24 http://permalink.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://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24344 <pre> Well there are a few things going on here. -d will exclude '.' but include ' ' -f is redundant with -d as -d is a subset of -f (I think) Also your locale make exclude punctuation chars from the search. I.E. cause ' ' to be disregarded in the sort. Now with -d, sort will not treat '.' and ' ' equivalently, or sort in ASCII order. So you have 2 options I think: tr '.' ' ' &lt; due | LANG=C sort -di -k1.11,1.39 &gt; due.sorted LANG=C sort -i -k1.11,1.39 -o due due The former will convert '.' to ' ', while the latter will include non dictionary chars in the sort. cheers, Pádraig. </pre> Pádraig Brady 2012-05-19T10:31:22 http://permalink.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://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24342 <pre>Pádraig Brady: I don't think it does. I think it doesn't know anything about fputs at all, so it tries to guess. If there is something that looks like a printf directive in the message, it is guessed to be c-format, otherwise not. In a simple test I found that fputs(_("Hello world"), stdout); is not considered c-format, but fputs(_("Hello %orld"), stdout); is. If I use printf instead of fputs, it is considered c-format in both cases. xgettext does know by default that printf's first argument is c-format. :-) I actually also sent a message to that list a little while ago, suggesting they add flags by default for the other stdio functions. (puts, fputs and fwrite came to mind) </pre> Göran Uddeborg 2012-05-17T18:39:48 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24341 <pre> Why does xgettext even think fputs takes a printf format? That's the real bug here right? I know we have to deal with the bug in the meantime with something like the above, but I've CC'd the gettext bug list so that we won't have to worry about it going forward. cheers, Pádraig. </pre> Pádraig Brady 2012-05-17T18:22:20 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24340 <pre>A possibly more general fix would be to tell xgettext that fputs' argument is not c-format. That would catch all uses of fputs. Something like this: --- po/Makevars~ 2012-05-10 11:05:30.000000000 +0200 +++ po/Makevars 2012-05-17 20:06:13.000000000 +0200 &lt; at &gt;&lt; at &gt; -18,6 +18,7 &lt; at &gt;&lt; at &gt; --flag=asprintf:2:c-format\ --flag=error:3:c-format\ --flag=error_at_line:5:c-format\ + --flag=fputs:1:no-c-format\ --flag=vasnprintf:3:c-format\ --flag=vasprintf:2:c-format\ --flag=verror:3:c-format\ </pre> Göran Uddeborg 2012-05-17T18:07:58 http://permalink.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://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24338 <pre>forcemerge 11470 11494 thanks On 05/16/2012 04:48 PM, Ivan Vilata i Balaguer wrote: Thanks for the report; however, you're the fifth person to report this in 48 hours, and it has already been fixed in current git: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e2bd5cda0a34 </pre> Eric Blake 2012-05-16T23:10:13 http://permalink.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 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gnu.core-utils.bugs