bug#11424: coreutils: split tests hang on /dev/zero on GNU/Hurd

2012-05-07 Thread Jim Meyering
Samuel Thibault wrote: Since some time, coreutils fails in split tests on GNU/Hurd. More precisely, these two: split/filter:55 split --filter=head -c1 /dev/null -n 1 /dev/zero split/l-chunk:39 split -n l/2 /dev/zero It seems that these two tests assume that split will stop by itself when

bug#11424: coreutils: split tests hang on /dev/zero on GNU/Hurd

2012-05-07 Thread Paul Eggert
Thanks, here's a quick cut at a patch to 'split' to fix the problem. Also, the test cases also need to be adjusted, so as not to attempt to split -n on a device. diff --git a/src/split.c b/src/split.c index 99f6390..8b966bc 100644 --- a/src/split.c +++ b/src/split.c @@ -1344,7 +1344,9 @@ main

bug#11424: coreutils: split tests hang on /dev/zero on GNU/Hurd

2012-05-07 Thread Paul Eggert
On 05/07/2012 12:46 AM, Jim Meyering wrote: + + /* stat.st_size is valid only for regular files. For others, use 0. */ + file_size = S_ISREG (stat_buf.st_mode) ? stat_buf.st_size : 0; Is it right to use 0 there, for non-regular files? Won't later code compute incorrect sizes in that case?

bug#11424: coreutils: split tests hang on /dev/zero on GNU/Hurd

2012-05-07 Thread Jim Meyering
Paul Eggert wrote: On 05/07/2012 12:46 AM, Jim Meyering wrote: + + /* stat.st_size is valid only for regular files. For others, use 0. */ + file_size = S_ISREG (stat_buf.st_mode) ? stat_buf.st_size : 0; Is it right to use 0 there, for non-regular files? Won't later code compute

bug#11100: Racy code in copy.c

2012-05-07 Thread Philipp Thomas
* Jim Meyering (j...@meyering.net) [20120504 17:30]: If there's a bugzilla reference for this, let me know and I'll add it to the commit log. There is, but as it's a SLES bug it's only open for SUSE employees and customers and thus useless for a coreutils commit log. I'll instead reference the

bug#11100: Racy code in copy.c

2012-05-07 Thread Jim Meyering
Philipp Thomas wrote: * Jim Meyering (j...@meyering.net) [20120504 17:30]: If there's a bugzilla reference for this, let me know and I'll add it to the commit log. There is, but as it's a SLES bug it's only open for SUSE employees and customers and thus useless for a coreutils commit log.

bug#11427: cp 8.16 not writing through, writing over

2012-05-07 Thread Karl Berry
Create dangling symlink: $ ln -s foo bar Attempt to write over it with cp: $ \cp -i /etc/issue bar cp: not writing through dangling symlink 'bar' In the past, it would ask me if I wanted to replace bar. (As desired.) The error message makes me think that it is thinking I am writing through a

bug#11429: regarding conflict type error in compilation process

2012-05-07 Thread mahesh gadde
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. thanksregards mahesh

bug#11427: cp 8.16 not writing through, writing over

2012-05-07 Thread Jim Meyering
Karl Berry wrote: Create dangling symlink: $ ln -s foo bar Attempt to write over it with cp: $ \cp -i /etc/issue bar cp: not writing through dangling symlink 'bar' In the past, it would ask me if I wanted to replace bar. (As desired.) Hi Karl, When I try that in an empty directory and

bug#11429: regarding conflict type error in compilation process

2012-05-07 Thread Paul Eggert
Could you give more details about your problem? Please start by saying what source code you downloaded, what system you're using (hardware and software), what commands you ran, and exactly what the failed output was.