From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: Head command does not position file pointer correctly for negative line count Resent-From: Anoop Sharma Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 05 Jun 2012 09:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 11631@debbugs.gnu.org X-Debbugs-Original-To: bug-coreutils@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.133888922824590 (code B ref -1); Tue, 05 Jun 2012 09:41:01 +0000 Received: (at submit) by debbugs.gnu.org; 5 Jun 2012 09:40:28 +0000 Received: from localhost ([127.0.0.1]:57935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SbqFY-0006OY-04 for submit@debbugs.gnu.org; Tue, 05 Jun 2012 05:40:28 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48563) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SbqFC-0006Nc-Sc for submit@debbugs.gnu.org; Tue, 05 Jun 2012 05:40:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbqD5-0000DZ-DI for submit@debbugs.gnu.org; Tue, 05 Jun 2012 05:37:59 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:39731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbqD5-0000DV-7S for submit@debbugs.gnu.org; Tue, 05 Jun 2012 05:37:55 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbqCz-0007UX-0H for bug-coreutils@gnu.org; Tue, 05 Jun 2012 05:37:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbqCs-0000CM-In for bug-coreutils@gnu.org; Tue, 05 Jun 2012 05:37:48 -0400 Received: from mail-ee0-f41.google.com ([74.125.83.41]:57946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbqCs-0000C9-9V for bug-coreutils@gnu.org; Tue, 05 Jun 2012 05:37:42 -0400 Received: by eekb47 with SMTP id b47so1932764eek.0 for ; Tue, 05 Jun 2012 02:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=MWbbxEA6IqYhiwrh/CfBI/m/AD1TeborsY6mWnf9mSA=; b=oRbadiEoBOgGUfYcQfpIFBRk4TJQy8WrPxaiAxkFBOdylpR5ZKBkaeCGD2kDjzNFeA mjCDauYfeVf2TT3gfocHgd5IL0v3VBNUs+xRwOIGjQDBG3glTlwdgSv9l6LwDjJdmhbf o8+JzSoi95qmK1KGSvrVsHGis/ypc4SNpwawFWZXFFoJn4B+nGT0Lv6+JAyaKL9v/gaA Nae1SXmQmEvdGEO9Rq+Wswtx0b5XsLT8yCxaNDoARvds2LHC+gaCRFs1LoWeGfeFUfn9 dQwXpkumE8mhAatykBSgIBkXG+xkQGA8lfplM7JJHToVtoafph1PjejXnvzCiJQ8laTt WdDA== Received: by 10.14.39.70 with SMTP id c46mr7752319eeb.118.1338889059689; Tue, 05 Jun 2012 02:37:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.223.3 with HTTP; Tue, 5 Jun 2012 02:37:19 -0700 (PDT) From: Anoop Sharma Date: Tue, 5 Jun 2012 15:07:19 +0530 Message-ID: Content-Type: multipart/alternative; boundary=bcaec52be8f3cbe68704c1b666d4 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) --bcaec52be8f3cbe68704c1b666d4 Content-Type: text/plain; charset=ISO-8859-1 Head command does not position file pointer correctly for negative line count. Here is a demonstration of the problem. Step 1 - Create a file with 10 lines in it. $ yes "ABC" | head -c 40 >ip.txt $ Step 2 - If head behaves correctly, then 2 lines should get printed after "------------" but nothing gets printed! $ (head -n -2; echo "------------------------"; cat) Following snippet is copied from head.c (Function - elide_tail_lines_seekable ). Perhaps, there should be a lseek after fwrite there...: /* Output the initial portion of the buffer in which we found the desired newline byte. Don't bother testing for failure for such a small amount. Any failure will be detected upon close. */ fwrite (buffer, 1, n + 1, stdout); /*****************************************************************************************************************************/ --bcaec52be8f3cbe68704c1b666d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Head command does not position file pointer correctly for negative line cou= nt. Here is a demonstration of the problem.

Step 1 - Create a file w= ith 10 lines in it.
$ yes "ABC" | head -c 40 >ip.txt
$

Step 2 - If head behaves correctly, then 2 lines should get print= ed after "------------" but nothing gets printed!
$ (head -n -= 2; echo "------------------------"; cat) <ip.txt
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
------------------------$

Step 3 - Another try fails. If head behaves correctly, then 8 l= ines should get printed after "------------" but nothing gets pri= nted!
$ (head -n -8; echo "------------------------"; cat) <ip.txtABC
ABC
------------------------
$



/************= ***************************************************************************= **************************************/
Possible cause of the defect -> Following snippet is copied from head.c = (Function - elide_tail_lines_seekable ). Perhaps, there should be a lseek a= fter fwrite there...:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Out= put the initial portion of the buffer
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in which we found the desi= red newline byte.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Don&#= 39;t bother testing for failure for such a small amount.
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Any failure will be detected upon close.= =A0 */
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 fwrite (buffer, 1, n + 1,= stdout);
/**************************************************************************= ***************************************************/

--bcaec52be8f3cbe68704c1b666d4-- From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: Head command does not position file pointer correctly for negative line count Resent-From: "Voelker, Bernhard" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 05 Jun 2012 10:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Anoop Sharma , "11631@debbugs.gnu.org" <11631@debbugs.gnu.org> Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133889076326766 (code B ref 11631); Tue, 05 Jun 2012 10:07:02 +0000 Received: (at 11631) by debbugs.gnu.org; 5 Jun 2012 10:06:03 +0000 Received: from localhost ([127.0.0.1]:57942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SbqeI-0006xd-Mi for submit@debbugs.gnu.org; Tue, 05 Jun 2012 06:06:03 -0400 Received: from senmx11-mx.siemens-enterprise.com ([62.134.46.9]:32891) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sbqdy-0006wq-S9 for 11631@debbugs.gnu.org; Tue, 05 Jun 2012 06:06:01 -0400 Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id E1E7E1EB845D; Tue, 5 Jun 2012 12:03:34 +0200 (CEST) Received: from MCHP02MSX.global-ad.net ([169.254.4.240]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Tue, 5 Jun 2012 12:03:34 +0200 From: "Voelker, Bernhard" Thread-Topic: bug#11631: Head command does not position file pointer correctly for negative line count Thread-Index: AQHNQv8TMBcCHGrF8Uuh3Wz1hYr5L5brfUhA Date: Tue, 5 Jun 2012 10:03:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.132.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Anoop Sharma wrote: > Head command does not position file pointer correctly for negative line > count. Here is a demonstration of the problem. The problem doesn't seem to be limited to negative line counts. I replaced the 10 ABC lines by a number sequence to demonstrate this issue clearer. $ seq 10 | ( head -n -2 ; echo xxx ; cat ) 1 2 3 4 5 6 7 8 xxx $ seq 10 | ( head -n 2 ; echo xxx ; cat ) 1 2 xxx So head eats all of the input. The info page is silent about this. Have a nice day, Berny From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: Head command does not position file pointer correctly for negative line count Resent-From: Anoop Sharma Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 05 Jun 2012 10:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: "Voelker, Bernhard" Cc: "11631@debbugs.gnu.org" <11631@debbugs.gnu.org> Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133889213128781 (code B ref 11631); Tue, 05 Jun 2012 10:29:01 +0000 Received: (at 11631) by debbugs.gnu.org; 5 Jun 2012 10:28:51 +0000 Received: from localhost ([127.0.0.1]:57948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sbr0M-0007UA-EX for submit@debbugs.gnu.org; Tue, 05 Jun 2012 06:28:51 -0400 Received: from mail-ee0-f44.google.com ([74.125.83.44]:61285) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sbr0I-0007Tw-Um for 11631@debbugs.gnu.org; Tue, 05 Jun 2012 06:28:48 -0400 Received: by eekd4 with SMTP id d4so1887833eek.3 for <11631@debbugs.gnu.org>; Tue, 05 Jun 2012 03:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JYwwZ3rC52RznJft6onvNUT1O9UiKs4oiw9xW4HCCA4=; b=sqaa1Kbf3Xr2PqcGejHqMKMGC2IxabqIS+6038BOf0pFfWAEaG7Os9Qr9GPZmApUBI bQ+y2D5Q9VxatINg+UPAGGVGnp5oYDtfW4XOqZ4oME+vuDLl3wHaVA475dv1J24nqYG+ RyKdiGDlJmIueEeTE038TJcpDHId8batGmvk7lcXRGCJJXzeU99pYhgyRYjbUT4QXD5r tmehL6SWmh+k8Jj8E2ZB/h2dL0f6SkSkp7XkD5embajy4+aN+gQ+bcbRcefs9UX29dC8 9xXQDTaVJDSeObZfvzUiPcNOmzRodBXuxlbjdjpCbMDy5IPJAuYqCHDfMX/b2zgTzX7K xH/Q== Received: by 10.14.127.78 with SMTP id c54mr6861826eei.8.1338891998983; Tue, 05 Jun 2012 03:26:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.223.3 with HTTP; Tue, 5 Jun 2012 03:26:18 -0700 (PDT) In-Reply-To: References: From: Anoop Sharma Date: Tue, 5 Jun 2012 15:56:18 +0530 Message-ID: Content-Type: multipart/alternative; boundary=90e6ba5bb961fdf6dd04c1b7151d X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --90e6ba5bb961fdf6dd04c1b7151d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Head command behaves differently with seekable and un-seekable input-data sources. Pipes are un-seekable. Head's behavior with input provided using pipes will be different from its behavior when input is provided from a regular file (which are seekable). Therefore, the defect that was raised for regular files can not be evaluated by examples with pipes. Here's why head behaves differently depending on whether the file allows lseek(): ---------------------------------------------------------------------------= ---------------------- 1. Head command first reads data into a buffer using read() system call and then operates upon that buffer. 2. Size of the buffer used by head in read() is 8192 bytes on my machine. 3. It is not an error if read() gets lesser number of bytes than requested; this may happen for example because fewer bytes are actually available when read accessed the pipe or because read() was interrupted by a signal. 4. Therefore, only the upper bound of the data read in the buffer is fixed, not the lower bound. 5. Since read() tries to read as much data as it can (upto buffer size), therefore, in most cases it reads more data into the buffer than actually needed by head command's algorithm. 6. When head discovers that it does not need all the data in the buffer, then head tries to return the extra data back to the file descriptor by using lseek(). 7. However, data can not be returned back for un-seekable files. Therefore, head has to discard extra data in for un-seekable files. This creates situations that look as if head has eaten some part of the data. Head's problem with unseekable files - Commands waiting to execute after head will never get the extra data that was read by head. Bigger Problem =96 How much data will be lost is not fixed because how much data read() actually reads is not fixed (See point 4 above). It is also possible that no data is lost!! I tried the following example and it worked as expected: $ seq 10 >p $ ( head -n 2 ; echo xxx ; cat )

wrote: > Anoop Sharma wrote: > > > Head command does not position file pointer correctly for negative line > > count. Here is a demonstration of the problem. > > The problem doesn't seem to be limited to negative > line counts. I replaced the 10 ABC lines by a number > sequence to demonstrate this issue clearer. > > $ seq 10 | ( head -n -2 ; echo xxx ; cat ) > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > xxx > $ seq 10 | ( head -n 2 ; echo xxx ; cat ) > 1 > 2 > xxx > > So head eats all of the input. The info page is silent > about this. > > Have a nice day, > Berny > --90e6ba5bb961fdf6dd04c1b7151d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Head command behaves differently with seekable and un-seekable input-data s= ources.
Pipes are un-seekable. Head's behavior with input provided = using pipes will be different from its behavior when input is provided from= a regular file (which are seekable).

Therefore, the defect that was raised for regular files can not be eval= uated by examples with pipes.

Here's why head behaves differentl= y depending on whether the file allows lseek():
------------------------= ------------------------------------------------------------------------- 1. Head command first reads data into a buffer using read() system call and= then operates upon that buffer.
2. Size of the buffer used by head in r= ead() is 8192 bytes on my machine.
3. It is not an error if read() gets = lesser number of bytes than requested; this may happen for example because = fewer bytes are actually available when read accessed the pipe or because r= ead() was interrupted by a signal.
4. Therefore, only the upper bound of the data read in the buffer is fixed,= not the lower bound.
5. Since read() tries to read as much data as it c= an (upto buffer size), therefore, in most cases it reads more data into the= buffer than actually needed by head command's algorithm.
6. When head discovers that it does not need all the data in the buffer, th= en head tries to return the extra data back to the file descriptor by using= lseek().
7. However, data can not be returned back for un-seekable file= s. Therefore, head has to discard extra data in for un-seekable files. This= creates situations that look as if head has eaten some part of the data.
Head's problem with unseekable files - Commands waiting to execute = after head will never get the extra data that was read by head.
Bigger P= roblem =96 How much data will be lost is not fixed because how much data re= ad() actually reads is not fixed (See point 4 above). It is also possible t= hat no data is lost!!

I tried the following example and it worked as expected:
$ seq 10 &g= t;p
$ ( head -n 2 ; echo xxx ; cat )<p
1
2
xxx
3
4
= 5
6
7
8
9
10
$


On Tue, Jun 5, 2012 at 3:33 PM, Voelker, Bernhard <b= ernhard.voelker@siemens-enterprise.com> wrote:
Anoop Sharma wrote:

> Head command does not position file pointer correctly for negative lin= e
> count. Here is a demonstration of the problem.

The problem doesn't seem to be limited to negative
line counts. I replaced the 10 ABC lines by a number
sequence to demonstrate this issue clearer.

=A0$ seq 10 | ( head -n -2 ; echo xxx ; cat )
=A01
=A02
=A03
=A04
=A05
=A06
=A07
=A08
=A0xxx
=A0$ seq 10 | ( head -n 2 ; echo xxx ; cat )
=A01
=A02
=A0xxx

So head eats all of the input. The info page is silent
about this.

Have a nice day,
Berny

--90e6ba5bb961fdf6dd04c1b7151d-- From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: Head command does not position file pointer correctly for negative line count Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 05 Jun 2012 10:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Anoop Sharma Cc: 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133889232329115 (code B ref 11631); Tue, 05 Jun 2012 10:33:02 +0000 Received: (at 11631) by debbugs.gnu.org; 5 Jun 2012 10:32:03 +0000 Received: from localhost ([127.0.0.1]:57952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sbr3S-0007ZN-DR for submit@debbugs.gnu.org; Tue, 05 Jun 2012 06:32:02 -0400 Received: from mx.meyering.net ([88.168.87.75]:46476) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sbr37-0007Yq-VC for 11631@debbugs.gnu.org; Tue, 05 Jun 2012 06:32:01 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id A207F60103; Tue, 5 Jun 2012 12:29:38 +0200 (CEST) From: Jim Meyering In-Reply-To: (Anoop Sharma's message of "Tue, 5 Jun 2012 15:07:19 +0530") References: Date: Tue, 05 Jun 2012 12:29:38 +0200 Message-ID: <87ipf69hm5.fsf@rho.meyering.net> Lines: 82 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Anoop Sharma wrote: > Head command does not position file pointer correctly for negative line > count. Here is a demonstration of the problem. > > Step 1 - Create a file with 10 lines in it. > $ yes "ABC" | head -c 40 >ip.txt > $ Thank you for the report. That is indeed a bug. Here's a quick example of how head -n-3 should work: $ seq 10 > k; (./head -n-3; echo foo; cat) < k 1 2 3 4 5 6 7 foo 8 9 10 Before your suggested change, it did this: $ seq 10 > k; (head -n-3; echo foo; cat) < k 1 2 3 4 5 6 7 foo I note that a similar change is *not* required for the end-relative byte-seekable case: $ seq 3 > k; (head -c-2; echo foo; cat) < k 1 2 foo 3 Here's the start of a proper patch. To come: mention this in NEWS and add a test. >From 0c156fb347dba3f499ed7b922af1ea357f5558c0 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 5 Jun 2012 12:24:49 +0200 Subject: [PATCH] head: with --lines=-N (-n-N) reset file pointer on seekable input * src/head.c (elide_tail_lines_seekable): Reset file pointer after printing up to an end-relative line-counted offset. Anoop Sharma reported the problem and suggested the fix. --- src/head.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/head.c b/src/head.c index d7e83b7..75a69d8 100644 --- a/src/head.c +++ b/src/head.c @@ -667,6 +667,14 @@ elide_tail_lines_seekable (const char *pretty_filename, int fd, Don't bother testing for failure for such a small amount. Any failure will be detected upon close. */ fwrite (buffer, 1, n + 1, stdout); + + /* Set file pointer to the byte after what we've output. */ + if (lseek (fd, start_pos + n + 1, SEEK_SET) < 0) + { + error (0, errno, "%s: failed to reset file pointer", + quote (pretty_filename)); + return false; + } return true; } } -- 1.7.11.rc1 From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: Head command does not position file pointer correctly for negative line count Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 05 Jun 2012 10:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: "Voelker, Bernhard" Cc: Anoop Sharma , "11631@debbugs.gnu.org" <11631@debbugs.gnu.org> Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133889239229219 (code B ref 11631); Tue, 05 Jun 2012 10:34:02 +0000 Received: (at 11631) by debbugs.gnu.org; 5 Jun 2012 10:33:12 +0000 Received: from localhost ([127.0.0.1]:57956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sbr4Z-0007bD-D8 for submit@debbugs.gnu.org; Tue, 05 Jun 2012 06:33:12 -0400 Received: from mail3.vodafone.ie ([213.233.128.45]:25456) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sbr4W-0007ar-MF for 11631@debbugs.gnu.org; Tue, 05 Jun 2012 06:33:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgBAE/fzU9tTC0N/2dsb2JhbAANOLBehnYBAQEEMgFGEAsNCwkWDwkDAgECAUUGDQEHAQG/S4sTFIV8A5sNjGWBVQ Received: from unknown (HELO [192.168.1.79]) ([109.76.45.13]) by mail3.vodafone.ie with ESMTP; 05 Jun 2012 11:31:00 +0100 Message-ID: <4FCDDFE3.2080304@draigBrady.com> Date: Tue, 05 Jun 2012 11:30:59 +0100 From: =?UTF-8?Q?P=C3=A1draig?= Brady User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 06/05/2012 11:03 AM, Voelker, Bernhard wrote: > Anoop Sharma wrote: > >> Head command does not position file pointer correctly for negative line >> count. Here is a demonstration of the problem. > > The problem doesn't seem to be limited to negative > line counts. I replaced the 10 ABC lines by a number > sequence to demonstrate this issue clearer. > > $ seq 10 | ( head -n -2 ; echo xxx ; cat ) > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > xxx > $ seq 10 | ( head -n 2 ; echo xxx ; cat ) > 1 > 2 > xxx > > So head eats all of the input. The info page is silent > about this. > > Have a nice day, > Berny Well reading from files should be more flexible than pipes as we can reset positions in files with seek. This works for -c but not for -n. I'll look at fixing this issue this evening. For pipes we need to consume the data to determine what to throw away, and there is no facility to replace that. I'll try and document this edge case in the info too. cheers, Pádraig. From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: Head command does not position file pointer correctly for negative line count Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 05 Jun 2012 11:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: =?UTF-8?Q?P=C3=A1draig?= Brady Cc: 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.13388959425041 (code B ref 11631); Tue, 05 Jun 2012 11:33:02 +0000 Received: (at 11631) by debbugs.gnu.org; 5 Jun 2012 11:32:22 +0000 Received: from localhost ([127.0.0.1]:57994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sbrzp-0001JG-TV for submit@debbugs.gnu.org; Tue, 05 Jun 2012 07:32:22 -0400 Received: from mx.meyering.net ([88.168.87.75]:46631) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sbrzn-0001J8-Av for 11631@debbugs.gnu.org; Tue, 05 Jun 2012 07:32:20 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 08E7860081; Tue, 5 Jun 2012 13:30:15 +0200 (CEST) From: Jim Meyering In-Reply-To: <4FCDE320.9020509@draigBrady.com> ("=?UTF-8?Q?P=C3=A1draig?= Brady"'s message of "Tue, 05 Jun 2012 11:44:48 +0100") References: <87ipf69hm5.fsf@rho.meyering.net> <4FCDE320.9020509@draigBrady.com> Date: Tue, 05 Jun 2012 13:30:15 +0200 Message-ID: <87d35e9et4.fsf@rho.meyering.net> Lines: 79 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) P=E1draig Brady wrote: > On 06/05/2012 11:29 AM, Jim Meyering wrote: >> Anoop Sharma wrote: >>> Head command does not position file pointer correctly for negative line >>> count. Here is a demonstration of the problem. >>> >>> Step 1 - Create a file with 10 lines in it. >>> $ yes "ABC" | head -c 40 >ip.txt >>> $ >> >> Thank you for the report. That is indeed a bug. >> Here's a quick example of how head -n-3 should work: >> >> $ seq 10 > k; (./head -n-3; echo foo; cat) < k >> 1 >> 2 >> 3 >> 4 >> 5 >> 6 >> 7 >> foo >> 8 >> 9 >> 10 >> >> Before your suggested change, it did this: >> >> $ seq 10 > k; (head -n-3; echo foo; cat) < k >> 1 >> 2 >> 3 >> 4 >> 5 >> 6 >> 7 >> foo >> >> I note that a similar change is *not* required for the end-relative >> byte-seekable case: >> >> $ seq 3 > k; (head -c-2; echo foo; cat) < k >> 1 >> 2 >> foo >> 3 >> >> Here's the start of a proper patch. >> To come: mention this in NEWS and add a test. >> >>>>From 0c156fb347dba3f499ed7b922af1ea357f5558c0 Mon Sep 17 00:00:00 2001 >> From: Jim Meyering >> Date: Tue, 5 Jun 2012 12:24:49 +0200 >> Subject: [PATCH] head: with --lines=3D-N (-n-N) reset file pointer on se= ekable >> input >> >> * src/head.c (elide_tail_lines_seekable): Reset file pointer >> after printing up to an end-relative line-counted offset. >> Anoop Sharma reported the problem and suggested the fix. >> --- >> src/head.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/src/head.c b/src/head.c >> index d7e83b7..75a69d8 100644 >> --- a/src/head.c >> +++ b/src/head.c >> @@ -667,6 +667,14 @@ elide_tail_lines_seekable (const char *pretty_filen= ame, int fd, >> Don't bother testing for failure for such a small amou= nt. >> Any failure will be detected upon close. */ >> fwrite (buffer, 1, n + 1, stdout); >> + >> + /* Set file pointer to the byte after what we've output. = */ >> + if (lseek (fd, start_pos + n + 1, SEEK_SET) < 0) > > s/start_pos/pos/ ? Oh! Good catch. Thanks! You're right. Now I'll have to construct a test that exercises that bug, too. From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: Head command does not position file pointer correctly for negative line count Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 05 Jun 2012 18:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: =?UTF-8?Q?P=C3=A1draig?= Brady Cc: 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133892009110574 (code B ref 11631); Tue, 05 Jun 2012 18:15:02 +0000 Received: (at 11631) by debbugs.gnu.org; 5 Jun 2012 18:14:51 +0000 Received: from localhost ([127.0.0.1]:58590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SbyHL-0002kU-A0 for submit@debbugs.gnu.org; Tue, 05 Jun 2012 14:14:51 -0400 Received: from mx.meyering.net ([88.168.87.75]:47808) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SbyHI-0002kL-MR for 11631@debbugs.gnu.org; Tue, 05 Jun 2012 14:14:50 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 358B860051; Tue, 5 Jun 2012 20:12:43 +0200 (CEST) From: Jim Meyering In-Reply-To: <87d35e9et4.fsf@rho.meyering.net> (Jim Meyering's message of "Tue, 05 Jun 2012 13:30:15 +0200") References: <87ipf69hm5.fsf@rho.meyering.net> <4FCDE320.9020509@draigBrady.com> <87d35e9et4.fsf@rho.meyering.net> Date: Tue, 05 Jun 2012 20:12:43 +0200 Message-ID: <87zk8h631g.fsf@rho.meyering.net> Lines: 133 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Jim Meyering wrote: >>> Here's the start of a proper patch. >>> To come: mention this in NEWS and add a test. Here's the complete patch. Figuring out how to trigger the bug in my patch (s/start_pos/pos/) that P=E1draig spotted was interesting. No prior test case exercised any of the related code, at least not with the BUFSIZ value of 8KiB that I have here. As for when the bug was introduced, I confirmed that it's present at least as far back as textutils-2.1 with this: printf '\nok\n' > k; (head -n-1>/dev/null; grep o || echo FAIL) < k and there was no significant seek-related change prior to that. >From 295ee521bc1a4f473ee8b7b5a4be32c5b5c7386f Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 5 Jun 2012 12:24:49 +0200 Subject: [PATCH] head: with --lines=3D-N (-n-N) reset file pointer on seeka= ble input MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit * src/head.c (elide_tail_lines_seekable): Reset file pointer after printing up to an end-relative line-counted offset. Anoop Sharma reported the problem and suggested the fix. * tests/misc/head-pos: Add coverage via a very similar, existing test. Also add coverage for a previously untested block of code. * tests/misc/head-elide-tail ($READ_BUFSIZE): Update to 8192, to match the value of BUFSIZ I see today on Fedora 17/x86_64 (unrelated to this fix). * NEWS (Bug fixes): Mention it. Improved-by: P=E1draig Brady --- NEWS | 7 +++++++ src/head.c | 8 ++++++++ tests/misc/head-elide-tail | 2 +- tests/misc/head-pos | 26 +++++++++++++++++++------- 4 files changed, 35 insertions(+), 8 deletions(-) diff --git a/NEWS b/NEWS index 7c7c2c3..c0e5fdb 100644 --- a/NEWS +++ b/NEWS @@ -8,6 +8,13 @@ GNU coreutils NEWS -*- = outline -*- processes will not intersperse their output. [the bug dates back to the initial implementation] + head --lines=3D-N (-n-N) now resets the read pointer of a seekable input= file. + This means that "head -n-3" no longer consumes all of its input, and lin= es + not output by head may be processed by other programs. For example, this + command now prints the final line, 2, while before it would print nothin= g: + seq 2 > k; (head -n-1 > /dev/null; cat) < k + [This bug was present in "the beginning".] + ls --color would mis-color relative-named symlinks in / [bug introduced in coreutils-8.17] diff --git a/src/head.c b/src/head.c index d7e83b7..0d5e1b2 100644 --- a/src/head.c +++ b/src/head.c @@ -667,6 +667,14 @@ elide_tail_lines_seekable (const char *pretty_filename= , int fd, Don't bother testing for failure for such a small amount. Any failure will be detected upon close. */ fwrite (buffer, 1, n + 1, stdout); + + /* Set file pointer to the byte after what we've output. */ + if (lseek (fd, pos + n + 1, SEEK_SET) < 0) + { + error (0, errno, "%s: failed to reset file pointer", + quote (pretty_filename)); + return false; + } return true; } } diff --git a/tests/misc/head-elide-tail b/tests/misc/head-elide-tail index de4896b..85f509d 100755 --- a/tests/misc/head-elide-tail +++ b/tests/misc/head-elide-tail @@ -26,7 +26,7 @@ $ENV{PROG} =3D 'head'; @ENV{qw(LANGUAGE LANG LC_ALL)} =3D ('C') x 3; # This should match the definition in head.c. -my $READ_BUFSIZE =3D 4096; +my $READ_BUFSIZE =3D 8192; my @Tests =3D ( diff --git a/tests/misc/head-pos b/tests/misc/head-pos index 3d96261..fa3284e 100755 --- a/tests/misc/head-pos +++ b/tests/misc/head-pos @@ -21,12 +21,24 @@ print_ver_ head (echo a; echo b) > in || framework_failure_ - -(head -n 1 >/dev/null; cat) < in > out || fail=3D1 -cat < exp -b -EOF - -compare exp out || fail=3D1 +echo b > exp || framework_failure_ + +for i in -1 1; do + (head -n $i >/dev/null; cat) < in > out || fail=3D1 + compare exp out || fail=3D1 +done + +# Exercise the (start_pos < pos) block in elide_tail_lines_seekable. +# So far, this is the only test to do that. +# Do that by creating a file larger than BUFSIZ (I've seen 128K) and +# elide a suffix of it (by line count) that is also larger than BUFSIZ. +# 50000 lines times 6 bytes per line gives us enough leeway even on a +# system with a BUFSIZ of 256K. +n_lines=3D50000 +seq 70000 > in2 || framework_failure_ +echo $n_lines > exp-n || framework_failure_ + +(head -n-$n_lines>/dev/null; wc -l) < in2 > n +compare exp-n n || fail=3D1 Exit $fail -- 1.7.11.rc1 From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: Head command does not position file pointer correctly for negative line count Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 05 Jun 2012 20:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Jim Meyering Cc: 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133892805023023 (code B ref 11631); Tue, 05 Jun 2012 20:28:01 +0000 Received: (at 11631) by debbugs.gnu.org; 5 Jun 2012 20:27:30 +0000 Received: from localhost ([127.0.0.1]:59192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sc0Li-0005zI-IL for submit@debbugs.gnu.org; Tue, 05 Jun 2012 16:27:30 -0400 Received: from mail3.vodafone.ie ([213.233.128.45]:1761) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sc0LO-0005yn-0q for 11631@debbugs.gnu.org; Tue, 05 Jun 2012 16:27:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8BACNqzk9tTC0N/2dsb2JhbAANOLBqhncBAQEEMgFGEAsNCwkWDwkDAgECAUUGDQEHAQEWvyqLE4YZA5sNjGU Received: from unknown (HELO [192.168.1.79]) ([109.76.45.13]) by mail3.vodafone.ie with ESMTP; 05 Jun 2012 21:24:59 +0100 Message-ID: <4FCE6B1A.8010204@draigBrady.com> Date: Tue, 05 Jun 2012 21:24:58 +0100 From: =?UTF-8?Q?P=C3=A1draig?= Brady User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 References: <87ipf69hm5.fsf@rho.meyering.net> <4FCDE320.9020509@draigBrady.com> <87d35e9et4.fsf@rho.meyering.net> <87zk8h631g.fsf@rho.meyering.net> In-Reply-To: <87zk8h631g.fsf@rho.meyering.net> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 06/05/2012 07:12 PM, Jim Meyering wrote: > Jim Meyering wrote: >>>> Here's the start of a proper patch. >>>> To come: mention this in NEWS and add a test. > > Here's the complete patch. Nice tests. +1 cheers, Pádraig. From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: Head command does not position file pointer correctly for negative line count Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Tue, 05 Jun 2012 20:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: =?UTF-8?Q?P=C3=A1draig?= Brady Cc: 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133892850123696 (code B ref 11631); Tue, 05 Jun 2012 20:36:01 +0000 Received: (at 11631) by debbugs.gnu.org; 5 Jun 2012 20:35:01 +0000 Received: from localhost ([127.0.0.1]:59198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sc0Sz-0006A4-8I for submit@debbugs.gnu.org; Tue, 05 Jun 2012 16:35:01 -0400 Received: from mx.meyering.net ([88.168.87.75]:48213) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sc0Sw-00069w-GC for 11631@debbugs.gnu.org; Tue, 05 Jun 2012 16:34:59 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 250996009A; Tue, 5 Jun 2012 22:32:52 +0200 (CEST) From: Jim Meyering In-Reply-To: <4FCE6B1A.8010204@draigBrady.com> ("=?UTF-8?Q?P=C3=A1draig?= Brady"'s message of "Tue, 05 Jun 2012 21:24:58 +0100") References: <87ipf69hm5.fsf@rho.meyering.net> <4FCDE320.9020509@draigBrady.com> <87d35e9et4.fsf@rho.meyering.net> <87zk8h631g.fsf@rho.meyering.net> <4FCE6B1A.8010204@draigBrady.com> Date: Tue, 05 Jun 2012 22:32:52 +0200 Message-ID: <87mx4h5wjv.fsf@rho.meyering.net> Lines: 12 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) P=E1draig Brady wrote: > On 06/05/2012 07:12 PM, Jim Meyering wrote: >> Jim Meyering wrote: >>>>> Here's the start of a proper patch. >>>>> To come: mention this in NEWS and add a test. >> >> Here's the complete patch. > > Nice tests. > +1 Thanks, and thanks for the review. Pushed. From unknown Tue Aug 19 05:08:57 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Anoop Sharma Subject: bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count) Message-ID: References: <87haup5wfy.fsf@rho.meyering.net> X-Gnu-PR-Message: they-closed 11631 X-Gnu-PR-Package: coreutils Reply-To: 11631@debbugs.gnu.org Date: Tue, 05 Jun 2012 20:38:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1338928682-23952-1" This is a multi-part message in MIME format... ------------=_1338928682-23952-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #11631: Head command does not position file pointer correctly for negative = line count which was filed against the coreutils package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 11631@debbugs.gnu.org. --=20 11631: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D11631 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1338928682-23952-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 11631-done) by debbugs.gnu.org; 5 Jun 2012 20:37:39 +0000 Received: from localhost ([127.0.0.1]:59203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sc0VX-0006Dn-1t for submit@debbugs.gnu.org; Tue, 05 Jun 2012 16:37:39 -0400 Received: from mx.meyering.net ([88.168.87.75]:48229) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sc0VD-0006DQ-94 for 11631-done@debbugs.gnu.org; Tue, 05 Jun 2012 16:37:37 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 550816009A; Tue, 5 Jun 2012 22:35:13 +0200 (CEST) From: Jim Meyering To: =?iso-8859-1?Q?P=E1draig?= Brady Subject: Re: bug#11631: Head command does not position file pointer correctly for negative line count In-Reply-To: <87mx4h5wjv.fsf@rho.meyering.net> (Jim Meyering's message of "Tue, 05 Jun 2012 22:32:52 +0200") References: <87ipf69hm5.fsf@rho.meyering.net> <4FCDE320.9020509@draigBrady.com> <87d35e9et4.fsf@rho.meyering.net> <87zk8h631g.fsf@rho.meyering.net> <4FCE6B1A.8010204@draigBrady.com> <87mx4h5wjv.fsf@rho.meyering.net> Date: Tue, 05 Jun 2012 22:35:13 +0200 Message-ID: <87haup5wfy.fsf@rho.meyering.net> Lines: 4 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11631-done Cc: 11631-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Jim Meyering wrote: > Thanks, and thanks for the review. Pushed. And with this message, I've closed the issue. ------------=_1338928682-23952-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 5 Jun 2012 09:40:28 +0000 Received: from localhost ([127.0.0.1]:57935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SbqFY-0006OY-04 for submit@debbugs.gnu.org; Tue, 05 Jun 2012 05:40:28 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48563) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SbqFC-0006Nc-Sc for submit@debbugs.gnu.org; Tue, 05 Jun 2012 05:40:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbqD5-0000DZ-DI for submit@debbugs.gnu.org; Tue, 05 Jun 2012 05:37:59 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:39731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbqD5-0000DV-7S for submit@debbugs.gnu.org; Tue, 05 Jun 2012 05:37:55 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbqCz-0007UX-0H for bug-coreutils@gnu.org; Tue, 05 Jun 2012 05:37:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbqCs-0000CM-In for bug-coreutils@gnu.org; Tue, 05 Jun 2012 05:37:48 -0400 Received: from mail-ee0-f41.google.com ([74.125.83.41]:57946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbqCs-0000C9-9V for bug-coreutils@gnu.org; Tue, 05 Jun 2012 05:37:42 -0400 Received: by eekb47 with SMTP id b47so1932764eek.0 for ; Tue, 05 Jun 2012 02:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=MWbbxEA6IqYhiwrh/CfBI/m/AD1TeborsY6mWnf9mSA=; b=oRbadiEoBOgGUfYcQfpIFBRk4TJQy8WrPxaiAxkFBOdylpR5ZKBkaeCGD2kDjzNFeA mjCDauYfeVf2TT3gfocHgd5IL0v3VBNUs+xRwOIGjQDBG3glTlwdgSv9l6LwDjJdmhbf o8+JzSoi95qmK1KGSvrVsHGis/ypc4SNpwawFWZXFFoJn4B+nGT0Lv6+JAyaKL9v/gaA Nae1SXmQmEvdGEO9Rq+Wswtx0b5XsLT8yCxaNDoARvds2LHC+gaCRFs1LoWeGfeFUfn9 dQwXpkumE8mhAatykBSgIBkXG+xkQGA8lfplM7JJHToVtoafph1PjejXnvzCiJQ8laTt WdDA== Received: by 10.14.39.70 with SMTP id c46mr7752319eeb.118.1338889059689; Tue, 05 Jun 2012 02:37:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.223.3 with HTTP; Tue, 5 Jun 2012 02:37:19 -0700 (PDT) From: Anoop Sharma Date: Tue, 5 Jun 2012 15:07:19 +0530 Message-ID: Subject: Head command does not position file pointer correctly for negative line count To: bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary=bcaec52be8f3cbe68704c1b666d4 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) --bcaec52be8f3cbe68704c1b666d4 Content-Type: text/plain; charset=ISO-8859-1 Head command does not position file pointer correctly for negative line count. Here is a demonstration of the problem. Step 1 - Create a file with 10 lines in it. $ yes "ABC" | head -c 40 >ip.txt $ Step 2 - If head behaves correctly, then 2 lines should get printed after "------------" but nothing gets printed! $ (head -n -2; echo "------------------------"; cat) Following snippet is copied from head.c (Function - elide_tail_lines_seekable ). Perhaps, there should be a lseek after fwrite there...: /* Output the initial portion of the buffer in which we found the desired newline byte. Don't bother testing for failure for such a small amount. Any failure will be detected upon close. */ fwrite (buffer, 1, n + 1, stdout); /*****************************************************************************************************************************/ --bcaec52be8f3cbe68704c1b666d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Head command does not position file pointer correctly for negative line cou= nt. Here is a demonstration of the problem.

Step 1 - Create a file w= ith 10 lines in it.
$ yes "ABC" | head -c 40 >ip.txt
$

Step 2 - If head behaves correctly, then 2 lines should get print= ed after "------------" but nothing gets printed!
$ (head -n -= 2; echo "------------------------"; cat) <ip.txt
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
------------------------$

Step 3 - Another try fails. If head behaves correctly, then 8 l= ines should get printed after "------------" but nothing gets pri= nted!
$ (head -n -8; echo "------------------------"; cat) <ip.txtABC
ABC
------------------------
$



/************= ***************************************************************************= **************************************/
Possible cause of the defect -> Following snippet is copied from head.c = (Function - elide_tail_lines_seekable ). Perhaps, there should be a lseek a= fter fwrite there...:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Out= put the initial portion of the buffer
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in which we found the desi= red newline byte.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Don&#= 39;t bother testing for failure for such a small amount.
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Any failure will be detected upon close.= =A0 */
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 fwrite (buffer, 1, n + 1,= stdout);
/**************************************************************************= ***************************************************/

--bcaec52be8f3cbe68704c1b666d4-- ------------=_1338928682-23952-1-- From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count) Resent-From: Anoop Sharma Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 06 Jun 2012 04:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133895536730300 (code B ref 11631); Wed, 06 Jun 2012 04:03:02 +0000 Received: (at 11631) by debbugs.gnu.org; 6 Jun 2012 04:02:47 +0000 Received: from localhost ([127.0.0.1]:59792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sc7SJ-0007sf-4y for submit@debbugs.gnu.org; Wed, 06 Jun 2012 00:02:47 -0400 Received: from mail-ey0-f172.google.com ([209.85.215.172]:44355) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sc7SF-0007sR-M7 for 11631@debbugs.gnu.org; Wed, 06 Jun 2012 00:02:45 -0400 Received: by eaaq13 with SMTP id q13so1812595eaa.3 for <11631@debbugs.gnu.org>; Tue, 05 Jun 2012 21:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=hsq/TBcK1dXVYEp6exB6tAVmQAfIvCRXX+49LtdYFBg=; b=PaM1RxYE5th5vXl6e28CcXtgP8qJJs5s5uLJUD4InLzZF97wEOJThebLWSs0Jx0Amn k7fxS+mAKXcYYdWpxnvsAh9sWSXjhzd7xyigP/ClUYcdotZpBKPCdyqZFv3TTaXzbIxS ujClWXDK8BbJH+vVyR7sTsPnVXx76FaVu8bhvI2YFyCEbXQPNWtiNnN3Vcu6Q2gEm2Zy QLBI0FLhiU/5YPrUuJ9V94Q6mUAPi4lhuXW2D6grPGlhFx/Yf5kLkf3UpJuhbScWIQ8H ivs4rnkuWaogXJvf2kq/X0l1KX4GWuV5+jDdf4aR0c1AotyVwsmogflScoTyX4T/yCEo jdJg== Received: by 10.14.47.72 with SMTP id s48mr8878911eeb.130.1338955231575; Tue, 05 Jun 2012 21:00:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.223.3 with HTTP; Tue, 5 Jun 2012 21:00:11 -0700 (PDT) In-Reply-To: References: <87haup5wfy.fsf@rho.meyering.net> From: Anoop Sharma Date: Wed, 6 Jun 2012 09:30:11 +0530 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) 1. The comment in code - "Don't bother testing for failure for such a small amount. Any failure will be detected upon close." may be re-looked too, since we are now lseeking after it. What if we change plain fwrite to: if (fwrite (buffer, 1, n + 1, stdout) < (n + 1)) error (EXIT_FAILURE, errno, _("write error")); 2. Maybe using lseek with SEEK_CUR in place of SEEK_SET would reflect logic better. With Thanks for quick responses, Anoop On Wed, Jun 6, 2012 at 2:08 AM, GNU bug Tracking System wrote: > > Your bug report > > #11631: Head command does not position file pointer correctly for negativ= e line count > > which was filed against the coreutils package, has been closed. > > The explanation is attached below, along with your original report. > If you require more details, please reply to 11631@debbugs.gnu.org. > > -- > 11631: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D11631 > GNU Bug Tracking System > Contact help-debbugs@gnu.org with problems > > > ---------- Forwarded message ---------- > From:=A0Jim Meyering > To:=A0P=E1draig Brady > Cc:=A011631-done@debbugs.gnu.org > Date:=A0Tue, 05 Jun 2012 22:35:13 +0200 > Subject:=A0Re: bug#11631: Head command does not position file pointer cor= rectly for negative line count > Jim Meyering wrote: > > Thanks, and thanks for the review. =A0Pushed. > > And with this message, I've closed the issue. > > > > ---------- Forwarded message ---------- > From:=A0Anoop Sharma > To:=A0bug-coreutils@gnu.org > Cc: > Date:=A0Tue, 5 Jun 2012 15:07:19 +0530 > Subject:=A0Head command does not position file pointer correctly for nega= tive line count > Head command does not position file pointer correctly for negative line c= ount. Here is a demonstration of the problem. > > Step 1 - Create a file with 10 lines in it. > $ yes "ABC" | head -c 40 >ip.txt > $ > > Step 2 - If head behaves correctly, then 2 lines should get printed after= "------------" but nothing gets printed! > $ (head -n -2; echo "------------------------"; cat) ABC > ABC > ABC > ABC > ABC > ABC > ABC > ABC > ------------------------ > $ > > Step 3 - Another try fails. If head behaves correctly, then 8 lines shoul= d get printed after "------------" but nothing gets printed! > $ (head -n -8; echo "------------------------"; cat) ABC > ABC > ------------------------ > $ > > > > /************************************************************************= *****************************************************/ > Possible cause of the defect -> Following snippet is copied from head.c (= Function - elide_tail_lines_seekable ). Perhaps, there should be a lseek af= ter fwrite there...: > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Output the initial portion of = the buffer > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in which we found the de= sired newline byte. > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Don't bother testing for= failure for such a small amount. > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Any failure will be dete= cted upon close.=A0 */ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 fwrite (buffer, 1, n + 1, stdout)= ; > /************************************************************************= *****************************************************/ > > From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count) Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 06 Jun 2012 08:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Anoop Sharma Cc: 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133896988818886 (code B ref 11631); Wed, 06 Jun 2012 08:05:02 +0000 Received: (at 11631) by debbugs.gnu.org; 6 Jun 2012 08:04:48 +0000 Received: from localhost ([127.0.0.1]:59942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScBEW-0004uZ-7I for submit@debbugs.gnu.org; Wed, 06 Jun 2012 04:04:48 -0400 Received: from mx.meyering.net ([88.168.87.75]:49995) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScBEB-0004u9-MR for 11631@debbugs.gnu.org; Wed, 06 Jun 2012 04:04:47 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 74473601A9; Wed, 6 Jun 2012 10:02:18 +0200 (CEST) From: Jim Meyering In-Reply-To: (Anoop Sharma's message of "Wed, 6 Jun 2012 09:30:11 +0530") References: <87haup5wfy.fsf@rho.meyering.net> Date: Wed, 06 Jun 2012 10:02:18 +0200 Message-ID: <87y5o050mt.fsf@rho.meyering.net> Lines: 62 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Anoop Sharma wrote: > 1. The comment in code - "Don't bother testing for failure for such a > small amount. Any failure will be detected upon close." may be > re-looked too, since we are now lseeking after it. > > What if we change plain fwrite to: > if (fwrite (buffer, 1, n + 1, stdout) < (n + 1)) > error (EXIT_FAILURE, errno, _("write error")); > > 2. Maybe using lseek with SEEK_CUR in place of SEEK_SET would reflect > logic better. Regarding #1, thanks for the suggestion. You're right. I've written a complete patch in your name, below, adding a commit log and removing the unnecessary parentheses around "n + 1". In general, I much prefer a patch to a suggestion like that. The advantage to you is that if you describe precisely enough (usually requires a patch), then you're listed as the author of the commit. If you also take the time to write a commit log entry like I did below, then that's even better. See the file, HACKING, for instructions on how to do that as well as general contribution guidelines. Regarding #2, please be precise and write/post a patch. >From 7fcfa754f1ff92d4fed1495a05574b8e47c3b4fb Mon Sep 17 00:00:00 2001 From: Anoop Sharma Date: Wed, 6 Jun 2012 09:42:09 +0200 Subject: [PATCH] head: diagnose write failure immediately, given new lseek use Inserting the lseek call (commit v8.17-13-g295ee52) rendered inaccurate the comment/code that refrained from diagnosing the failure of the just-preceding fwrite. * src/head.c (elide_tail_lines_seekable): Remove now-erroneous comment, and diagnose fwrite failure. --- src/head.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/src/head.c b/src/head.c index c13c064..ffe7c74 100644 --- a/src/head.c +++ b/src/head.c @@ -663,10 +663,9 @@ elide_tail_lines_seekable (const char *pretty_filename, int fd, } /* Output the initial portion of the buffer - in which we found the desired newline byte. - Don't bother testing for failure for such a small amount. - Any failure will be detected upon close. */ - fwrite (buffer, 1, n + 1, stdout); + in which we found the desired newline byte. */ + if (fwrite (buffer, 1, n + 1, stdout) < n + 1) + error (EXIT_FAILURE, errno, _("write error")); /* Set file pointer to the byte after what we've output. */ if (lseek (fd, pos + n + 1, SEEK_SET) < 0) -- 1.7.11.rc1 From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count) Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 06 Jun 2012 11:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Jim Meyering Cc: Anoop Sharma , 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.13389836839750 (code B ref 11631); Wed, 06 Jun 2012 11:55:02 +0000 Received: (at 11631) by debbugs.gnu.org; 6 Jun 2012 11:54:43 +0000 Received: from localhost ([127.0.0.1]:60107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScEp1-0002XD-1j for submit@debbugs.gnu.org; Wed, 06 Jun 2012 07:54:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23780) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScEox-0002Ww-CI for 11631@debbugs.gnu.org; Wed, 06 Jun 2012 07:54:41 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q56BqOiu011023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jun 2012 07:52:25 -0400 Received: from [10.3.113.60] (ovpn-113-60.phx2.redhat.com [10.3.113.60]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q56BqNgi011455; Wed, 6 Jun 2012 07:52:24 -0400 Message-ID: <4FCF4477.1070608@redhat.com> Date: Wed, 06 Jun 2012 05:52:23 -0600 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 References: <87haup5wfy.fsf@rho.meyering.net> <87y5o050mt.fsf@rho.meyering.net> In-Reply-To: <87y5o050mt.fsf@rho.meyering.net> X-Enigmail-Version: 1.4.2 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC669B9FBE6938CC9AFDC2A63" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Spam-Score: -6.9 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC669B9FBE6938CC9AFDC2A63 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/06/2012 02:02 AM, Jim Meyering wrote: > +++ b/src/head.c > @@ -663,10 +663,9 @@ elide_tail_lines_seekable (const char *pretty_file= name, int fd, > } >=20 > /* Output the initial portion of the buffer > - in which we found the desired newline byte. > - Don't bother testing for failure for such a small amo= unt. > - Any failure will be detected upon close. */ > - fwrite (buffer, 1, n + 1, stdout); > + in which we found the desired newline byte. */ > + if (fwrite (buffer, 1, n + 1, stdout) < n + 1) > + error (EXIT_FAILURE, errno, _("write error")); Is testing for fwrite() sufficient? Shouldn't you actually be testing for fflush() errors, since fwrite() buffers the output and might not actually encounter an error until it flushes? Or even on NFS, where fflush() may succeed but fclose() fails? In other words, our atexit() handler for detecting fclose() failure will already catch things; we may still be in a situation where fwrite() succeeds, we then do lseek(), but fclose() fails, in spite of our efforts. I don't see how this patch improves anything, other than earlier error reporting. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigC669B9FBE6938CC9AFDC2A63 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPz0R3AAoJEKeha0olJ0NqhmgH/2EMQ8vLZuEHMeKsqH+P4RMw 9eLsCcwDKD2nPgtDWlQJV8BD0xdUxlmHtEeN3QxMPc2mU/i8rsMJqwrCECZ3zE3Z VSa3v0msWTWuzUPkuI3QxmOXWO0UHD3FE0gvHOk/bKA9h1OnPioid1C4tUxrQ7yO h4mGFbFQfeV1FE6iwi6BGW+TGo8A+q0Ka8aC4pxtS0n6QFpUhKWWZX8UFS3J46Xa QrEcMKULzPutV9jo8NlWPM6zYfzfs9R7hYylqU7ZSjOK83KCweUF6bsw3AL4vhxN OpJHBg5qwv/K/ukJu3i505S9vNYpbcfCSqNNIN2E6rcRtCiE1fNhA5hitJs9BS0= =WFZs -----END PGP SIGNATURE----- --------------enigC669B9FBE6938CC9AFDC2A63-- From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count) Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 06 Jun 2012 13:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Anoop Sharma Cc: 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133898781815933 (code B ref 11631); Wed, 06 Jun 2012 13:04:01 +0000 Received: (at 11631) by debbugs.gnu.org; 6 Jun 2012 13:03:38 +0000 Received: from localhost ([127.0.0.1]:60187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScFth-00048v-Pi for submit@debbugs.gnu.org; Wed, 06 Jun 2012 09:03:37 -0400 Received: from mx.meyering.net ([88.168.87.75]:50817) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScFtf-00048n-GT for 11631@debbugs.gnu.org; Wed, 06 Jun 2012 09:03:36 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 4AD27600BA; Wed, 6 Jun 2012 15:01:25 +0200 (CEST) From: Jim Meyering In-Reply-To: <87y5o050mt.fsf@rho.meyering.net> (Jim Meyering's message of "Wed, 06 Jun 2012 10:02:18 +0200") References: <87haup5wfy.fsf@rho.meyering.net> <87y5o050mt.fsf@rho.meyering.net> Date: Wed, 06 Jun 2012 15:01:25 +0200 Message-ID: <87wr3k387u.fsf@rho.meyering.net> Lines: 23 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Jim Meyering wrote: > Anoop Sharma wrote: >> 1. The comment in code - "Don't bother testing for failure for such a >> small amount. Any failure will be detected upon close." may be >> re-looked too, since we are now lseeking after it. >> >> What if we change plain fwrite to: >> if (fwrite (buffer, 1, n + 1, stdout) < (n + 1)) >> error (EXIT_FAILURE, errno, _("write error")); ... > Regarding #1, thanks for the suggestion. You're right. Actually, the existing code is fine. I'm glad I didn't push that change in your name. It's not that it would introduce a bug or anything, but the rationale was incorrect: The fwrite affects only the output stream, stdout, while the lseek operates on the input file descriptor, so they are independent, and the comment is still valid. The only possible overlap is errno, but if lseek fails, we now exit immediately, so whether close_stdout has an errno or not is irrelevant. From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count) Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Wed, 06 Jun 2012 13:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: Anoop Sharma , 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133898831416607 (code B ref 11631); Wed, 06 Jun 2012 13:12:02 +0000 Received: (at 11631) by debbugs.gnu.org; 6 Jun 2012 13:11:54 +0000 Received: from localhost ([127.0.0.1]:60194 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScG1h-0004Jn-KA for submit@debbugs.gnu.org; Wed, 06 Jun 2012 09:11:53 -0400 Received: from mx.meyering.net ([88.168.87.75]:50845) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScG1f-0004Jf-FX for 11631@debbugs.gnu.org; Wed, 06 Jun 2012 09:11:52 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 2DE256010C; Wed, 6 Jun 2012 15:09:42 +0200 (CEST) From: Jim Meyering In-Reply-To: <4FCF4477.1070608@redhat.com> (Eric Blake's message of "Wed, 06 Jun 2012 05:52:23 -0600") References: <87haup5wfy.fsf@rho.meyering.net> <87y5o050mt.fsf@rho.meyering.net> <4FCF4477.1070608@redhat.com> Date: Wed, 06 Jun 2012 15:09:42 +0200 Message-ID: <87txyo37u1.fsf@rho.meyering.net> Lines: 49 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Eric Blake wrote: > On 06/06/2012 02:02 AM, Jim Meyering wrote: > >> +++ b/src/head.c >> @@ -663,10 +663,9 @@ elide_tail_lines_seekable (const char *pretty_filename, int fd, >> } >> >> /* Output the initial portion of the buffer >> - in which we found the desired newline byte. >> - Don't bother testing for failure for such a small amount. >> - Any failure will be detected upon close. */ >> - fwrite (buffer, 1, n + 1, stdout); >> + in which we found the desired newline byte. */ >> + if (fwrite (buffer, 1, n + 1, stdout) < n + 1) >> + error (EXIT_FAILURE, errno, _("write error")); > > Is testing for fwrite() sufficient? Shouldn't you actually be testing > for fflush() errors, since fwrite() buffers the output and might not Hi Eric, There is no need (or desire) for explicit fflush here. Relying on our atexit-invoked close_stdout is enough. > actually encounter an error until it flushes? Or even on NFS, where > fflush() may succeed but fclose() fails? In other words, our atexit() > handler for detecting fclose() failure will already catch things; we may > still be in a situation where fwrite() succeeds, we then do lseek(), but > fclose() fails, in spite of our efforts. I don't see how this patch > improves anything, other than earlier error reporting. Adding the fwrite test would be important solely if we were required to diagnose-with-errno a failure that occurs when this fwrite actually happens to perform a write syscall. Without the new test, the fwrite can fail, leading the eventual close_stdout call to emit the dumbed-down diagnostic (no strerror part) that it must emit when ferror indicates a previous error yet fclose does not fail. It's a hard call. This fwrite is not in a loop (it's printing only a fraction of a read buffer), so the cost of the test is negligible, but similarly, there's a relatively small risk that, assuming we'll get a write failure, it will happen while printing this relatively small amount of data. Thanks for making me think more about it. There are many other unchecked uses of fwrite in head.c, and I cannot justify adding tests for all of them. As you probably saw, I have retracted the proposed change. From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count) Resent-From: Anoop Sharma Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 07 Jun 2012 14:40:07 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Jim Meyering Cc: Eric Blake , 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133908000432766 (code B ref 11631); Thu, 07 Jun 2012 14:40:07 +0000 Received: (at 11631) by debbugs.gnu.org; 7 Jun 2012 14:40:04 +0000 Received: from localhost ([127.0.0.1]:33668 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScdsY-0008WO-VU for submit@debbugs.gnu.org; Thu, 07 Jun 2012 10:40:04 -0400 Received: from mail-ee0-f44.google.com ([74.125.83.44]:45965) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScdsR-0008W0-EB for 11631@debbugs.gnu.org; Thu, 07 Jun 2012 10:39:59 -0400 Received: by eekd4 with SMTP id d4so313477eek.3 for <11631@debbugs.gnu.org>; Thu, 07 Jun 2012 07:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=PPK3xgPVY00m8ptzk0mv0D3Rh/9UYtMoHf34rFvwBoY=; b=IvtOPYS38GFYwViPuQn700yet//bIstxF0s4F+hqME7PZyv22JS3kwQ6iiDijtIXnE fsakESlWsAaJW38DHZGcwN/LDrcrkJ0v8/u8+K7Sl3WT9p5kHjSdWq6hop7ER4eoJok3 uXFT88Uwn0CrQxfbv+cG6v2ic/sWesZiBObBdF54wlAoCwyneAi04kFCUbzMkkoM4jTk GORElhht3Rop75Wint/G4LIrLMc7/S2AHiXgRNMaiRd3IFRYgwa/Ibl3Or35pcMJuqbQ 27W5H8RD44ltiDuQnboaa0gP3hk7nrJ0YP1VYWKwbkjdVDkJzaU4E6mkF7/nfhkoicKQ RHgA== Received: by 10.14.119.197 with SMTP id n45mr1313026eeh.204.1339079855146; Thu, 07 Jun 2012 07:37:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.223.3 with HTTP; Thu, 7 Jun 2012 07:37:14 -0700 (PDT) In-Reply-To: <87txyo37u1.fsf@rho.meyering.net> References: <87haup5wfy.fsf@rho.meyering.net> <87y5o050mt.fsf@rho.meyering.net> <4FCF4477.1070608@redhat.com> <87txyo37u1.fsf@rho.meyering.net> From: Anoop Sharma Date: Thu, 7 Jun 2012 20:07:14 +0530 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) The thought behind the proposed change was that lseek should reflect the amount of data that head has actually been able to print. For example, how do we want head to behave in a situation like the following where files more than a particular size are not allowed (with bash shell on a machine with block size of 1024 bytes)? This situation can be handled by applying this patch. I agree this example is custom designed to illustrate my point but what do we gain by not making the check?: ulimit -f 1; trap '' SIGXFSZ (stdbuf -o0 head -n -1025 >someOutFile; cat) wrote: > Eric Blake wrote: >> On 06/06/2012 02:02 AM, Jim Meyering wrote: >> >>> +++ b/src/head.c >>> @@ -663,10 +663,9 @@ elide_tail_lines_seekable (const char *pretty_file= name, int fd, >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Output the initial portion of the buf= fer >>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in which we found the desired newline= byte. >>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Don't bother testing for failure for = such a small amount. >>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Any failure will be detected upon clo= se. =A0*/ >>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0fwrite (buffer, 1, n + 1, stdout); >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in which we found the desired newline= byte. =A0*/ >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0if (fwrite (buffer, 1, n + 1, stdout) < n = + 1) >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0error (EXIT_FAILURE, errno, _("write e= rror")); >> >> Is testing for fwrite() sufficient? =A0Shouldn't you actually be testing >> for fflush() errors, since fwrite() buffers the output and might not > > Hi Eric, > > There is no need (or desire) for explicit fflush here. > Relying on our atexit-invoked close_stdout is enough. > >> actually encounter an error until it flushes? =A0Or even on NFS, where >> fflush() may succeed but fclose() fails? =A0In other words, our atexit() >> handler for detecting fclose() failure will already catch things; we may >> still be in a situation where fwrite() succeeds, we then do lseek(), but >> fclose() fails, in spite of our efforts. =A0I don't see how this patch >> improves anything, other than earlier error reporting. > > Adding the fwrite test would be important solely if we were required > to diagnose-with-errno a failure that occurs when this fwrite actually > happens to perform a write syscall. =A0Without the new test, the fwrite > can fail, leading the eventual close_stdout call to emit the dumbed-down > diagnostic (no strerror part) that it must emit when ferror indicates > a previous error yet fclose does not fail. > > It's a hard call. =A0This fwrite is not in a loop (it's printing only > a fraction of a read buffer), so the cost of the test is negligible, > but similarly, there's a relatively small risk that, assuming we'll get > a write failure, it will happen while printing this relatively small > amount of data. > > Thanks for making me think more about it. > There are many other unchecked uses of fwrite in head.c, > and I cannot justify adding tests for all of them. > > As you probably saw, I have retracted the proposed change. From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count) Resent-From: Jim Meyering Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 07 Jun 2012 17:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Anoop Sharma Cc: Eric Blake , 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133909089722694 (code B ref 11631); Thu, 07 Jun 2012 17:42:02 +0000 Received: (at 11631) by debbugs.gnu.org; 7 Jun 2012 17:41:37 +0000 Received: from localhost ([127.0.0.1]:33778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScgiG-0005tw-DF for submit@debbugs.gnu.org; Thu, 07 Jun 2012 13:41:37 -0400 Received: from mx.meyering.net ([88.168.87.75]:55599) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Scghu-0005tU-Mc for 11631@debbugs.gnu.org; Thu, 07 Jun 2012 13:41:34 -0400 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 7153060073; Thu, 7 Jun 2012 19:38:58 +0200 (CEST) From: Jim Meyering In-Reply-To: (Anoop Sharma's message of "Thu, 7 Jun 2012 20:07:14 +0530") References: <87haup5wfy.fsf@rho.meyering.net> <87y5o050mt.fsf@rho.meyering.net> <4FCF4477.1070608@redhat.com> <87txyo37u1.fsf@rho.meyering.net> Date: Thu, 07 Jun 2012 19:38:58 +0200 Message-ID: <87r4trt425.fsf@rho.meyering.net> Lines: 41 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Anoop Sharma wrote: > The thought behind the proposed change was that lseek should reflect > the amount of data that head has actually been able to print. > > For example, how do we want head to behave in a situation like the > following where files more than a particular size are not allowed > (with bash shell on a machine with block size of 1024 bytes)? This > situation can be handled by applying this patch. I agree this example > is custom designed to illustrate my point but what do we gain by not > making the check?: > > ulimit -f 1; trap '' SIGXFSZ > (stdbuf -o0 head -n -1025 >someOutFile; cat) > What should cat print now? > > By detecting fwrite failure, we can increment file pointer by the > amount that was written successfully. > That was what I originally wanted to accomplish. However, I looked at > the existing implementation of head.c and found that a stock behavior > on fwrite failures was to exit and afraid to rock the boat too much, I > proposed that. > > I agree that the checking for fwrite failure is not fool-proof. But it > looks better than ignoring the return value. While head is ignoring that return value, it is not really ignoring the failure. That would be a bug. Rather, head is relying on the fact that the stream records the failure, and that our atexit-invoked close_stdout function will detect the prior failure (via ferror(stdout)) and diagnose it. In practice, testing for fwrite failure will make no difference, other than adding a small amount to the size of "head". Regarding your example, what you've done above (turning off buffering) is very unusual. That doesn't seem like a case worth catering to. And besides, since in general we don't know how much a failing fwrite function has actually written, there can be no guarantee that the input stream position somehow reflects what was written. From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count) Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 07 Jun 2012 17:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Anoop Sharma Cc: Jim Meyering , 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133909127423296 (code B ref 11631); Thu, 07 Jun 2012 17:48:02 +0000 Received: (at 11631) by debbugs.gnu.org; 7 Jun 2012 17:47:54 +0000 Received: from localhost ([127.0.0.1]:33806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScgoL-00063g-Mh for submit@debbugs.gnu.org; Thu, 07 Jun 2012 13:47:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23232) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ScgoI-00063P-Ub for 11631@debbugs.gnu.org; Thu, 07 Jun 2012 13:47:53 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q57HjTdA001041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jun 2012 13:45:29 -0400 Received: from [10.3.113.60] (ovpn-113-60.phx2.redhat.com [10.3.113.60]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q57HjRch012290; Thu, 7 Jun 2012 13:45:28 -0400 Message-ID: <4FD0E8B7.7090204@redhat.com> Date: Thu, 07 Jun 2012 11:45:27 -0600 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 References: <87haup5wfy.fsf@rho.meyering.net> <87y5o050mt.fsf@rho.meyering.net> <4FCF4477.1070608@redhat.com> <87txyo37u1.fsf@rho.meyering.net> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigEC2B129F4E0AAE08AE7AA952" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Spam-Score: -6.9 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC2B129F4E0AAE08AE7AA952 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [please don't top-post on technical lists] On 06/07/2012 08:37 AM, Anoop Sharma wrote: > The thought behind the proposed change was that lseek should reflect > the amount of data that head has actually been able to print. But that's not generically possible to know. >=20 > For example, how do we want head to behave in a situation like the > following where files more than a particular size are not allowed > (with bash shell on a machine with block size of 1024 bytes)? This > situation can be handled by applying this patch. I agree this example > is custom designed to illustrate my point but what do we gain by not > making the check?: >=20 > ulimit -f 1; trap '' SIGXFSZ > (stdbuf -o0 head -n -1025 >someOutFile; cat) =20 > What should cat print now? Bogus question. That's a bug in your shell scripting - if you are worried about partial processing errors, then you must check all intermediate steps: ulimit -f 1; trap '' SIGXFSZ (stdbuf -o0 head -n -1025 >someOutFile && cat) Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 08 Jun 2012 20:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Jim Meyering Cc: Eric Blake , 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.13391861139783 (code B ref 11631); Fri, 08 Jun 2012 20:09:01 +0000 Received: (at 11631) by debbugs.gnu.org; 8 Jun 2012 20:08:33 +0000 Received: from localhost ([127.0.0.1]:35402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sd5U0-0002Xj-HJ for submit@debbugs.gnu.org; Fri, 08 Jun 2012 16:08:32 -0400 Received: from mail-ey0-f172.google.com ([209.85.215.172]:51750) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sd5Tx-0002Xa-VD for 11631@debbugs.gnu.org; Fri, 08 Jun 2012 16:08:30 -0400 Received: by eaaq13 with SMTP id q13so1450842eaa.3 for <11631@debbugs.gnu.org>; Fri, 08 Jun 2012 13:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=nxWjEkbD4RC2ZjlWqvVqLrBYrTDK2LB/Ur+SBMROASc=; b=oB6Jr9lBxj7dbrF2dlWp8Sr7HFFqf1Pzm3wN5tlgOXwkrpkNBjnUvpI1Zn/6R/EQLQ oUo/Q8K1QN0ErA1GAV1BCY5e9KYJaiGvq5QEIIl5ay7O6naUtdd2D6/YkMZOZPmiSknb gvkXtapT5hB3vmuPlwPwzYmz92WZujuykpuT2Evjh4HPvrUyiYsjLh9Y+1iU3oztjBb0 SH1QBz566rHauQWwWen/U4g/hAx3TFzZ1XRjM4T3Ha4pX46/OJnesNVQmaINqX31GQA9 Jsg7Gty4fyA+9zkwQKjoqe4qgaG9lzlopuJqFolbw5ZixLgs9kKf/+VFSaaYCHgPy+I7 xSuQ== Received: by 10.14.53.73 with SMTP id f49mr4262952eec.65.1339185967911; Fri, 08 Jun 2012 13:06:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.223.3 with HTTP; Fri, 8 Jun 2012 13:05:46 -0700 (PDT) In-Reply-To: <87r4trt425.fsf@rho.meyering.net> References: <87haup5wfy.fsf@rho.meyering.net> <87y5o050mt.fsf@rho.meyering.net> <4FCF4477.1070608@redhat.com> <87txyo37u1.fsf@rho.meyering.net> <87r4trt425.fsf@rho.meyering.net> From: Anoop Sharma Date: Sat, 9 Jun 2012 01:35:46 +0530 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Thu, Jun 7, 2012 at 11:08 PM, Jim Meyering wrote: > Anoop Sharma wrote: >> The thought behind the proposed change was that lseek should reflect >> the amount of data that head has actually been able to print. >> >> For example, how do we want head to behave in a situation like the >> following where files more than a particular size are not allowed >> (with bash shell on a machine with block size of 1024 bytes)? This >> situation can be handled by applying this patch. I agree this example >> is custom designed to illustrate my point but what do we gain by not >> making the check?: >> >> ulimit -f 1; trap '' SIGXFSZ >> (stdbuf -o0 head -n -1025 >someOutFile; cat) > >> What should cat print now? >> >> By detecting fwrite failure, we can increment file pointer by the >> amount that was written successfully. >> That was what I originally wanted to accomplish. However, I looked at >> the existing implementation of head.c and found that a stock behavior >> on fwrite failures was to exit and afraid to rock the boat too much, I >> proposed that. >> >> I agree that the checking for fwrite failure is not fool-proof. But it >> looks better than ignoring the return value. > > While head is ignoring that return value, > it is not really ignoring the failure. =A0That would be a bug. > > Rather, head is relying on the fact that the stream records the failure, > and that our atexit-invoked close_stdout function will detect the prior > failure (via ferror(stdout)) and diagnose it. > > In practice, testing for fwrite failure will make no difference, > other than adding a small amount to the size of "head". > > Regarding your example, what you've done above (turning off buffering) > is very unusual. =A0That doesn't seem like a case worth catering to. > And besides, since in general we don't know how much a failing fwrite > function has actually written, there can be no guarantee that the input > stream position somehow reflects what was written. Thank you. I get it now. From unknown Tue Aug 19 05:08:57 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count) Resent-From: Anoop Sharma Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 08 Jun 2012 20:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11631 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Eric Blake Cc: Jim Meyering , 11631@debbugs.gnu.org Received: via spool by 11631-submit@debbugs.gnu.org id=B11631.133918630310052 (code B ref 11631); Fri, 08 Jun 2012 20:12:01 +0000 Received: (at 11631) by debbugs.gnu.org; 8 Jun 2012 20:11:43 +0000 Received: from localhost ([127.0.0.1]:35406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sd5X5-0002c5-4t for submit@debbugs.gnu.org; Fri, 08 Jun 2012 16:11:43 -0400 Received: from mail-ey0-f172.google.com ([209.85.215.172]:32781) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sd5X2-0002bw-Ls for 11631@debbugs.gnu.org; Fri, 08 Jun 2012 16:11:41 -0400 Received: by eaaq13 with SMTP id q13so1451606eaa.3 for <11631@debbugs.gnu.org>; Fri, 08 Jun 2012 13:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=E9ASsTcRckaVBArsGmyB/QQKh75UXxiFY8nZnhgjPfU=; b=idZKMEr0HUNyjbDewnOBe84PtaYvY9gzbUnSFM/h2ZR3wgyRyBmbdBFHj4/ONWWrGw UbrLEsuD9jRKBt/Kgp8xRsCTk5YVbwVad/C6CFjNbbOIyR7lmED9KFqomeSnJcCF7JJW dtD4vWqDquEL0LonLqdQcT66SFFwxGnWUzUSv7d3m+wt0I9EPC5RB8R8zI5P/j/gQqZo d0Edi+j5GbNyOVVuDCnv/n8/eUSI8mI4P+vcmNDxW96d4b2fT/MaHUX84su0Az+hx7UB PpEh0CZq3Rww14VcNX4MVW8M7Jqnkg12jN2/Azh3Ni4Tb0bjxdW03SHEIdnO3dYrgHha UiWQ== Received: by 10.14.96.10 with SMTP id q10mr4162286eef.14.1339186158758; Fri, 08 Jun 2012 13:09:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.223.3 with HTTP; Fri, 8 Jun 2012 13:08:57 -0700 (PDT) In-Reply-To: <4FD0E8B7.7090204@redhat.com> References: <87haup5wfy.fsf@rho.meyering.net> <87y5o050mt.fsf@rho.meyering.net> <4FCF4477.1070608@redhat.com> <87txyo37u1.fsf@rho.meyering.net> <4FD0E8B7.7090204@redhat.com> From: Anoop Sharma Date: Sat, 9 Jun 2012 01:38:57 +0530 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Thu, Jun 7, 2012 at 11:15 PM, Eric Blake wrote: > [please don't top-post on technical lists] > > On 06/07/2012 08:37 AM, Anoop Sharma wrote: >> The thought behind the proposed change was that lseek should reflect >> the amount of data that head has actually been able to print. > > But that's not generically possible to know. > >> >> For example, how do we want head to behave in a situation like the >> following where files more than a particular size are not allowed >> (with bash shell on a machine with block size of 1024 bytes)? This >> situation can be handled by applying this patch. I agree this example >> is custom designed to illustrate my point but what do we gain by not >> making the check?: >> >> ulimit -f 1; trap '' SIGXFSZ >> (stdbuf -o0 head -n -1025 >someOutFile; cat) > >> What should cat print now? > > Bogus question. =A0That's a bug in your shell scripting - if you are > worried about partial processing errors, then you must check all > intermediate steps: > > ulimit -f 1; trap '' SIGXFSZ > (stdbuf -o0 head -n -1025 >someOutFile && cat) > That is, you should have used && rather than ;, so that cat prints > nothing on error. > > -- > Eric Blake =A0 eblake@redhat.com =A0 =A0+1-919-301-3266 > Libvirt virtualization library http://libvirt.org > Thank you. I understand your perspective now.