grep branch, master, updated. v3.11-43-g944c2ec

[Paul Eggert]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "grep".

The branch, master has been updated
       via  944c2eccc7e88299c47ada1d319fbb5705bc713d (commit)
       via  8fb15fb5bff35ff069ce108b2ff987dc7183de37 (commit)
       via  288ea84c7083e7068d4ab70ba8d5a6e8d206cf95 (commit)
       via  c89ce1cd48d949322a110ea793f41484a8dd0be9 (commit)
       via  37ed0f562198a1c8d472d63b9d25fd853b3cfefd (commit)
       via  cb83e12460bc184327dc58c1785ab861bc822b70 (commit)
      from  e7481a09399839c2b3b9b833f3167c1ffd6f8202 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://git.savannah.gnu.org/cgit/grep.git/commit/?id=944c2eccc7e88299c47ada1d319fbb5705bc713d


commit 944c2eccc7e88299c47ada1d319fbb5705bc713d
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Sat Sep 21 22:37:33 2024 -0700

    doc: warn re using ‘grep’ to detect binary files
    
    This is in response to a bug report by Rodrigo Jorge
    <https://bugs.gnu.org/73360>.
    * doc/grep.texi (File and Directory Selection):
    Warn that ‘grep’ shouldn’t be used to determine whether
    a file is binary for other applications’ purposes, as
    their definition of “binary” may well differ.
    Improve documentation for discovery of null input.

diff --git a/doc/grep.texi b/doc/grep.texi
index 7d10f86..9c46e76 100644
--- a/doc/grep.texi
+++ b/doc/grep.texi
@@ -631,9 +631,11 @@ When some output is suppressed, @command{grep} follows any 
output
 with a message to standard error saying that a binary file matches.
 
 If @var{type} is @samp{without-match},
-when @command{grep} discovers null input binary data
-it assumes that the rest of the file does not match;
+when @command{grep} discovers null binary data in an input file
+it assumes that any unprocessed input does not match;
 this is equivalent to the @option{-I} option.
+In this case the region of unprocessed input starts no later than the
+null binary data, and continues to end of file.
 
 If @var{type} is @samp{text},
 @command{grep} processes binary data as if it were text;
@@ -649,6 +651,16 @@ is not matched when @var{type} is @samp{text}.  
Conversely, when
 @var{type} is @samp{binary} the pattern @samp{.} (period) might not
 match a null byte.
 
+The heuristic that @command{grep} uses to intuit whether input is
+binary is specific to @command{grep} and may well be unsuitable for
+other applications, as it depends on command-line options, on locale,
+and on hardware and operating system characteristics such as system
+page size and input buffering.  For example, if the input consists of
+a matching text line followed by nonmatching data that contains a null
+byte, @command{grep} might either output the matching line or treat
+the file as binary, depending on whether the unprocessed input happens
+to include the matching text line.
+
 @emph{Warning:} The @option{-a} (@option{--binary-files=text}) option
 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
@@ -2004,7 +2016,7 @@ Note that on some platforms,
 except the available memory.
 
 @item
-Why does @command{grep} report ``Binary file matches''?
+Why does @command{grep} report ``binary file matches''?
 
 If @command{grep} listed all matching ``lines'' from a binary file, it
 would probably generate output that is not useful, and it might even

http://git.savannah.gnu.org/cgit/grep.git/commit/?id=8fb15fb5bff35ff069ce108b2ff987dc7183de37


commit 944c2eccc7e88299c47ada1d319fbb5705bc713d
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Sat Sep 21 22:37:33 2024 -0700

    doc: warn re using ‘grep’ to detect binary files
    
    This is in response to a bug report by Rodrigo Jorge
    <https://bugs.gnu.org/73360>.
    * doc/grep.texi (File and Directory Selection):
    Warn that ‘grep’ shouldn’t be used to determine whether
    a file is binary for other applications’ purposes, as
    their definition of “binary” may well differ.
    Improve documentation for discovery of null input.

diff --git a/doc/grep.texi b/doc/grep.texi
index 7d10f86..9c46e76 100644
--- a/doc/grep.texi
+++ b/doc/grep.texi
@@ -631,9 +631,11 @@ When some output is suppressed, @command{grep} follows any 
output
 with a message to standard error saying that a binary file matches.
 
 If @var{type} is @samp{without-match},
-when @command{grep} discovers null input binary data
-it assumes that the rest of the file does not match;
+when @command{grep} discovers null binary data in an input file
+it assumes that any unprocessed input does not match;
 this is equivalent to the @option{-I} option.
+In this case the region of unprocessed input starts no later than the
+null binary data, and continues to end of file.
 
 If @var{type} is @samp{text},
 @command{grep} processes binary data as if it were text;
@@ -649,6 +651,16 @@ is not matched when @var{type} is @samp{text}.  
Conversely, when
 @var{type} is @samp{binary} the pattern @samp{.} (period) might not
 match a null byte.
 
+The heuristic that @command{grep} uses to intuit whether input is
+binary is specific to @command{grep} and may well be unsuitable for
+other applications, as it depends on command-line options, on locale,
+and on hardware and operating system characteristics such as system
+page size and input buffering.  For example, if the input consists of
+a matching text line followed by nonmatching data that contains a null
+byte, @command{grep} might either output the matching line or treat
+the file as binary, depending on whether the unprocessed input happens
+to include the matching text line.
+
 @emph{Warning:} The @option{-a} (@option{--binary-files=text}) option
 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
@@ -2004,7 +2016,7 @@ Note that on some platforms,
 except the available memory.
 
 @item
-Why does @command{grep} report ``Binary file matches''?
+Why does @command{grep} report ``binary file matches''?
 
 If @command{grep} listed all matching ``lines'' from a binary file, it
 would probably generate output that is not useful, and it might even

http://git.savannah.gnu.org/cgit/grep.git/commit/?id=288ea84c7083e7068d4ab70ba8d5a6e8d206cf95


commit 944c2eccc7e88299c47ada1d319fbb5705bc713d
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Sat Sep 21 22:37:33 2024 -0700

    doc: warn re using ‘grep’ to detect binary files
    
    This is in response to a bug report by Rodrigo Jorge
    <https://bugs.gnu.org/73360>.
    * doc/grep.texi (File and Directory Selection):
    Warn that ‘grep’ shouldn’t be used to determine whether
    a file is binary for other applications’ purposes, as
    their definition of “binary” may well differ.
    Improve documentation for discovery of null input.

diff --git a/doc/grep.texi b/doc/grep.texi
index 7d10f86..9c46e76 100644
--- a/doc/grep.texi
+++ b/doc/grep.texi
@@ -631,9 +631,11 @@ When some output is suppressed, @command{grep} follows any 
output
 with a message to standard error saying that a binary file matches.
 
 If @var{type} is @samp{without-match},
-when @command{grep} discovers null input binary data
-it assumes that the rest of the file does not match;
+when @command{grep} discovers null binary data in an input file
+it assumes that any unprocessed input does not match;
 this is equivalent to the @option{-I} option.
+In this case the region of unprocessed input starts no later than the
+null binary data, and continues to end of file.
 
 If @var{type} is @samp{text},
 @command{grep} processes binary data as if it were text;
@@ -649,6 +651,16 @@ is not matched when @var{type} is @samp{text}.  
Conversely, when
 @var{type} is @samp{binary} the pattern @samp{.} (period) might not
 match a null byte.
 
+The heuristic that @command{grep} uses to intuit whether input is
+binary is specific to @command{grep} and may well be unsuitable for
+other applications, as it depends on command-line options, on locale,
+and on hardware and operating system characteristics such as system
+page size and input buffering.  For example, if the input consists of
+a matching text line followed by nonmatching data that contains a null
+byte, @command{grep} might either output the matching line or treat
+the file as binary, depending on whether the unprocessed input happens
+to include the matching text line.
+
 @emph{Warning:} The @option{-a} (@option{--binary-files=text}) option
 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
@@ -2004,7 +2016,7 @@ Note that on some platforms,
 except the available memory.
 
 @item
-Why does @command{grep} report ``Binary file matches''?
+Why does @command{grep} report ``binary file matches''?
 
 If @command{grep} listed all matching ``lines'' from a binary file, it
 would probably generate output that is not useful, and it might even

http://git.savannah.gnu.org/cgit/grep.git/commit/?id=c89ce1cd48d949322a110ea793f41484a8dd0be9


commit 944c2eccc7e88299c47ada1d319fbb5705bc713d
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Sat Sep 21 22:37:33 2024 -0700

    doc: warn re using ‘grep’ to detect binary files
    
    This is in response to a bug report by Rodrigo Jorge
    <https://bugs.gnu.org/73360>.
    * doc/grep.texi (File and Directory Selection):
    Warn that ‘grep’ shouldn’t be used to determine whether
    a file is binary for other applications’ purposes, as
    their definition of “binary” may well differ.
    Improve documentation for discovery of null input.

diff --git a/doc/grep.texi b/doc/grep.texi
index 7d10f86..9c46e76 100644
--- a/doc/grep.texi
+++ b/doc/grep.texi
@@ -631,9 +631,11 @@ When some output is suppressed, @command{grep} follows any 
output
 with a message to standard error saying that a binary file matches.
 
 If @var{type} is @samp{without-match},
-when @command{grep} discovers null input binary data
-it assumes that the rest of the file does not match;
+when @command{grep} discovers null binary data in an input file
+it assumes that any unprocessed input does not match;
 this is equivalent to the @option{-I} option.
+In this case the region of unprocessed input starts no later than the
+null binary data, and continues to end of file.
 
 If @var{type} is @samp{text},
 @command{grep} processes binary data as if it were text;
@@ -649,6 +651,16 @@ is not matched when @var{type} is @samp{text}.  
Conversely, when
 @var{type} is @samp{binary} the pattern @samp{.} (period) might not
 match a null byte.
 
+The heuristic that @command{grep} uses to intuit whether input is
+binary is specific to @command{grep} and may well be unsuitable for
+other applications, as it depends on command-line options, on locale,
+and on hardware and operating system characteristics such as system
+page size and input buffering.  For example, if the input consists of
+a matching text line followed by nonmatching data that contains a null
+byte, @command{grep} might either output the matching line or treat
+the file as binary, depending on whether the unprocessed input happens
+to include the matching text line.
+
 @emph{Warning:} The @option{-a} (@option{--binary-files=text}) option
 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
@@ -2004,7 +2016,7 @@ Note that on some platforms,
 except the available memory.
 
 @item
-Why does @command{grep} report ``Binary file matches''?
+Why does @command{grep} report ``binary file matches''?
 
 If @command{grep} listed all matching ``lines'' from a binary file, it
 would probably generate output that is not useful, and it might even

http://git.savannah.gnu.org/cgit/grep.git/commit/?id=37ed0f562198a1c8d472d63b9d25fd853b3cfefd


commit 944c2eccc7e88299c47ada1d319fbb5705bc713d
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Sat Sep 21 22:37:33 2024 -0700

    doc: warn re using ‘grep’ to detect binary files
    
    This is in response to a bug report by Rodrigo Jorge
    <https://bugs.gnu.org/73360>.
    * doc/grep.texi (File and Directory Selection):
    Warn that ‘grep’ shouldn’t be used to determine whether
    a file is binary for other applications’ purposes, as
    their definition of “binary” may well differ.
    Improve documentation for discovery of null input.

diff --git a/doc/grep.texi b/doc/grep.texi
index 7d10f86..9c46e76 100644
--- a/doc/grep.texi
+++ b/doc/grep.texi
@@ -631,9 +631,11 @@ When some output is suppressed, @command{grep} follows any 
output
 with a message to standard error saying that a binary file matches.
 
 If @var{type} is @samp{without-match},
-when @command{grep} discovers null input binary data
-it assumes that the rest of the file does not match;
+when @command{grep} discovers null binary data in an input file
+it assumes that any unprocessed input does not match;
 this is equivalent to the @option{-I} option.
+In this case the region of unprocessed input starts no later than the
+null binary data, and continues to end of file.
 
 If @var{type} is @samp{text},
 @command{grep} processes binary data as if it were text;
@@ -649,6 +651,16 @@ is not matched when @var{type} is @samp{text}.  
Conversely, when
 @var{type} is @samp{binary} the pattern @samp{.} (period) might not
 match a null byte.
 
+The heuristic that @command{grep} uses to intuit whether input is
+binary is specific to @command{grep} and may well be unsuitable for
+other applications, as it depends on command-line options, on locale,
+and on hardware and operating system characteristics such as system
+page size and input buffering.  For example, if the input consists of
+a matching text line followed by nonmatching data that contains a null
+byte, @command{grep} might either output the matching line or treat
+the file as binary, depending on whether the unprocessed input happens
+to include the matching text line.
+
 @emph{Warning:} The @option{-a} (@option{--binary-files=text}) option
 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
@@ -2004,7 +2016,7 @@ Note that on some platforms,
 except the available memory.
 
 @item
-Why does @command{grep} report ``Binary file matches''?
+Why does @command{grep} report ``binary file matches''?
 
 If @command{grep} listed all matching ``lines'' from a binary file, it
 would probably generate output that is not useful, and it might even

http://git.savannah.gnu.org/cgit/grep.git/commit/?id=cb83e12460bc184327dc58c1785ab861bc822b70


commit 944c2eccc7e88299c47ada1d319fbb5705bc713d
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Sat Sep 21 22:37:33 2024 -0700

    doc: warn re using ‘grep’ to detect binary files
    
    This is in response to a bug report by Rodrigo Jorge
    <https://bugs.gnu.org/73360>.
    * doc/grep.texi (File and Directory Selection):
    Warn that ‘grep’ shouldn’t be used to determine whether
    a file is binary for other applications’ purposes, as
    their definition of “binary” may well differ.
    Improve documentation for discovery of null input.

diff --git a/doc/grep.texi b/doc/grep.texi
index 7d10f86..9c46e76 100644
--- a/doc/grep.texi
+++ b/doc/grep.texi
@@ -631,9 +631,11 @@ When some output is suppressed, @command{grep} follows any 
output
 with a message to standard error saying that a binary file matches.
 
 If @var{type} is @samp{without-match},
-when @command{grep} discovers null input binary data
-it assumes that the rest of the file does not match;
+when @command{grep} discovers null binary data in an input file
+it assumes that any unprocessed input does not match;
 this is equivalent to the @option{-I} option.
+In this case the region of unprocessed input starts no later than the
+null binary data, and continues to end of file.
 
 If @var{type} is @samp{text},
 @command{grep} processes binary data as if it were text;
@@ -649,6 +651,16 @@ is not matched when @var{type} is @samp{text}.  
Conversely, when
 @var{type} is @samp{binary} the pattern @samp{.} (period) might not
 match a null byte.
 
+The heuristic that @command{grep} uses to intuit whether input is
+binary is specific to @command{grep} and may well be unsuitable for
+other applications, as it depends on command-line options, on locale,
+and on hardware and operating system characteristics such as system
+page size and input buffering.  For example, if the input consists of
+a matching text line followed by nonmatching data that contains a null
+byte, @command{grep} might either output the matching line or treat
+the file as binary, depending on whether the unprocessed input happens
+to include the matching text line.
+
 @emph{Warning:} The @option{-a} (@option{--binary-files=text}) option
 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
@@ -2004,7 +2016,7 @@ Note that on some platforms,
 except the available memory.
 
 @item
-Why does @command{grep} report ``Binary file matches''?
+Why does @command{grep} report ``binary file matches''?
 
 If @command{grep} listed all matching ``lines'' from a binary file, it
 would probably generate output that is not useful, and it might even

-----------------------------------------------------------------------

Summary of changes:
 configure.ac  | 13 +++++++++----
 doc/grep.texi | 18 +++++++++++++++---
 gnulib        |  2 +-
 src/grep.c    | 54 +++++++++++++++++++++++++-----------------------------
 4 files changed, 50 insertions(+), 37 deletions(-)


hooks/post-receive
-- 
grep