GNU bug report logs - #22624
[bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd

Previous Next

Package: coreutils;

Reported by: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>

Date: Wed, 10 Feb 2016 21:59:02 UTC

Severity: normal

Tags: fixed

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #23 received at 22624 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, "Nelson H. F. Beebe"
 <beebe <at> math.utah.edu>
Cc: sysstaff <at> math.utah.edu, 22624 <at> debbugs.gnu.org
Subject: Re: bug#22624: [bug-coreutils] coreutils-8.25: big success, but
 problem on GNU/Hurd
Date: Thu, 11 Feb 2016 20:13:27 -0800
On 11/02/16 09:43, Paul Eggert wrote:
> On 02/11/2016 08:10 AM, Nelson H. F. Beebe wrote:
>> end_offset=9223372036854775807
>>
> 
> Thanks, that confirms my suspicions about GNU/Hurd. I'm attaching a 
> proposed patch; please give it a try if you have a chance. Turned out to 
> be trickier than I thought, but oh well.

Thanks for working on this.
The changes look good, except for this:

  $ seq 1000 | split -n4
  $ seq 100000 | split -n4
  split: -: cannot determine file size: Illegal seek

I.E. it would be better to indicate immediately
if there is an issue determining the file size,
because it's a gotcha that may hit users as data increases,
and -n is complex enough anyway, that it's better to
do as much checking up front as possible.
I'd still disallow this case even for -n1 in case the
number was parameterized to number of CPUs or whatever.

A small point on the tests is that we use `returns_ 1 ... || fail=1`
rather than `... && fail=1` so that we catch seg faults etc. in tests.

thanks!
Pádraig




This bug report was last modified 6 years and 251 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.