From unknown Mon Aug 18 17:53:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes Resent-From: Bjoern Voigt Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Mon, 13 Jun 2016 19:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 23763 X-GNU-PR-Package: grep X-GNU-PR-Keywords: To: 23763@debbugs.gnu.org X-Debbugs-Original-To: bug-grep@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.146584769416695 (code B ref -1); Mon, 13 Jun 2016 19:55:02 +0000 Received: (at submit) by debbugs.gnu.org; 13 Jun 2016 19:54:54 +0000 Received: from localhost ([127.0.0.1]:39282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCXwk-0004LD-5S for submit@debbugs.gnu.org; Mon, 13 Jun 2016 15:54:54 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39571) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCXnu-00047e-VJ for submit@debbugs.gnu.org; Mon, 13 Jun 2016 15:45:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCXno-0006hT-NR for submit@debbugs.gnu.org; Mon, 13 Jun 2016 15:45:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:43378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCXno-0006hK-KA for submit@debbugs.gnu.org; Mon, 13 Jun 2016 15:45:40 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCXnm-0004cK-3C for bug-grep@gnu.org; Mon, 13 Jun 2016 15:45:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCXni-0006gI-Qe for bug-grep@gnu.org; Mon, 13 Jun 2016 15:45:38 -0400 Received: from mail-in-14.arcor-online.net ([151.189.21.54]:34752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCXni-0006f7-Du for bug-grep@gnu.org; Mon, 13 Jun 2016 15:45:34 -0400 Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mx.arcor.de (Postfix) with ESMTP id 3rT3Cw1qBSz8FMm for ; Mon, 13 Jun 2016 21:45:32 +0200 (CEST) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 39FD71F6765; Mon, 13 Jun 2016 21:45:32 +0200 (CEST) X-Greylist: Passed host: 5.61.157.201 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-09.arcor-online.net 3rT3Cv6zwJzB4Hm DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1465847132; bh=bFgorfturl+h4lu26zYFzUfI26MIgwsc2nG4jNzcxKg=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=YX8ZcwsVRwNpCUe66oKRh0oTHaB9dVfDsQVC3Q1OOK4OKFi20NnFJuup8e4kIFlx5 upQwXMQXNEhb5pQ/Xvr6Ob2B+aWjy3HvHYlpJhFu2CW3v37wEFl/D3luH4ThpoIJGR 38qgnaZM+qY6ZlfAAxXnvgZPhYBwIVrekLL14KXI= X-Greylist: Passed host: 5.61.157.201 Received: from [192.168.115.2] (053d9dc9.dynamic.tele-ag.de [5.61.157.201]) (Authenticated sender: bjoernv@arcor.de) by mail-in-09.arcor-online.net (Postfix) with ESMTPSA id 3rT3Cv6zwJzB4Hm; Mon, 13 Jun 2016 21:45:31 +0200 (CEST) From: Bjoern Voigt Message-ID: <575F0D5A.9080107@arcor.de> Date: Mon, 13 Jun 2016 21:45:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Mailman-Approved-At: Mon, 13 Jun 2016 15:54:52 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) Grep shows a bug, if it processes a text file with at least one embedded 0 (ASCII zero) character after byte 32768. Grep stops with the error message "Binary file testfile.txt matches" and exit code 0. The error message is written to standard output. Any line after the 0 character is silently ignored in output. Environment: - grep-2.25 - no patches, no "configure" options - openSUSE Tumbleweed 20160611 x86_64; glibc 2.23; libpcre 8.38 I saw this bug first, as I tried to filter out a line of the MySQL backup utility "mysqldump". Because grep stopped at the 0 character, the backups where incomplete. # mysqldump --all-databases | grep -v '^-- Dump completed on' [... around 240 lines of SQL output ...] LOCK TABLES `PartTable` WRITE; /*!40000 ALTER TABLE `PartTable` DISABLE KEYS */; Binary file (standard input) matches mysqldump: Got errno 32 on write I found that the mysqldump output contains 0 characters in table PartTabl= e. I wrote the following test script, which shows the bug without a dependency to MySQL: -------------------------------------------------------- #!/bin/bash testfile=3D"testfile.txt" # write a text file large enough (16384 lines is # the minimum number for this test case) for((i=3D1;i<=3D16384;i++)) do echo "A"; done > $testfile # write a zero byte echo -e '\0' >> $testfile # write an end line echo -e 'A ... the end' >> $testfile # verify the file contents ls -l $testfile tail -n 10 $testfile # use 'grep' to find all lines with the string "A" grep "A" $testfile # the last line is missing, the output ends with # "Binary file testfile.txt matches" # check the exit code echo "Exit code of grep:" $? -------------------------------------------------------- The last line "A ... the end" is missing in output of grep. The exit code is 0: # ./null-bug-testcase.txt [...] A A A Binary file testfile.txt matches Exit code of grep: 0 I also found this bug in older grep versions (e.g. Ubuntu 14.04; grep 2.1= 6). FreeBSD's version of grep (tested with 2.5.1-FreeBSD under FreeBSD 10.3-RELEASE-p4) does not show the bug: #./null-bug-testcase.txt [...] A A A A ... the end Exit code of grep: 0 Regards, Bj=C3=B6rn From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 13 16:01:35 2016 Received: (at control) by debbugs.gnu.org; 13 Jun 2016 20:01:35 +0000 Received: from localhost ([127.0.0.1]:39299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCY3C-0005kr-KG for submit@debbugs.gnu.org; Mon, 13 Jun 2016 16:01:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCY3A-0005hB-6i; Mon, 13 Jun 2016 16:01:32 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B2A1D7AE91; Mon, 13 Jun 2016 20:01:29 +0000 (UTC) Received: from [10.3.116.126] (ovpn-116-126.phx2.redhat.com [10.3.116.126]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5DK1T68012124; Mon, 13 Jun 2016 16:01:29 -0400 Subject: Re: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes To: Bjoern Voigt , 23763-done@debbugs.gnu.org References: <575F0D5A.9080107@arcor.de> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Organization: Red Hat, Inc. Message-ID: <575F1118.3050700@redhat.com> Date: Mon, 13 Jun 2016 14:01:28 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <575F0D5A.9080107@arcor.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DaQMJaMpulKuw3lSQT2EnUBx8vS4PCsSG" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 13 Jun 2016 20:01:29 +0000 (UTC) X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DaQMJaMpulKuw3lSQT2EnUBx8vS4PCsSG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable tag 23763 notabug thanks On 06/13/2016 01:45 PM, Bjoern Voigt wrote: > Grep shows a bug, if it processes a text file with at least one embedde= d > 0 (ASCII zero) character after byte 32768. Thanks for the report. However, this is not a bug in grep, but documented behavior. By definition, a text file CANNOT contain NUL bytes; any file with NUL characters is a binary file. You can still make grep process it as a text file, but only with the '-a' flag. > Grep stops with the error > message "Binary file testfile.txt matches" and exit code 0. The error > message is written to standard output. Any line after the 0 character i= s > silently ignored in output. POSIX allows this behavior, in that it says that grep's behavior is undefined on non-text files (which you have by virtue of your NUL byte). Since this is documented behavior of GNU grep when -a is not used, I'm closing this as not a bug. But feel free to add further comments to this thread. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --DaQMJaMpulKuw3lSQT2EnUBx8vS4PCsSG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXXxEYAAoJEKeha0olJ0NqOWAH+gI/usQTQ7MPIBev0Zt7lKpR 7ZMv5gBXDt5n6T37o6UUqRIajNMlF6SNAwI6iq+BjRybPCw7sC/LJl68OBOKFEaQ Hwf033shX3qbpFEgRyScxSWcjYbUQvjpJnBXTCg+rrw4VSvDFRgqh9OwrYdfIRzO HrbqKwpmijaXjAZfjd/8s1dpuXlIyF0bGeTJhVHXjvg9x0iltHWNYJX3lzz7tohs wW31r+0CPdjJZa00KX+AbusyZMcw/yAedVDwxMC5HMjcJl8QxBsMngZi3dOQk9xK 7XNB5gRFgd5/sGL7Swln4Mks8a+sOtWMyuQlYh/00Bpl9p8x6ndXGomrSI74fzM= =XaOf -----END PGP SIGNATURE----- --DaQMJaMpulKuw3lSQT2EnUBx8vS4PCsSG-- From unknown Mon Aug 18 17:53:42 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Bjoern Voigt Subject: bug#23763: closed (Re: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes) Message-ID: References: <575F1118.3050700@redhat.com> <575F0D5A.9080107@arcor.de> X-Gnu-PR-Message: they-closed 23763 X-Gnu-PR-Package: grep X-Gnu-PR-Keywords: notabug Reply-To: 23763@debbugs.gnu.org Date: Mon, 13 Jun 2016 20:02:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1465848122-23387-1" This is a multi-part message in MIME format... ------------=_1465848122-23387-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #23763: Bug report: Grep stops, if a text file contains a null character af= ter 32768 bytes which was filed against the grep package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 23763@debbugs.gnu.org. --=20 23763: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D23763 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1465848122-23387-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 23763-done) by debbugs.gnu.org; 13 Jun 2016 20:01:34 +0000 Received: from localhost ([127.0.0.1]:39297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCY3C-0005kf-94 for submit@debbugs.gnu.org; Mon, 13 Jun 2016 16:01:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCY3A-0005hB-6i; Mon, 13 Jun 2016 16:01:32 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B2A1D7AE91; Mon, 13 Jun 2016 20:01:29 +0000 (UTC) Received: from [10.3.116.126] (ovpn-116-126.phx2.redhat.com [10.3.116.126]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5DK1T68012124; Mon, 13 Jun 2016 16:01:29 -0400 Subject: Re: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes To: Bjoern Voigt , 23763-done@debbugs.gnu.org References: <575F0D5A.9080107@arcor.de> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Organization: Red Hat, Inc. Message-ID: <575F1118.3050700@redhat.com> Date: Mon, 13 Jun 2016 14:01:28 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <575F0D5A.9080107@arcor.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DaQMJaMpulKuw3lSQT2EnUBx8vS4PCsSG" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 13 Jun 2016 20:01:29 +0000 (UTC) X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 23763-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DaQMJaMpulKuw3lSQT2EnUBx8vS4PCsSG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable tag 23763 notabug thanks On 06/13/2016 01:45 PM, Bjoern Voigt wrote: > Grep shows a bug, if it processes a text file with at least one embedde= d > 0 (ASCII zero) character after byte 32768. Thanks for the report. However, this is not a bug in grep, but documented behavior. By definition, a text file CANNOT contain NUL bytes; any file with NUL characters is a binary file. You can still make grep process it as a text file, but only with the '-a' flag. > Grep stops with the error > message "Binary file testfile.txt matches" and exit code 0. The error > message is written to standard output. Any line after the 0 character i= s > silently ignored in output. POSIX allows this behavior, in that it says that grep's behavior is undefined on non-text files (which you have by virtue of your NUL byte). Since this is documented behavior of GNU grep when -a is not used, I'm closing this as not a bug. But feel free to add further comments to this thread. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --DaQMJaMpulKuw3lSQT2EnUBx8vS4PCsSG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXXxEYAAoJEKeha0olJ0NqOWAH+gI/usQTQ7MPIBev0Zt7lKpR 7ZMv5gBXDt5n6T37o6UUqRIajNMlF6SNAwI6iq+BjRybPCw7sC/LJl68OBOKFEaQ Hwf033shX3qbpFEgRyScxSWcjYbUQvjpJnBXTCg+rrw4VSvDFRgqh9OwrYdfIRzO HrbqKwpmijaXjAZfjd/8s1dpuXlIyF0bGeTJhVHXjvg9x0iltHWNYJX3lzz7tohs wW31r+0CPdjJZa00KX+AbusyZMcw/yAedVDwxMC5HMjcJl8QxBsMngZi3dOQk9xK 7XNB5gRFgd5/sGL7Swln4Mks8a+sOtWMyuQlYh/00Bpl9p8x6ndXGomrSI74fzM= =XaOf -----END PGP SIGNATURE----- --DaQMJaMpulKuw3lSQT2EnUBx8vS4PCsSG-- ------------=_1465848122-23387-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 13 Jun 2016 19:54:54 +0000 Received: from localhost ([127.0.0.1]:39282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCXwk-0004LD-5S for submit@debbugs.gnu.org; Mon, 13 Jun 2016 15:54:54 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39571) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCXnu-00047e-VJ for submit@debbugs.gnu.org; Mon, 13 Jun 2016 15:45:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCXno-0006hT-NR for submit@debbugs.gnu.org; Mon, 13 Jun 2016 15:45:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:43378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCXno-0006hK-KA for submit@debbugs.gnu.org; Mon, 13 Jun 2016 15:45:40 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCXnm-0004cK-3C for bug-grep@gnu.org; Mon, 13 Jun 2016 15:45:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCXni-0006gI-Qe for bug-grep@gnu.org; Mon, 13 Jun 2016 15:45:38 -0400 Received: from mail-in-14.arcor-online.net ([151.189.21.54]:34752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCXni-0006f7-Du for bug-grep@gnu.org; Mon, 13 Jun 2016 15:45:34 -0400 Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mx.arcor.de (Postfix) with ESMTP id 3rT3Cw1qBSz8FMm for ; Mon, 13 Jun 2016 21:45:32 +0200 (CEST) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id 39FD71F6765; Mon, 13 Jun 2016 21:45:32 +0200 (CEST) X-Greylist: Passed host: 5.61.157.201 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-09.arcor-online.net 3rT3Cv6zwJzB4Hm DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1465847132; bh=bFgorfturl+h4lu26zYFzUfI26MIgwsc2nG4jNzcxKg=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=YX8ZcwsVRwNpCUe66oKRh0oTHaB9dVfDsQVC3Q1OOK4OKFi20NnFJuup8e4kIFlx5 upQwXMQXNEhb5pQ/Xvr6Ob2B+aWjy3HvHYlpJhFu2CW3v37wEFl/D3luH4ThpoIJGR 38qgnaZM+qY6ZlfAAxXnvgZPhYBwIVrekLL14KXI= X-Greylist: Passed host: 5.61.157.201 Received: from [192.168.115.2] (053d9dc9.dynamic.tele-ag.de [5.61.157.201]) (Authenticated sender: bjoernv@arcor.de) by mail-in-09.arcor-online.net (Postfix) with ESMTPSA id 3rT3Cv6zwJzB4Hm; Mon, 13 Jun 2016 21:45:31 +0200 (CEST) To: bug-grep@gnu.org From: Bjoern Voigt Subject: Bug report: Grep stops, if a text file contains a null character after 32768 bytes Message-ID: <575F0D5A.9080107@arcor.de> Date: Mon, 13 Jun 2016 21:45:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 13 Jun 2016 15:54:52 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) Grep shows a bug, if it processes a text file with at least one embedded 0 (ASCII zero) character after byte 32768. Grep stops with the error message "Binary file testfile.txt matches" and exit code 0. The error message is written to standard output. Any line after the 0 character is silently ignored in output. Environment: - grep-2.25 - no patches, no "configure" options - openSUSE Tumbleweed 20160611 x86_64; glibc 2.23; libpcre 8.38 I saw this bug first, as I tried to filter out a line of the MySQL backup utility "mysqldump". Because grep stopped at the 0 character, the backups where incomplete. # mysqldump --all-databases | grep -v '^-- Dump completed on' [... around 240 lines of SQL output ...] LOCK TABLES `PartTable` WRITE; /*!40000 ALTER TABLE `PartTable` DISABLE KEYS */; Binary file (standard input) matches mysqldump: Got errno 32 on write I found that the mysqldump output contains 0 characters in table PartTabl= e. I wrote the following test script, which shows the bug without a dependency to MySQL: -------------------------------------------------------- #!/bin/bash testfile=3D"testfile.txt" # write a text file large enough (16384 lines is # the minimum number for this test case) for((i=3D1;i<=3D16384;i++)) do echo "A"; done > $testfile # write a zero byte echo -e '\0' >> $testfile # write an end line echo -e 'A ... the end' >> $testfile # verify the file contents ls -l $testfile tail -n 10 $testfile # use 'grep' to find all lines with the string "A" grep "A" $testfile # the last line is missing, the output ends with # "Binary file testfile.txt matches" # check the exit code echo "Exit code of grep:" $? -------------------------------------------------------- The last line "A ... the end" is missing in output of grep. The exit code is 0: # ./null-bug-testcase.txt [...] A A A Binary file testfile.txt matches Exit code of grep: 0 I also found this bug in older grep versions (e.g. Ubuntu 14.04; grep 2.1= 6). FreeBSD's version of grep (tested with 2.5.1-FreeBSD under FreeBSD 10.3-RELEASE-p4) does not show the bug: #./null-bug-testcase.txt [...] A A A A ... the end Exit code of grep: 0 Regards, Bj=C3=B6rn ------------=_1465848122-23387-1-- From unknown Mon Aug 18 17:53:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes Resent-From: Bjoern Voigt Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Mon, 13 Jun 2016 20:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23763 X-GNU-PR-Package: grep X-GNU-PR-Keywords: notabug To: 23763@debbugs.gnu.org Cc: Eric Blake Received: via spool by 23763-submit@debbugs.gnu.org id=B23763.14658511678046 (code B ref 23763); Mon, 13 Jun 2016 20:53:02 +0000 Received: (at 23763) by debbugs.gnu.org; 13 Jun 2016 20:52:47 +0000 Received: from localhost ([127.0.0.1]:39335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCYql-00025i-Gz for submit@debbugs.gnu.org; Mon, 13 Jun 2016 16:52:47 -0400 Received: from mail-in-05.arcor-online.net ([151.189.21.45]:38573) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCYqj-00025V-VG for 23763@debbugs.gnu.org; Mon, 13 Jun 2016 16:52:46 -0400 Received: from mail-in-15-z2.arcor-online.net (mail-in-15-z2.arcor-online.net [151.189.8.32]) by mx.arcor.de (Postfix) with ESMTP id 3rT4jM49CGz25dW; Mon, 13 Jun 2016 22:52:39 +0200 (CEST) Received: from mail-in-14.arcor-online.net (mail-in-14.arcor-online.net [151.189.21.54]) by mail-in-15-z2.arcor-online.net (Postfix) with ESMTP id 7EAE0112A6E; Mon, 13 Jun 2016 22:52:39 +0200 (CEST) X-Greylist: Passed host: 5.61.157.201 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-14.arcor-online.net 3rT4jL6vK9z6XYS DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1465851159; bh=wJL+xPwGQ2XWDr0AeZZTBWGsFgc/zepyb3yyS1zM33s=; h=Subject:To:References:From:Cc:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=BSJhvhroqXuaK185QGX+JeU+hPXpW/LgQkJdc9rd6URkVczFa9RPZDEHO6PaddHAu Gp5sB6+qHK/SNcEz076MKnxlwIABXYvBFeZmefuSZfoA9ly0rnkVr7rkfgpYHBl4aS uu2NfGmB50O+L9oIFDB1LU8xPUfUJUAt5cc962CA= X-Greylist: Passed host: 5.61.157.201 X-Greylist: Passed host: 5.61.157.201 Received: from [192.168.115.2] (053d9dc9.dynamic.tele-ag.de [5.61.157.201]) (Authenticated sender: bjoernv@arcor.de) by mail-in-14.arcor-online.net (Postfix) with ESMTPSA id 3rT4jL6vK9z6XYS; Mon, 13 Jun 2016 22:52:38 +0200 (CEST) References: <575F0D5A.9080107@arcor.de> <575F1118.3050700@redhat.com> From: Bjoern Voigt Message-ID: <575F1D16.2060701@arcor.de> Date: Mon, 13 Jun 2016 22:52:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: <575F1118.3050700@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eric Blake wrote: > POSIX allows this behavior, in that it says that grep's behavior is > undefined on non-text files (which you have by virtue of your NUL > byte). Since this is documented behavior of GNU grep when -a is not > used, I'm closing this as not a bug. But feel free to add further > comments to this thread. If I start grep with the "-a" option or "--binary=text", the bug does not show up. "grep --binary-files=binary" which is the default shows the bug. I am relatively sure, that the auto guessing code is incorrect or limited, if a null character is found after 32KB. The manual page says about the auto guessing code: -U, --binary Treat the file(s) as binary. By default, under MS-DOS and MS- Windows, grep guesses the file type by looking at the contents of the first 32KB read from the file. If grep decides the file is a text file, it strips the CR characters from the original file contents (to make regular expressions with ^ and $ work correctly). Specifying -U overrules this guesswork, causing all files to be read and passed to the matching mechanism verbatim; if the file is a text file with CR/LF pairs at the end of each line, this will cause some regular expressions to fail. This option has no effect on platforms other than MS-DOS and MS- Windows. I see these problems: 1. The binary mode is implemented inconsistent. It would be acceptable, if grep produces none (no match, exit code >0) or exactly one output line ("Binary file testfile.txt matches", exit code 0). It is not acceptable, that grep writes some matching text lines and later "Binary file testfile.txt matches" and exits with code 0. 2. Linux or more precisely None-MS-DOS and None-MS-Windows users will oversee the auto guessing section in manual page, because of the notes "By default, under MS-DOS and MS-Windows, grep guesses the file type by looking at the contents of the first 32KB read from the file." and "This option has no effect on platforms other than MS-DOS and MS-Windows." 3. The auto-guessing mechanism is not documented somewhere else in the documentation. 4. The auto guessing limitations are somehow documented in the manual page, but not in the BUGS section. 5. The exit code should not be 0, if grep founds an error in input which it can't recover. 6. The error message "Binary file testfile.txt matches" must not be written on standard output, if matching text lines are written before. 7. POSIX defines minimal assurances for grep. Of course GNU grep can or should be better. 8. Other implementations (like the tested FreeBSD version) do not show the bug. Also busybox works correctly. From unknown Mon Aug 18 17:53:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Mon, 13 Jun 2016 22:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23763 X-GNU-PR-Package: grep X-GNU-PR-Keywords: notabug To: Bjoern Voigt , 23763@debbugs.gnu.org Received: via spool by 23763-submit@debbugs.gnu.org id=B23763.146585636115940 (code B ref 23763); Mon, 13 Jun 2016 22:20:02 +0000 Received: (at 23763) by debbugs.gnu.org; 13 Jun 2016 22:19:21 +0000 Received: from localhost ([127.0.0.1]:39392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCaCX-000491-2F for submit@debbugs.gnu.org; Mon, 13 Jun 2016 18:19:21 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34483) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCaCV-00048n-Bf for 23763@debbugs.gnu.org; Mon, 13 Jun 2016 18:19:19 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 77DF7161457; Mon, 13 Jun 2016 15:19:11 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6KyEEucfwHqk; Mon, 13 Jun 2016 15:19:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 908B316145A; Mon, 13 Jun 2016 15:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Z_M7ZFYjZUU3; Mon, 13 Jun 2016 15:19:10 -0700 (PDT) Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 754AC161457; Mon, 13 Jun 2016 15:19:10 -0700 (PDT) References: <575F0D5A.9080107@arcor.de> <575F1118.3050700@redhat.com> <575F1D16.2060701@arcor.de> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <054316f2-4d3e-1458-6643-b821a096ec94@cs.ucla.edu> Date: Mon, 13 Jun 2016 15:19:10 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <575F1D16.2060701@arcor.de> Content-Type: multipart/mixed; boundary="------------230AF5B9BE128E8BD69F5CF7" X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) This is a multi-part message in MIME format. --------------230AF5B9BE128E8BD69F5CF7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 06/13/2016 01:52 PM, Bjoern Voigt wrote: > The manual page says > about the auto guessing code: That's a typo in the man page, and I installed the attached patch to fix it. This should address the first four points you mentioned. As for the remaining points, grep does not consider binary data to be an error. Although there is a judgment call as to whether a matching-lines notification should be sent to stdout or stderr when input contains binary data, grep has been behaving this way for some time (GNU diff even longer) and it would be a hassle to change it at this point. For GNU grep, you should be able to work around the issue by using the -a option. Other grep implementations may or may not work; in my experience, sending NUL bytes to them can sometimes make them dump core or artificially truncate their output. --------------230AF5B9BE128E8BD69F5CF7 Content-Type: application/x-patch; name="0001-doc-remove-obsolete-MS-DOS-mention.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-doc-remove-obsolete-MS-DOS-mention.patch" RnJvbSA4MzJiZmQ4ZDFkZDdjOGUyMzU4YjA4ZDE4Y2EyMTExODJkMGQ0NGU3IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1 PgpEYXRlOiBNb24sIDEzIEp1biAyMDE2IDE1OjE0OjU2IC0wNzAwClN1YmplY3Q6IFtQQVRD SF0gZG9jOiByZW1vdmUgb2Jzb2xldGUgTVMtRE9TIG1lbnRpb24KTUlNRS1WZXJzaW9uOiAx LjAKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PVVURi04CkNvbnRlbnQtVHJh bnNmZXItRW5jb2Rpbmc6IDhiaXQKCiogZG9jL2dyZXAuaW4uMTogUmVtb3ZlIG9ic29sZXRl IGRpc2N1c3Npb24gb2YgTVMtRE9TIGhldXJpc3RpY3MuClByb2JsZW0gcmVwb3J0ZWQgYnkg QmrDtnJuIFZvaWd0IGluOiBodHRwOi8vYnVncy5nbnUub3JnLzIzNzYzCi0tLQogZG9jL2dy ZXAuaW4uMSB8IDUgKysrLS0KIDEgZmlsZSBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDIg ZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZG9jL2dyZXAuaW4uMSBiL2RvYy9ncmVwLmlu LjEKaW5kZXggMWEzYjdkMi4uODUyNWNhNCAxMDA2NDQKLS0tIGEvZG9jL2dyZXAuaW4uMQor KysgYi9kb2MvZ3JlcC5pbi4xCkBAIC01MDIsOCArNTAyLDkgQEAgVGhpcyBjYW4gY2F1c2Ug YSBwZXJmb3JtYW5jZSBwZW5hbHR5LgogVHJlYXQgdGhlIGZpbGUocykgYXMgYmluYXJ5Lgog QnkgZGVmYXVsdCwgdW5kZXIgXHMtMU1TLURPU1xzMCBhbmQgXHMtMU1TXHMwLVdpbmRvd3Ms CiAuQlIgZ3JlcAotZ3Vlc3NlcyB0aGUgZmlsZSB0eXBlIGJ5IGxvb2tpbmcgYXQgdGhlIGNv bnRlbnRzIG9mIHRoZSBmaXJzdCAzMktCCi1yZWFkIGZyb20gdGhlIGZpbGUuCitndWVzc2Vz IHdoZXRoZXIgYSBmaWxlIGlzIHRleHQgb3IgYmluYXJ5IGFzIGRlc2NyaWJlZCBmb3IgdGhl CisuQiBcLVxeXC1iaW5hcnlcLWZpbGVzCitvcHRpb24uCiBJZgogLkJSIGdyZXAKIGRlY2lk ZXMgdGhlIGZpbGUgaXMgYSB0ZXh0IGZpbGUsIGl0IHN0cmlwcyB0aGUgQ1IgY2hhcmFjdGVy cyBmcm9tIHRoZQotLSAKMi41LjUKCg== --------------230AF5B9BE128E8BD69F5CF7-- From unknown Mon Aug 18 17:53:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes Resent-From: Bjoern Voigt Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Tue, 14 Jun 2016 08:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23763 X-GNU-PR-Package: grep X-GNU-PR-Keywords: notabug To: 23763@debbugs.gnu.org Cc: Paul Eggert Received: via spool by 23763-submit@debbugs.gnu.org id=B23763.146589277925163 (code B ref 23763); Tue, 14 Jun 2016 08:27:02 +0000 Received: (at 23763) by debbugs.gnu.org; 14 Jun 2016 08:26:19 +0000 Received: from localhost ([127.0.0.1]:39596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCjfv-0006Xn-D4 for submit@debbugs.gnu.org; Tue, 14 Jun 2016 04:26:19 -0400 Received: from mail-in-09.arcor-online.net ([151.189.21.49]:35338) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCjft-0006XX-Gm for 23763@debbugs.gnu.org; Tue, 14 Jun 2016 04:26:18 -0400 Received: from mail-in-05-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mx.arcor.de (Postfix) with ESMTP id 3rTN5Z65cqzC2YV; Tue, 14 Jun 2016 10:26:10 +0200 (CEST) Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) by mail-in-05-z2.arcor-online.net (Postfix) with ESMTP id B02F76F3481; Tue, 14 Jun 2016 10:26:10 +0200 (CEST) X-Greylist: Passed host: 5.61.157.201 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-10.arcor-online.net 3rTN5Z1tTjzW3Nl DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1465892770; bh=IwVExVNMpBDIqDW+eUpou3nTOKgpxbI84mEqIexrjNQ=; h=Subject:To:References:From:Cc:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YGlHGQKQsr9Xl6/xG8yQ3bo2bToVnmkKpBLvtDmnCMOBx0mCxwXjN0Cg3P2Wr6QY6 4lGd/VLAL0slwbed3QtpS8jOY5Z7ra8mZQUuSzRS/vexNAESi+WbxHNNVAFUyJU3UB 5ZTo7jx0w7ehRIDN89NsSlbss6oQ3jRYxm1OvnC0= X-Greylist: Passed host: 5.61.157.201 X-Greylist: Passed host: 5.61.157.201 Received: from [192.168.115.2] (053d9dc9.dynamic.tele-ag.de [5.61.157.201]) (Authenticated sender: bjoernv@arcor.de) by mail-in-10.arcor-online.net (Postfix) with ESMTPSA id 3rTN5Z1tTjzW3Nl; Tue, 14 Jun 2016 10:26:10 +0200 (CEST) References: <575F0D5A.9080107@arcor.de> <575F1118.3050700@redhat.com> <575F1D16.2060701@arcor.de> <054316f2-4d3e-1458-6643-b821a096ec94@cs.ucla.edu> From: Bjoern Voigt Message-ID: <575FBFA1.4070802@arcor.de> Date: Tue, 14 Jun 2016 10:26:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: <054316f2-4d3e-1458-6643-b821a096ec94@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) What about the inconsistent output? Grep should not print a mixture of text matches and then exits with a binary match and exit code 0: # ./null-bug-testcase.txt [...] A A A Binary file testfile.txt matches Exit code of grep: 0 This is clearly a bug in my eyes. Is a patch welcome, which fixes this inconsistency? Currently I am analyzing grep in debugging sessions. From unknown Mon Aug 18 17:53:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Tue, 14 Jun 2016 16:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23763 X-GNU-PR-Package: grep X-GNU-PR-Keywords: notabug To: Bjoern Voigt , 23763@debbugs.gnu.org Received: via spool by 23763-submit@debbugs.gnu.org id=B23763.146592167110538 (code B ref 23763); Tue, 14 Jun 2016 16:28:01 +0000 Received: (at 23763) by debbugs.gnu.org; 14 Jun 2016 16:27:51 +0000 Received: from localhost ([127.0.0.1]:40792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCrBu-0002ju-UL for submit@debbugs.gnu.org; Tue, 14 Jun 2016 12:27:51 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCrBt-0002jf-G6 for 23763@debbugs.gnu.org; Tue, 14 Jun 2016 12:27:49 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 612671614A5; Tue, 14 Jun 2016 09:27:43 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id F-o3N3JATfD6; Tue, 14 Jun 2016 09:27:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6B4FC1614A4; Tue, 14 Jun 2016 09:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cWrLcndft5DI; Tue, 14 Jun 2016 09:27:41 -0700 (PDT) Received: from [192.168.1.9] (unknown [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 33E54161499; Tue, 14 Jun 2016 09:27:41 -0700 (PDT) References: <575F0D5A.9080107@arcor.de> <575F1118.3050700@redhat.com> <575F1D16.2060701@arcor.de> <054316f2-4d3e-1458-6643-b821a096ec94@cs.ucla.edu> <575FBFA1.4070802@arcor.de> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <5760307D.4000905@cs.ucla.edu> Date: Tue, 14 Jun 2016 09:27:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <575FBFA1.4070802@arcor.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) Bjoern Voigt wrote: > This is clearly a bug in my eyes. The behavior conforms to grep's spec, so it's not a bug in that sense. I don't offhand see a behavior change that wouldn't cause worse problems elsewhere. Unless you were thinking of adding an option? From unknown Mon Aug 18 17:53:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes Resent-From: Bjoern Voigt Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Tue, 14 Jun 2016 20:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23763 X-GNU-PR-Package: grep X-GNU-PR-Keywords: notabug To: 23763@debbugs.gnu.org Cc: Paul Eggert Received: via spool by 23763-submit@debbugs.gnu.org id=B23763.146593503710536 (code B ref 23763); Tue, 14 Jun 2016 20:11:01 +0000 Received: (at 23763) by debbugs.gnu.org; 14 Jun 2016 20:10:37 +0000 Received: from localhost ([127.0.0.1]:40892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCufU-0002js-W3 for submit@debbugs.gnu.org; Tue, 14 Jun 2016 16:10:37 -0400 Received: from mail-in-10.arcor-online.net ([151.189.21.50]:51249) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bCufT-0002jc-64 for 23763@debbugs.gnu.org; Tue, 14 Jun 2016 16:10:36 -0400 Received: from mail-in-11-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mx.arcor.de (Postfix) with ESMTP id 3rTgkF0b7Kz8RrT; Tue, 14 Jun 2016 22:10:29 +0200 (CEST) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-11-z2.arcor-online.net (Postfix) with ESMTP id 0F52F326089; Tue, 14 Jun 2016 22:10:29 +0200 (CEST) X-Greylist: Passed host: 5.61.157.201 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-16.arcor-online.net 3rTgkD4PrVz4nJw DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arcor.de; s=mail-in; t=1465935029; bh=pExDaDmuRM3sTQO9KewC2UvMwnE4dBeRbs5VE/ZrI2k=; h=Subject:To:References:From:Cc:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Am9YbEiuHD2tuDgsG8ZJeimqjC5o+NDygJkGY1PYqveewiufL6OHbGr2K6+FXxv/l Zk3ZL4fR0dWbgxY9C3xXFpryBwvX673sNqREdCOHOzj2DcOjJWv1UAncrKrhrVqXIN Jvlh4TsSObWqxfJJ4WrosFxVeno30SeHnYIacHnw= X-Greylist: Passed host: 5.61.157.201 X-Greylist: Passed host: 5.61.157.201 Received: from [192.168.115.2] (053d9dc9.dynamic.tele-ag.de [5.61.157.201]) (Authenticated sender: bjoernv@arcor.de) by mail-in-16.arcor-online.net (Postfix) with ESMTPSA id 3rTgkD4PrVz4nJw; Tue, 14 Jun 2016 22:10:28 +0200 (CEST) References: <575F0D5A.9080107@arcor.de> <575F1118.3050700@redhat.com> <575F1D16.2060701@arcor.de> <054316f2-4d3e-1458-6643-b821a096ec94@cs.ucla.edu> <575FBFA1.4070802@arcor.de> <5760307D.4000905@cs.ucla.edu> From: Bjoern Voigt Message-ID: <576064B3.1080508@arcor.de> Date: Tue, 14 Jun 2016 22:10:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: <5760307D.4000905@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Paul Eggert wrote: > Bjoern Voigt wrote: >> This is clearly a bug in my eyes. > > The behavior conforms to grep's spec, so it's not a bug in that sense. > I don't offhand see a behavior change that wouldn't cause worse > problems elsewhere. Unless you were thinking of adding an option? The current manual page patched with "0001-doc-remove-obsolete-MS-DOS-mention-2.patch" says: --binary-files=TYPE If the first few bytes of a file indicate that the file contains binary data, assume that the file is of type TYPE. By default, TYPE is binary, and grep normally outputs either a one-line message saying that a binary file matches, or no message if there is no match. If TYPE is without-match, grep assumes that a binary file does not match; this is equivalent to the -I option. If TYPE is text, grep processes a binary file as if it were text; this is equivalent to the -a option. When processing binary data, grep may treat non-text bytes as line terminators; for example, the pattern '.' (period) might not match a null byte, as the null byte might be treated as a line terminator. Warning: grep --binary-files=text might output binary garbage, which can have nasty side effects if the output is a terminal and if the terminal driver interprets some of it as commands. My test case where a files starts with more than 32KB text data and continues with text data with at least one embedded 0 character (which makes this binary data) is undocumented. Consequently I probably search a new option "--binary-files=auto" which also should by the default sometime later. For files it should work as follows: --binary-files=auto If the first few bytes of a file indicate that the file contains binary data, assume that the file is of type binary. Otherwise assume that the file is of type text. Since the behavior of --binary-files=binary for my testcase is undocumented and since the output is more or less useless except of the fact that some not-printable characters on terminal are suppressed, it would be also an option to change --binary-files=binary mode in code and in the manual page. For files as input data this is easy to implement. But I haven't checked, how --binary-files should work with standard input. The decision binary or text should be made there before the first match is printed. My MySQL mysqldump problem can be solved with --text or --binary-files=text. So I do not search a quick solution anymore. Regards, Björn From unknown Mon Aug 18 17:53:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Wed, 15 Jun 2016 05:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23763 X-GNU-PR-Package: grep X-GNU-PR-Keywords: notabug To: Bjoern Voigt , 23763@debbugs.gnu.org Received: via spool by 23763-submit@debbugs.gnu.org id=B23763.146596862528398 (code B ref 23763); Wed, 15 Jun 2016 05:31:02 +0000 Received: (at 23763) by debbugs.gnu.org; 15 Jun 2016 05:30:25 +0000 Received: from localhost ([127.0.0.1]:41073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bD3PF-0007Ny-2Y for submit@debbugs.gnu.org; Wed, 15 Jun 2016 01:30:25 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bD3PC-0007K3-UU for 23763@debbugs.gnu.org; Wed, 15 Jun 2016 01:30:23 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 816BA1614B5; Tue, 14 Jun 2016 22:30:15 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6V9kywQ1NE_O; Tue, 14 Jun 2016 22:30:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 30CE51614C7; Tue, 14 Jun 2016 22:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2e9Eegd9RFUh; Tue, 14 Jun 2016 22:30:14 -0700 (PDT) Received: from [192.168.1.9] (unknown [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 107681614B5; Tue, 14 Jun 2016 22:30:14 -0700 (PDT) References: <575F0D5A.9080107@arcor.de> <575F1118.3050700@redhat.com> <575F1D16.2060701@arcor.de> <054316f2-4d3e-1458-6643-b821a096ec94@cs.ucla.edu> <575FBFA1.4070802@arcor.de> <5760307D.4000905@cs.ucla.edu> <576064B3.1080508@arcor.de> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <5760E7E5.7030101@cs.ucla.edu> Date: Tue, 14 Jun 2016 22:30:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <576064B3.1080508@arcor.de> Content-Type: multipart/mixed; boundary="------------060708010804010002080304" X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) This is a multi-part message in MIME format. --------------060708010804010002080304 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Bjoern Voigt wrote: > --binary-files=TYPE > If the first few bytes of a file indicate that the file > contains binary data, assume that the file is of type TYPE. That's another place where the man page is obsolete and wrong. (In GNU projects, man pages are often poorly maintained as they are not the primary form of documentation; one is supposed to read the manual instead.) I installed the attached patch to fix that. > My MySQL mysqldump problem can be solved with --text or > --binary-files=text. So I do not search a quick solution anymore. Works for me. --------------060708010804010002080304 Content-Type: text/plain; charset=UTF-8; name="0001-doc-propagate-more-changes-from-grep.texi.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-doc-propagate-more-changes-from-grep.texi.txt" RnJvbSAwZTg4MjVlYWJjZWQxZjA1YmU5OGI4YzY3MGM0MTlmOGMzOTE2MWY0IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1 PgpEYXRlOiBUdWUsIDE0IEp1biAyMDE2IDIyOjI1OjM1IC0wNzAwClN1YmplY3Q6IFtQQVRD SF0gZG9jOiBwcm9wYWdhdGUgbW9yZSBjaGFuZ2VzIGZyb20gZ3JlcC50ZXhpCk1JTUUtVmVy c2lvbjogMS4wCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOApDb250 ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA4Yml0CgpQcm9ibGVtIHJlcG9ydGVkIGJ5IEJqw7Zy biBWb2lndCBpbjogaHR0cDovL2J1Z3MuZ251Lm9yZy8yMzc2MyMyNwoqIGRvYy9ncmVwLmlu LjE6IEZpeCBtb3JlIGluY29uc2lzdGVuY2llcyB3aXRoIGdyZXAudGV4aS4KLS0tCiBkb2Mv Z3JlcC5pbi4xIHwgMTIwICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKy0tLS0tLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCA5MyBpbnNlcnRpb25zKCsp LCAyNyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kb2MvZ3JlcC5pbi4xIGIvZG9jL2dy ZXAuaW4uMQppbmRleCA4NTI1Y2E0Li4wNWYzMzgyIDEwMDY0NAotLS0gYS9kb2MvZ3JlcC5p bi4xCisrKyBiL2RvYy9ncmVwLmluLjEKQEAgLTE0MCw2ICsxNDAsOSBAQCBjaGFyYWN0ZXIu CiBTaW1pbGFybHksIGl0IG11c3QgYmUgZWl0aGVyIGF0IHRoZSBlbmQgb2YgdGhlIGxpbmUK IG9yIGZvbGxvd2VkIGJ5IGEgbm9uLXdvcmQgY29uc3RpdHVlbnQgY2hhcmFjdGVyLgogV29y ZC1jb25zdGl0dWVudCBjaGFyYWN0ZXJzIGFyZSBsZXR0ZXJzLCBkaWdpdHMsIGFuZCB0aGUg dW5kZXJzY29yZS4KK1RoaXMgb3B0aW9uIGhhcyBubyBlZmZlY3QgaWYKKy5CIFwteAoraXMg YWxzbyBzcGVjaWZpZWQuCiAuVFAKIC5CUiBcLXggIiwgIiBcLVxeXC1saW5lXC1yZWdleHAK IFNlbGVjdCBvbmx5IHRob3NlIG1hdGNoZXMgdGhhdCBleGFjdGx5IG1hdGNoIHRoZSB3aG9s ZSBsaW5lLgpAQCAtMzY1LDI2ICszNjgsMzYgQEAgUHJvY2VzcyBhIGJpbmFyeSBmaWxlIGFz IGlmIGl0IHdlcmUgdGV4dDsgdGhpcyBpcyBlcXVpdmFsZW50IHRvIHRoZQogb3B0aW9uLgog LlRQCiAuQkkgXC1cXlwtYmluYXJ5XC1maWxlcz0gVFlQRQotSWYgdGhlIGZpcnN0IGZldyBi eXRlcyBvZiBhIGZpbGUgaW5kaWNhdGUgdGhhdCB0aGUgZmlsZSBjb250YWlucyBiaW5hcnkK LWRhdGEsIGFzc3VtZSB0aGF0IHRoZSBmaWxlIGlzIG9mIHR5cGUKK0lmIGEgZmlsZSdzIGRh dGEgb3IgbWV0YWRhdGEKK2luZGljYXRlIHRoYXQgdGhlIGZpbGUgY29udGFpbnMgYmluYXJ5 IGRhdGEsCithc3N1bWUgdGhhdCB0aGUgZmlsZSBpcyBvZiB0eXBlCiAuSVIgVFlQRSAuCitO b24tdGV4dCBieXRlcyBpbmRpY2F0ZSBiaW5hcnkgZGF0YTsgdGhlc2UgYXJlIGVpdGhlciBv dXRwdXQgYnl0ZXMgdGhhdCBhcmUKK2ltcHJvcGVybHkgZW5jb2RlZCBmb3IgdGhlIGN1cnJl bnQgbG9jYWxlLCBvciBudWxsIGlucHV0IGJ5dGVzIHdoZW4gdGhlCisuQiBcLXoKK29wdGlv biBpcyBub3QgZ2l2ZW4uCisuSVAKIEJ5IGRlZmF1bHQsCiAuSSBUWVBFCiBpcwogLkJSIGJp bmFyeSAsCi1hbmQKK2FuZCB3aGVuCiAuQiBncmVwCi1ub3JtYWxseSBvdXRwdXRzIGVpdGhl cgotYSBvbmUtbGluZSBtZXNzYWdlIHNheWluZyB0aGF0IGEgYmluYXJ5IGZpbGUgbWF0Y2hl cywgb3Igbm8gbWVzc2FnZSBpZgotdGhlcmUgaXMgbm8gbWF0Y2guCitkaXNjb3ZlcnMgdGhh dCBhIGZpbGUgaXMgYmluYXJ5IGl0IHN1cHByZXNzZXMgYW55IGZ1cnRoZXIgb3V0cHV0LCBh bmQKK2luc3RlYWQgb3V0cHV0cyBlaXRoZXIgYSBvbmUtbGluZSBtZXNzYWdlIHNheWluZyB0 aGF0IGEgYmluYXJ5IGZpbGUKK21hdGNoZXMsIG9yIG5vIG1lc3NhZ2UgaWYgdGhlcmUgaXMg bm8gbWF0Y2guCisuSVAKIElmCiAuSSBUWVBFCiBpcwogLkJSIHdpdGhvdXQtbWF0Y2ggLAor d2hlbgogLkIgZ3JlcAotYXNzdW1lcyB0aGF0IGEgYmluYXJ5IGZpbGUgZG9lcyBub3QgbWF0 Y2g7IHRoaXMgaXMgZXF1aXZhbGVudCB0byB0aGUKK2Rpc2NvdmVycyB0aGF0IGEgZmlsZSBp cyBiaW5hcnkgaXQgYXNzdW1lcyB0aGF0IHRoZSByZXN0IG9mIHRoZSBmaWxlCitkb2VzIG5v dCBtYXRjaDsgdGhpcyBpcyBlcXVpdmFsZW50IHRvIHRoZQogLkIgXC1JCiBvcHRpb24uCisu SVAKIElmCiAuSSBUWVBFCiBpcwpAQCAtMzkzLDE3ICs0MDYsNTMgQEAgaXMKIHByb2Nlc3Nl cyBhIGJpbmFyeSBmaWxlIGFzIGlmIGl0IHdlcmUgdGV4dDsgdGhpcyBpcyBlcXVpdmFsZW50 IHRvIHRoZQogLkIgXC1hCiBvcHRpb24uCi1XaGVuIHByb2Nlc3NpbmcgYmluYXJ5IGRhdGEs CisuSVAKK1doZW4KKy5JIHR5cGUKK2lzCisuQlIgYmluYXJ5ICwKIC5CIGdyZXAKLW1heSB0 cmVhdCBub24tdGV4dCBieXRlcyBhcyBsaW5lIHRlcm1pbmF0b3JzOyBmb3IgZXhhbXBsZSwg dGhlIHBhdHRlcm4KLS5SQiAnIC4gJ1wmCi0ocGVyaW9kKSBtaWdodCBub3QgbWF0Y2ggYSBu dWxsIGJ5dGUsIGFzIHRoZSBudWxsIGJ5dGUgbWlnaHQgYmUKLXRyZWF0ZWQgYXMgYSBsaW5l IHRlcm1pbmF0b3IuCittYXkgdHJlYXQgbm9uLXRleHQgYnl0ZXMgYXMgbGluZSB0ZXJtaW5h dG9ycyBldmVuIHdpdGhvdXQgdGhlCisuQiBcLXoKK29wdGlvbi4gIFRoaXMgbWVhbnMgY2hv b3NpbmcKKy5CIGJpbmFyeQordmVyc3VzCisuQiB0ZXh0CitjYW4gYWZmZWN0IHdoZXRoZXIg YSBwYXR0ZXJuIG1hdGNoZXMgYSBmaWxlLiAgRm9yCitleGFtcGxlLCB3aGVuCisuSSB0eXBl CitpcworLkIgYmluYXJ5Cit0aGUgcGF0dGVybgorLkIgcSQgbWlnaHQKK21hdGNoCisuQiBx CitpbW1lZGlhdGVseSBmb2xsb3dlZCBieSBhIG51bGwgYnl0ZSwgZXZlbiB0aG91Z2ggdGhp cworaXMgbm90IG1hdGNoZWQgd2hlbgorLkkgdHlwZQoraXMKKy5CUiB0ZXh0IC4KK0NvbnZl cnNlbHksIHdoZW4KKy5JIHR5cGUKK2lzCisuQiBiaW5hcnkKK3RoZSBwYXR0ZXJuCisuQiAu XCYKKyhwZXJpb2QpIG1pZ2h0IG5vdCBtYXRjaCBhIG51bGwgYnl0ZS4KKy5JUAogLkkgV2Fy bmluZzoKLS5CICJncmVwIFwtXF5cLWJpbmFyeVwtZmlsZXM9dGV4dCIKLW1pZ2h0IG91dHB1 dCBiaW5hcnkgZ2FyYmFnZSwKK1RoZQorLkIgXC1hCitvcHRpb24gbWlnaHQgb3V0cHV0IGJp bmFyeSBnYXJiYWdlLAogd2hpY2ggY2FuIGhhdmUgbmFzdHkgc2lkZSBlZmZlY3RzIGlmIHRo ZSBvdXRwdXQgaXMgYSB0ZXJtaW5hbCBhbmQgaWYgdGhlCiB0ZXJtaW5hbCBkcml2ZXIgaW50 ZXJwcmV0cyBzb21lIG9mIGl0IGFzIGNvbW1hbmRzLgorT24gdGhlIG90aGVyIGhhbmQsIHdo ZW4gcmVhZGluZyBmaWxlcyB3aG9zZSB0ZXh0IGVuY29kaW5ncyBhcmUKK3Vua25vd24sIGl0 IGNhbiBiZSBoZWxwZnVsIHRvIHVzZQorLkIgXC1hCitvciB0byBzZXQKKy5CIExDX0FMTD0n QycKK2luIHRoZSBlbnZpcm9ubWVudCwgaW4gb3JkZXIgdG8gZmluZCBtb3JlIG1hdGNoZXMg ZXZlbiBpZiB0aGUgbWF0Y2hlcworYXJlIHVuc2FmZSBmb3IgZGlyZWN0IGRpc3BsYXkuCiAu VFAKIC5CSSBcLUQgIiBBQ1RJT04iICJcZlIsXGZQIFwtXF5cLWRldmljZXM9IiBBQ1RJT04K IElmIGFuIGlucHV0IGZpbGUgaXMgYSBkZXZpY2UsIEZJRk8gb3Igc29ja2V0LCB1c2UKQEAg LTQ0NSwxMCArNDk0LDE3IEBAIFRoaXMgaXMgZXF1aXZhbGVudCB0byB0aGUKIG9wdGlvbi4K IC5UUAogLkJJIFwtXF5cLWV4Y2x1ZGU9IEdMT0IKLVNraXAgZmlsZXMgd2hvc2UgYmFzZSBu YW1lIG1hdGNoZXMKLS5JIEdMT0IKLSh1c2luZyB3aWxkY2FyZCBtYXRjaGluZykuCi1BIGZp bGUtbmFtZSBnbG9iIGNhbiB1c2UKK1NraXAgYW55IGNvbW1hbmQtbGluZSBmaWxlIHdpdGgg YSBuYW1lIHN1ZmZpeCB0aGF0IG1hdGNoZXMgdGhlIHBhdHRlcm4KKy5JUiBHTE9CICwKK3Vz aW5nIHdpbGRjYXJkIG1hdGNoaW5nOyBhIG5hbWUgc3VmZml4IGlzIGVpdGhlciB0aGUgd2hv bGUKK25hbWUsIG9yIGFueSBzdWZmaXggc3RhcnRpbmcgYWZ0ZXIgYQorLkIgLworYW5kIGJl Zm9yZSBhICtub24tXGZCL1xmUC4KK1doZW4gc2VhcmNoaW5nIHJlY3Vyc2l2ZWx5LCBza2lw IGFueSBzdWJmaWxlIHdob3NlIGJhc2UgbmFtZSBtYXRjaGVzCisuSVIgR0xPQiA7Cit0aGUg YmFzZSBuYW1lIGlzIHRoZSBwYXJ0IGFmdGVyIHRoZSBsYXN0CisuQlIgLyAuCitBIHBhdHRl cm4gY2FuIHVzZQogLkJSICogLAogLkJSID8gLAogYW5kCkBAIC00NjMsMTAgKzUxOSwxNSBA QCBTa2lwIGZpbGVzIHdob3NlIGJhc2UgbmFtZSBtYXRjaGVzIGFueSBvZiB0aGUgZmlsZS1u YW1lIGdsb2JzIHJlYWQgZnJvbQogKHVzaW5nIHdpbGRjYXJkIG1hdGNoaW5nIGFzIGRlc2Ny aWJlZCB1bmRlcgogLkJSIFwtXF5cLWV4Y2x1ZGUgKS4KIC5UUAotLkJJIFwtXF5cLWV4Y2x1 ZGUtZGlyPSBESVIKLUV4Y2x1ZGUgZGlyZWN0b3JpZXMgbWF0Y2hpbmcgdGhlIHBhdHRlcm4K LS5JIERJUgotZnJvbSByZWN1cnNpdmUgc2VhcmNoZXMuCisuQkkgXC1cXlwtZXhjbHVkZS1k aXI9IEdMT0IKK1NraXAgYW55IGNvbW1hbmQtbGluZSBkaXJlY3Rvcnkgd2l0aCBhIG5hbWUg c3VmZml4IHRoYXQgbWF0Y2hlcyB0aGUKK3BhdHRlcm4KKy5JUiBHTE9CIC4KK1doZW4gc2Vh cmNoaW5nIHJlY3Vyc2l2ZWx5LCBza2lwIGFueSBzdWJkaXJlY3RvcnkKK3dob3NlIGJhc2Ug bmFtZSBtYXRjaGVzCisuSVIgR0xPQiAuCitJZ25vcmUgYW55IHJlZHVuZGFudCB0cmFpbGlu ZyBzbGFzaGVzIGluCisuSVIgR0xPQiAuCiAuVFAKIC5CUiBcLUkKIFByb2Nlc3MgYSBiaW5h cnkgZmlsZSBhcyBpZiBpdCBkaWQgbm90IGNvbnRhaW4gbWF0Y2hpbmcgZGF0YTsgdGhpcyBp cwpAQCAtNTIzLDEyICs1ODQsMTAgQEAgVGhpcyBvcHRpb24gaGFzIG5vIGVmZmVjdCBvbiBw bGF0Zm9ybXMKIG90aGVyIHRoYW4gXHMtMU1TLURPU1xzMCBhbmQgXHMtMU1TXHMwLVdpbmRv d3MuCiAuVFAKIC5CUiBcLXogIiwgIiBcLVxeXC1udWxsXC1kYXRhCi1UcmVhdCB0aGUgaW5w dXQgYXMgYSBzZXQgb2YgbGluZXMsCi1lYWNoIHRlcm1pbmF0ZWQgYnkgYSB6ZXJvIGJ5dGUg KHRoZSBccy0xQVNDSUlcczAKLS5CIE5VTAotY2hhcmFjdGVyKSBpbnN0ZWFkIG9mIGEgbmV3 bGluZS4KK1RyZWF0IGlucHV0IGFuZCBvdXRwdXQgZGF0YSBhcyBzZXF1ZW5jZXMgb2YgbGlu ZXMsIGVhY2ggdGVybWluYXRlZCBieQorYSB6ZXJvIGJ5dGUgKHRoZSBBU0NJSSBOVUwgY2hh cmFjdGVyKSBpbnN0ZWFkIG9mIGEgbmV3bGluZS4KIExpa2UgdGhlCi0uQiAtWgorLkIgXC1a CiBvcgogLkIgXC1cXlwtbnVsbAogb3B0aW9uLCB0aGlzIG9wdGlvbiBjYW4gYmUgdXNlZCB3 aXRoIGNvbW1hbmRzIGxpa2UKQEAgLTc3Miw2ICs4MzEsOSBAQCBUaGUgQyBsb2NhbGUgaXMg dXNlZCBpZiBub25lIG9mIHRoZXNlIGVudmlyb25tZW50IHZhcmlhYmxlcyBhcmUgc2V0LAog aWYgdGhlIGxvY2FsZSBjYXRhbG9nIGlzIG5vdCBpbnN0YWxsZWQsIG9yIGlmCiAuQiBncmVw CiB3YXMgbm90IGNvbXBpbGVkIHdpdGggbmF0aW9uYWwgbGFuZ3VhZ2Ugc3VwcG9ydCAoXHMt MU5MU1xzMCkuCitUaGUgc2hlbGwgY29tbWFuZAorLkIgImxvY2FsZSBcLWEiCitsaXN0cyBs b2NhbGVzIHRoYXQgYXJlIGN1cnJlbnRseSBhdmFpbGFibGUuCiAuVFAKIC5CIEdSRVBfT1BU SU9OUwogVGhpcyB2YXJpYWJsZSBzcGVjaWZpZXMgZGVmYXVsdCBvcHRpb25zCkBAIC0xMDE5 LDYgKzEwODEsMTAgQEAgVGhlc2UgdmFyaWFibGVzIHNwZWNpZnkgdGhlIGxvY2FsZSBmb3Ig dGhlCiBjYXRlZ29yeSwKIHdoaWNoIGRldGVybWluZXMgdGhlIHR5cGUgb2YgY2hhcmFjdGVy cywKIGUuZy4sIHdoaWNoIGNoYXJhY3RlcnMgYXJlIHdoaXRlc3BhY2UuCitUaGlzIGNhdGVn b3J5IGFsc28gZGV0ZXJtaW5lcyB0aGUgY2hhcmFjdGVyIGVuY29kaW5nLCB0aGF0IGlzLCB3 aGV0aGVyCit0ZXh0IGlzIGVuY29kZWQgaW4gVVRGLTgsIEFTQ0lJLCBvciBzb21lIG90aGVy IGVuY29kaW5nLiAgSW4gdGhlIEMgb3IKK1BPU0lYIGxvY2FsZSwgYWxsIGNoYXJhY3RlcnMg YXJlIGVuY29kZWQgYXMgYSBzaW5nbGUgYnl0ZSBhbmQgZXZlcnkKK2J5dGUgaXMgYSB2YWxp ZCBjaGFyYWN0ZXIuCiAuVFAKIFxmQkxDX0FMTFxmUCwgXGZCTENfTUVTU0FHRVNcZlAsIFxm QkxBTkdcZlAKIFRoZXNlIHZhcmlhYmxlcyBzcGVjaWZ5IHRoZSBsb2NhbGUgZm9yIHRoZQot LSAKMi43LjQKCg== --------------060708010804010002080304-- From unknown Mon Aug 18 17:53:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes Resent-From: sur-behoffski Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Wed, 15 Jun 2016 10:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23763 X-GNU-PR-Package: grep X-GNU-PR-Keywords: notabug To: 23763@debbugs.gnu.org Received: via spool by 23763-submit@debbugs.gnu.org id=B23763.146598772826199 (code B ref 23763); Wed, 15 Jun 2016 10:49:02 +0000 Received: (at 23763) by debbugs.gnu.org; 15 Jun 2016 10:48:48 +0000 Received: from localhost ([127.0.0.1]:41193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bD8NM-0006oV-3w for submit@debbugs.gnu.org; Wed, 15 Jun 2016 06:48:48 -0400 Received: from ipmail05.adl6.internode.on.net ([150.101.137.143]:5429) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bD8NJ-0006oL-MU for 23763@debbugs.gnu.org; Wed, 15 Jun 2016 06:48:46 -0400 Received: from ppp14-2-59-161.lns21.adl2.internode.on.net (HELO [192.168.178.182]) ([14.2.59.161]) by ipmail05.adl6.internode.on.net with ESMTP; 15 Jun 2016 20:18:42 +0930 References: <575F0D5A.9080107@arcor.de> <575F1118.3050700@redhat.com> <575F1D16.2060701@arcor.de> <054316f2-4d3e-1458-6643-b821a096ec94@cs.ucla.edu> <575FBFA1.4070802@arcor.de> <5760307D.4000905@cs.ucla.edu> <576064B3.1080508@arcor.de> <5760E7E5.7030101@cs.ucla.edu> From: sur-behoffski Message-ID: <57613289.5020908@grouse.com.au> Date: Wed, 15 Jun 2016 20:18:41 +0930 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5760E7E5.7030101@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 06/15/16 15:00, Paul Eggert wrote: > Bjoern Voigt wrote: >> --binary-files=TYPE >> If the first few bytes of a file indicate that the file >> contains binary data, assume that the file is of type TYPE. > > That's another place where the man page is obsolete and wrong. (In GNU projects, man pages are often poorly maintained as they are not the primary form of documentation; one is supposed to read the manual instead.) I installed the attached patch to fix that. > >> My MySQL mysqldump problem can be solved with --text or >> --binary-files=text. So I do not search a quick solution anymore. > > Works for me. > G'day, Fairly pedantic comment: I try to keep reserve the term "null" to use in a pointer context (as NULL), and to use ASCII NUL for the zero character ('\0'). [Just checked, EBCDIC also uses NUL as its name for character value 0.] My experience (admittedly somewhat dated, and/or for smaller architectures) is that preserving the distinction is valuable. Are there documentation standards, especially GNU ones, that cover this distinction? If not, is it worth striving to gradually introduce this in a systematic manner, e.g. "NUL (the zero character)"? cheers, sur-behoffski (Brenton Hoff) Programmer, Grouse Software From unknown Mon Aug 18 17:53:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Wed, 15 Jun 2016 18:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23763 X-GNU-PR-Package: grep X-GNU-PR-Keywords: notabug To: sur-behoffski , 23763@debbugs.gnu.org Received: via spool by 23763-submit@debbugs.gnu.org id=B23763.146601540023902 (code B ref 23763); Wed, 15 Jun 2016 18:30:02 +0000 Received: (at 23763) by debbugs.gnu.org; 15 Jun 2016 18:30:00 +0000 Received: from localhost ([127.0.0.1]:42582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bDFZf-0006DS-Tt for submit@debbugs.gnu.org; Wed, 15 Jun 2016 14:30:00 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49601) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bDFZe-0006DG-MI for 23763@debbugs.gnu.org; Wed, 15 Jun 2016 14:29:59 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BE3271614D4; Wed, 15 Jun 2016 11:29:52 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id LWUIxZRWa7MQ; Wed, 15 Jun 2016 11:29:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 218F51614C6; Wed, 15 Jun 2016 11:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iznH5d9YuHyE; Wed, 15 Jun 2016 11:29:52 -0700 (PDT) Received: from [192.168.1.9] (unknown [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 0365E161381; Wed, 15 Jun 2016 11:29:52 -0700 (PDT) References: <575F0D5A.9080107@arcor.de> <575F1118.3050700@redhat.com> <575F1D16.2060701@arcor.de> <054316f2-4d3e-1458-6643-b821a096ec94@cs.ucla.edu> <575FBFA1.4070802@arcor.de> <5760307D.4000905@cs.ucla.edu> <576064B3.1080508@arcor.de> <5760E7E5.7030101@cs.ucla.edu> <57613289.5020908@grouse.com.au> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <57619E9F.9000306@cs.ucla.edu> Date: Wed, 15 Jun 2016 11:29:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <57613289.5020908@grouse.com.au> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.4 (-) sur-behoffski wrote: > Are there documentation standards, especially GNU ones, that cover this > distinction? If not, is it worth striving to gradually introduce this > in a systematic manner, e.g. "NUL (the zero character)"? I don't know of any terminology standards in this area. (Wikipedia does not count. :-) From unknown Mon Aug 18 17:53:42 2025 X-Loop: help-debbugs@gnu.org Subject: bug#23763: Bug report: Grep stops, if a text file contains a null character after 32768 bytes Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Wed, 15 Jun 2016 18:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23763 X-GNU-PR-Package: grep X-GNU-PR-Keywords: notabug To: Paul Eggert , sur-behoffski , 23763@debbugs.gnu.org Received: via spool by 23763-submit@debbugs.gnu.org id=B23763.146601586424665 (code B ref 23763); Wed, 15 Jun 2016 18:38:02 +0000 Received: (at 23763) by debbugs.gnu.org; 15 Jun 2016 18:37:44 +0000 Received: from localhost ([127.0.0.1]:42586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bDFh9-0006Pk-MX for submit@debbugs.gnu.org; Wed, 15 Jun 2016 14:37:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bDFh7-0006PX-VR for 23763@debbugs.gnu.org; Wed, 15 Jun 2016 14:37:42 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1C4FE6F692; Wed, 15 Jun 2016 18:37:36 +0000 (UTC) Received: from [10.3.116.106] (ovpn-116-106.phx2.redhat.com [10.3.116.106]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5FIbZqG002883; Wed, 15 Jun 2016 14:37:35 -0400 References: <575F0D5A.9080107@arcor.de> <575F1118.3050700@redhat.com> <575F1D16.2060701@arcor.de> <054316f2-4d3e-1458-6643-b821a096ec94@cs.ucla.edu> <575FBFA1.4070802@arcor.de> <5760307D.4000905@cs.ucla.edu> <576064B3.1080508@arcor.de> <5760E7E5.7030101@cs.ucla.edu> <57613289.5020908@grouse.com.au> <57619E9F.9000306@cs.ucla.edu> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg X-Enigmail-Draft-Status: N1110 Organization: Red Hat, Inc. Message-ID: <5761A06E.7070308@redhat.com> Date: Wed, 15 Jun 2016 12:37:34 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <57619E9F.9000306@cs.ucla.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u1kr8ok8FT1gJ3Lax9W80ogWunVCRX8UU" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 15 Jun 2016 18:37:36 +0000 (UTC) X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --u1kr8ok8FT1gJ3Lax9W80ogWunVCRX8UU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/15/2016 12:29 PM, Paul Eggert wrote: > sur-behoffski wrote: >> Are there documentation standards, especially GNU ones, that cover thi= s >> distinction? If not, is it worth striving to gradually introduce this= >> in a systematic manner, e.g. "NUL (the zero character)"? >=20 > I don't know of any terminology standards in this area. (Wikipedia does= > not count. :-) The POSIX standard tries to consistently use NUL for the character name (whether you are using a unibyte encoding and it fits in char, or a wide encoding where it fits in wchar_t), a 'null byte' for a byte that is all zeroes (which happens to be the NUL character in both unibyte and in multibyte encodings, since no other multibyte character is allowed to have an embedded null byte), and a 'null pointer' when referring to a pointer to nowhere (the constant NULL is a null pointer, as is the C expression '((void*)0)', although the null pointer need not have an all-zero bit representation in hardware). http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html in particular 3.243-3.245 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --u1kr8ok8FT1gJ3Lax9W80ogWunVCRX8UU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXYaBuAAoJEKeha0olJ0NqxPIH/Rk6vYLLhUsNfgINpSY8sKYo FOG4IOWN+dEF+XcJchlhAPMBnogkwUz4DncIuA/KbWur3DR3NdqvRy4oBYHp+cza E1O7V1vckX8Q4XDWxTuPtSfUsn5pHTH5CVCeGBB5UC/8ku8ZrQd/IxIkDK3Gc74z b3m4jU1uaW5TaBWhJjJZU2/tShnLMFohB+7wEfK6YWrgnr/ALto2lQtQKydggfiA e4XWMBw/owkcyZfZHbB++sGCGmj6B2FpwW1Opek7j6FDy2aLDt1lj+HRfVXhpXVf e6n3ijpKDHR/2k9431ZaCI8Au539E9OvB2BijzS34wxD2Z5VaIHgV68gNILl8wc= =cHxV -----END PGP SIGNATURE----- --u1kr8ok8FT1gJ3Lax9W80ogWunVCRX8UU--