GNU bug report logs - #69929
Can grep -q report matches in incomplete lines?

Previous Next

To reply to this bug, email your comments to 69929 AT debbugs.gnu.org.

the display of automated, internal messages from the tracker.

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

From: Niels Möller <nisse <at> lysator.liu.se>
To: bug-grep <at> gnu.org
Subject: Can grep -q report matches in incomplete lines?
Date: 2024年3月21日 14:57:04 +0100

Hi,
I'm having grep -q read input from a pipe. I would like grep to exit
successfully as soon as a match occurs, without requiring the line to be
terminated by newline or EOF (unless the grep pattern includes '$', that
is).
E.g., if I run 
 (printf foo ; sleep 30) | grep -q foo
I want grep to exit successfully right away. Currently, grep waits until
it gets EOF on the input, 30 seconds later. I'm testing with GNU grep
3.8, running on Debian GNU/Linux.
Another less friendly example:
 (printf foo ; cat /dev/zero | tr '0円' x) | grep -q foo
It would be nice if that exited quickly. And without any excessive
memory usage, with or without match.
My actual usecase is for a test booting a machine in qemu. I pipe qemu's
output (including the console of the guest machine) to grep, and I want
to check that the machine gets to the login prompt. But there's usually
no trailing newline after that prompt.
Regards,
/Niels
-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.

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

From: Niels Möller <nisse <at> lysator.liu.se>
To: bug-grep <at> gnu.org
Subject: Re: Can grep -q report matches in incomplete lines?
Date: 2024年3月21日 16:02:49 +0100

Niels Möller <nisse <at> lysator.liu.se> writes:
> E.g., if I run 
>
> (printf foo ; sleep 30) | grep -q foo
>
> I want grep to exit successfully right away. Currently, grep waits until
> it gets EOF on the input, 30 seconds later.
Sorry if I'm confused about how to script this. The following (bash
syntax) is a better example:
 grep -q foo <(sh -c 'printf foo ; sleep 30' &)
This blocks 30 seconds before exiting. In contrast, 
 grep -q foo <(sh -c echo foo ; sleep 30' &)
(only difference is the newline at the end of the line) does exit
immediately.
Regards,
/Niels
-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Niels Möller <nisse <at> lysator.liu.se>, 69929 <at> debbugs.gnu.org
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月21日 17:51:34 -0700

On 3/21/24 06:57, Niels Möller wrote:
> I'm having grep -q read input from a pipe. I would like grep to exit
> successfully as soon as a match occurs, without requiring the line to be
> terminated by newline or EOF (unless the grep pattern includes '$', that
> is).
Grep used to behave almost that way. It did wait for a newline but it 
did not wait for EOF. But people started complaining about that behavior 
so we changed it.
Perhaps there should be an option to switch between old and new behaviors.
However, not waiting for a newline is problematic; although doable it 
would be a bit of a pain to program and not sure it's worth the effort. 
Grep didn't used to do that.

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

From: jackson <at> fastmail.com
To: "Paul Eggert" <eggert <at> cs.ucla.edu>,
 Niels Möller <nisse <at> lysator.liu.se>, 69929 <at> debbugs.gnu.org
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月21日 21:58:41 -0500

Paul Eggert wrote:
> although doable it would be a bit of a pain to program
yup - sure would be a pain.
If you're not sure whether your actual input of interest will end
in a newline, can you add one, to "feed grep's newline hunger",
thus for instance replacing your example:
 grep -q foo <(sh -c 'printf foo ; sleep 30' &)
with:
 grep -q foo <(sh -c 'printf foo ; echo ; sleep 30' &)
In any case, grep is quite line oriented, as implied by an early
sentence in the man page grep(1):
"PATTERNS is one or more patterns separated by newline characters,"
-- 
 Paul Jackson
 jackson <at> fastmail.fm

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

From: Niels Möller <nisse <at> lysator.liu.se>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 69929 <at> debbugs.gnu.org
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月22日 09:24:24 +0100

Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 3/21/24 06:57, Niels Möller wrote:
>> I'm having grep -q read input from a pipe. I would like grep to exit
>> successfully as soon as a match occurs, without requiring the line to be
>> terminated by newline or EOF (unless the grep pattern includes '$', that
>> is).
>
> Grep used to behave almost that way. It did wait for a newline but it
> did not wait for EOF. But people started complaining about that
> behavior so we changed it.
Some --exit-early option? Sounds reasonable, but not enough for my
usecase. And I understand it might be an undesirable default behavior of
-q: Not so nice if changing "foo | grep" to "foo | grep -q" could make
foo fail with EPIPE/SIGPIPE.
(BTW, man page says about the -q option "Exit immediately with zero
status if any match is found", from reading that, I would not expect
grep to continue to read the rest of the file until EOF).
> However, not waiting for a newline is problematic; although doable it
> would be a bit of a pain to program and not sure it's worth the
> effort. Grep didn't used to do that.
I only have a rather abstract understanding of regexp matching, but for
patterns that aren't extended to require backtracking, in principle it
should be doably to feed the state machine one character at a time, with
no buffering of input?
jackson <at> fastmail.com writes:
> If you're not sure whether your actual input of interest will end
> in a newline, can you add one, to "feed grep's newline hunger",
> thus for instance replacing your example:
>
> grep -q foo <(sh -c 'printf foo ; sleep 30' &)
>
> with:
>
> grep -q foo <(sh -c 'printf foo ; echo ; sleep 30' &)
Not so easy when the input is the log output by a still running process
(in my case qemu).
> In any case, grep is quite line oriented,
Right. Maybe what I'm really looking for is a binary grep. For the time
being, I hacked together a tool that does just what I need for my qemu
test (no regexp matching, just matching a fix string starting at the
beginning of a line). See
https://git.glasklar.is/system-transparency/core/stboot/-/blob/43e91273a57473ee361e332926b88c1b4fe9917a/integration/look-for/look-for.go
I use this in combination with timeout (GNU coreutils) to fail the test
if no match for the login prompt is found within reasonable time.
A more general binary grep could match a regexp against a binary file or
stream, with options to exit on first match (my immediate usecase),
output the count of matches, or output the positions for each match. I
still think some of those features would make sense as part of GNU grep.
Regards,
/Niels
-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.

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

From: jackson <at> fastmail.com
To: Niels Möller <nisse <at> lysator.liu.se>,
 "Paul Eggert" <eggert <at> cs.ucla.edu>
Cc: 69929 <at> debbugs.gnu.org
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月22日 09:37:55 -0500

Neils noted:
>> (BTW, man page says about the -q option "Exit immediately with zero
>> status if any match is found", ...
If I had the master copy of that man page in front of me right now,
I'd change that to say "... if any matching line is found ..."
>> For the time being, I hacked together a tool that does just what I need
Bingo.
Given that our talents and resources are finite, and our various
needs and situations infinite, it's impossible to have general
purpose tools that are ideal for every situation.
We can do the rest, individually.
-- 
Paul Jackson
 jackson <at> fastmail.fm

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

From: Dennis Clarke <dclarke <at> blastwave.org>
To: bug-grep <at> gnu.org
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月22日 15:25:15 -0400

On 3/21/24 22:58, jackson <at> fastmail.com wrote:
> Paul Eggert wrote:
>> although doable it would be a bit of a pain to program
>
> yup - sure would be a pain.
>
> If you're not sure whether your actual input of interest will end
> in a newline, can you add one, to "feed grep's newline hunger",
> thus for instance replacing your example:
>
> grep -q foo <(sh -c 'printf foo ; sleep 30' &)
>
> with:
>
> grep -q foo <(sh -c 'printf foo ; echo ; sleep 30' &)
>
> In any case, grep is quite line oriented, as implied by an early
> sentence in the man page grep(1):
>
> "PATTERNS is one or more patterns separated by newline characters,"
>
 This may not be helpful but I powered up and old old Sun server
running Solaris 8 where I see :
nix$ uname -a
SunOS nix 5.8 Generic_117350-62 sun4m sparc SUNW,SPARCstation-20
nix$ cat /etc/release
 Solaris 8 2/04 s28s_hw4wos_05a SPARC
 Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.
 Assembled 08 January 2004
nix$ which grep
/usr/xpg4/bin/grep
nix$ /usr/bin/printf "This is a line of text without a newline" | wc
 0 9 40
nix$ /usr/bin/printf "This is a line of text without a newline" | 
/usr/xpg4/bin/grep -c 'line'
1
nix$
So that seems to look at a "line" that is not a "line" as we see that wc
claims there are zero lines. The manpage[1] even claims the words :
 "prints all lines that contain that pattern"
So I have to wonder. Old Solaris 8, once fully patched, was definately
compliant with SUSv2 which is all of POSIX.1b-1993, POSIX.1c-1996 as
well as ISO/IEC 9899 (C Standard) Amendment 1.
Anyways, this is just a crusty old grey beard here putting yet another
layer of paint onto the bikeshed ( https://www.bikeshed.com/ ) and I do
apologize for the messy paintwork.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
[1] the man page on ye old old Solaris 8
nix$ man grep
Reformatting page. Please Wait... done
User Commands grep(1)
NAME
 grep - search a file for a pattern
SYNOPSIS
 /usr/bin/grep [ -bchilnsvw ] limited-regular-expression [
 filename ... ]
 /usr/xpg4/bin/grep [ -E | -F ] [ -c | -l | -q ] [
 -bhinsvwx ] -e pattern_list ... [ -f pattern_file ] ...
 [ file ... ]
 /usr/xpg4/bin/grep [ -E | -F ] [ -c | -l | -q ] [
 -bhinsvwx ] [ -e pattern_list ... ] -f pattern_file ... [
 file ... ]
 /usr/xpg4/bin/grep [ -E | -F ] [ -c | -l | -q ] [
 -bhinsvwx ] pattern [ file ... ]
DESCRIPTION
 The grep utility searches text files for a pattern and
 prints all lines that contain that pattern. It uses a com-
 pact non-deterministic algorithm.
 Be careful using the characters ,ドル *, [, ^, |, (, ), and \
 in the pattern_list because they are also meaningful to the
 shell. It is safest to enclose the entire pattern_list in
 single quotes '... '.
 If no files are specified, grep assumes standard input. Nor-
 mally, each line found is copied to standard output. The
 file name is printed before each line found if there is more
 than one input file.
 /usr/bin/grep
 The /usr/bin/grep utility uses limited regular expressions
 like those described on the regexp(5) manual page to match
 the patterns.
 /usr/xpg4/bin/grep
 The options -E and -F affect the way /usr/xpg4/bin/grep
 interprets pattern_list. If -E is specified,
 /usr/xpg4/bin/grep interprets pattern_list as a full regular
 expression (see -E for description). If -F is specified,
 grep interprets pattern_list as a fixed string. If neither
 are specified, grep interprets pattern_list as a basic regu-
 lar expression as described on regex(5) manual page.
.
.
.

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

From: "David G. Pickett" <dgpickett <at> aol.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 
 Niels Möller <nisse <at> lysator.liu.se>
Cc: "69929 <at> debbugs.gnu.org" <69929 <at> debbugs.gnu.org>
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月22日 20:42:12 +0000 (UTC)

[Message part 1 (text/plain, inline)]

 Maybe the opposite: -only_lines_with_newline ? Most users consider a line at EOF lacking a trailing newline as still a line, but perhaps some do not?
 On Friday, March 22, 2024 at 04:25:38 AM EDT, Niels Möller <nisse <at> lysator.liu.se> wrote: 
 
 Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 3/21/24 06:57, Niels Möller wrote:
>> I'm having grep -q read input from a pipe. I would like grep to exit
>> successfully as soon as a match occurs, without requiring the line to be
>> terminated by newline or EOF (unless the grep pattern includes '$', that
>> is).
>
> Grep used to behave almost that way. It did wait for a newline but it
> did not wait for EOF. But people started complaining about that
> behavior so we changed it.
Some --exit-early option? Sounds reasonable, but not enough for my
usecase. And I understand it might be an undesirable default behavior of
-q: Not so nice if changing "foo | grep" to "foo | grep -q" could make
foo fail with EPIPE/SIGPIPE.
(BTW, man page says about the -q option "Exit immediately with zero
status if any match is found", from reading that, I would not expect
grep to continue to read the rest of the file until EOF).
> However, not waiting for a newline is problematic; although doable it
> would be a bit of a pain to program and not sure it's worth the
> effort. Grep didn't used to do that.
I only have a rather abstract understanding of regexp matching, but for
patterns that aren't extended to require backtracking, in principle it
should be doably to feed the state machine one character at a time, with
no buffering of input?
jackson <at> fastmail.com writes:
> If you're not sure whether your actual input of interest will end
> in a newline, can you add one, to "feed grep's newline hunger",
> thus for instance replacing your example:
>
> grep -q foo <(sh -c 'printf foo ; sleep 30' &)
>
> with:
>
> grep -q foo <(sh -c 'printf foo ; echo ; sleep 30' &)
Not so easy when the input is the log output by a still running process
(in my case qemu).
> In any case, grep is quite line oriented,
Right. Maybe what I'm really looking for is a binary grep. For the time
being, I hacked together a tool that does just what I need for my qemu
test (no regexp matching, just matching a fix string starting at the
beginning of a line). See
https://git.glasklar.is/system-transparency/core/stboot/-/blob/43e91273a57473ee361e332926b88c1b4fe9917a/integration/look-for/look-for.go
I use this in combination with timeout (GNU coreutils) to fail the test
if no match for the login prompt is found within reasonable time.
A more general binary grep could match a regexp against a binary file or
stream, with options to exit on first match (my immediate usecase),
output the count of matches, or output the positions for each match. I
still think some of those features would make sense as part of GNU grep.
Regards,
/Niels
-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
 

[Message part 2 (text/html, inline)]

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

From: "David G. Pickett" <dgpickett <at> aol.com>
To: "69929 <at> debbugs.gnu.org" <69929 <at> debbugs.gnu.org>, 
 Niels Möller <nisse <at> lysator.liu.se>
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月22日 20:34:19 +0000 (UTC)

[Message part 1 (text/plain, inline)]

 $ (echo foo;sleep 10;echo bar)|time grep -q foo;echo $?0.00user 0.00system 0:00.00elapsed 50%CPU (0avgtext+0avgdata 2432maxresident)k0inputs+0outputs (0major+107minor)pagefaults 0swaps0$ 
The shell hangs for 10 seconds on its child pids but grep does not!
 On Thursday, March 21, 2024 at 11:03:49 AM EDT, Niels Möller <nisse <at> lysator.liu.se> wrote: 
 
 Niels Möller <nisse <at> lysator.liu.se> writes:
> E.g., if I run 
>
> (printf foo ; sleep 30) | grep -q foo
>
> I want grep to exit successfully right away. Currently, grep waits until
> it gets EOF on the input, 30 seconds later.
Sorry if I'm confused about how to script this. The following (bash
syntax) is a better example:
 grep -q foo <(sh -c 'printf foo ; sleep 30' &)
This blocks 30 seconds before exiting. In contrast, 
 grep -q foo <(sh -c echo foo ; sleep 30' &)
(only difference is the newline at the end of the line) does exit
immediately.
Regards,
/Niels
-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
 

[Message part 2 (text/html, inline)]

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

From: "David G. Pickett" <dgpickett <at> aol.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 
 Niels Möller <nisse <at> lysator.liu.se>
Cc: "69929 <at> debbugs.gnu.org" <69929 <at> debbugs.gnu.org>
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月22日 21:01:49 +0000 (UTC)

[Message part 1 (text/plain, inline)]

 $ (echo -n foo;sleep 10;echo bar)|time sh -c '(grep -q foo;echo $?)'00.00user 0.00system 0:10.00elapsed 0%CPU (0avgtext+0avgdata 2432maxresident)k0inputs+0outputs (0major+202minor)pagefaults 0swaps$ (echo -n foo;sleep 10)|time sh -c '(grep -q foo;echo $?)'00.00user 0.00system 0:10.00elapsed 0%CPU (0avgtext+0avgdata 2432maxresident)k0inputs+0outputs (0major+202minor)pagefaults 0swaps$
 On Friday, March 22, 2024 at 04:43:56 PM EDT, David G. Pickett" via Bug reports for GNU grep <bug-grep <at> gnu.org> wrote: 
 
 Maybe the opposite: -only_lines_with_newline ? Most users consider a line at EOF lacking a trailing newline as still a line, but perhaps some do not?
  On Friday, March 22, 2024 at 04:25:38 AM EDT, Niels Möller <nisse <at> lysator.liu.se> wrote: 
 
 Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 3/21/24 06:57, Niels Möller wrote:
>> I'm having grep -q read input from a pipe. I would like grep to exit
>> successfully as soon as a match occurs, without requiring the line to be
>> terminated by newline or EOF (unless the grep pattern includes '$', that
>> is).
>
> Grep used to behave almost that way. It did wait for a newline but it
> did not wait for EOF. But people started complaining about that
> behavior so we changed it.
Some --exit-early option? Sounds reasonable, but not enough for my
usecase. And I understand it might be an undesirable default behavior of
-q: Not so nice if changing "foo | grep" to "foo | grep -q" could make
foo fail with EPIPE/SIGPIPE.
(BTW, man page says about the -q option "Exit immediately with zero
status if any match is found", from reading that, I would not expect
grep to continue to read the rest of the file until EOF).
> However, not waiting for a newline is problematic; although doable it
> would be a bit of a pain to program and not sure it's worth the
> effort. Grep didn't used to do that.
I only have a rather abstract understanding of regexp matching, but for
patterns that aren't extended to require backtracking, in principle it
should be doably to feed the state machine one character at a time, with
no buffering of input?
jackson <at> fastmail.com writes:
> If you're not sure whether your actual input of interest will end
> in a newline, can you add one, to "feed grep's newline hunger",
> thus for instance replacing your example:
>
> grep -q foo <(sh -c 'printf foo ; sleep 30' &)
>
> with:
>
> grep -q foo <(sh -c 'printf foo ; echo ; sleep 30' &)
Not so easy when the input is the log output by a still running process
(in my case qemu).
> In any case, grep is quite line oriented,
Right. Maybe what I'm really looking for is a binary grep. For the time
being, I hacked together a tool that does just what I need for my qemu
test (no regexp matching, just matching a fix string starting at the
beginning of a line). See
https://git.glasklar.is/system-transparency/core/stboot/-/blob/43e91273a57473ee361e332926b88c1b4fe9917a/integration/look-for/look-for.go
I use this in combination with timeout (GNU coreutils) to fail the test
if no match for the login prompt is found within reasonable time.
A more general binary grep could match a regexp against a binary file or
stream, with options to exit on first match (my immediate usecase),
output the count of matches, or output the positions for each match. I
still think some of those features would make sense as part of GNU grep.
Regards,
/Niels
-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
 
 

[Message part 2 (text/html, inline)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Dennis Clarke <dclarke <at> blastwave.org>, 69929 <at> debbugs.gnu.org
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月22日 14:12:20 -0700

On 3/22/24 12:25, Dennis Clarke via Bug reports for GNU grep wrote:
> Old Solaris 8, once fully patched, was definately
> compliant with SUSv2 which is all of POSIX.1b-1993, POSIX.1c-1996
POSIX does not specify the behavior of grep when the input is not a text 
file, and a file that ends in a non-newline is not a text file. So 
Solaris grep and GNU grep can do what they like when the input ends in a 
non-newline; they don't have to agree with each other.

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

From: Dennis Clarke <dclarke <at> blastwave.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 69929 <at> debbugs.gnu.org
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月23日 16:13:06 -0400

On 3/22/24 17:12, Paul Eggert wrote:
> On 3/22/24 12:25, Dennis Clarke via Bug reports for GNU grep wrote:
>> Old Solaris 8, once fully patched, was definately
>> compliant with SUSv2 which is all of POSIX.1b-1993, POSIX.1c-1996
> 
> POSIX does not specify the behavior of grep when the input is not a text 
> file, and a file that ends in a non-newline is not a text file. So 
> Solaris grep and GNU grep can do what they like when the input ends in a 
> non-newline; they don't have to agree with each other.
re "a file that ends in a non-newline is not a text file" <-- really?
That is a new one on me. Regardless ... this is entirely a GNU sed
discussion so the comparison to some XPG4 grep from old old Solaris
is not really all that helpful. Sorry.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

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

From: Dennis Clarke <dclarke <at> blastwave.org>
To: bug-grep <at> gnu.org
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月23日 16:15:28 -0400

On 3/22/24 16:42, David G. Pickett via Bug reports for GNU grep wrote:
>
> Most users consider a line at EOF lacking a trailing newline as
> still a line, but perhaps some do not?
>
Good ol "wc" says it is not a line. I would go with what "wc" claims.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

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

From: Martin Schulte <gnu <at> schrader-schulte.de>
To: "David G. Pickett" <dgpickett <at> aol.com>
Cc: 69929 <at> debbugs.gnu.org, bug-grep <at> gnu.org, nisse <at> lysator.liu.se,
 eggert <at> cs.ucla.edu
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月23日 22:07:58 +0100

Hello David!
Am 2024年3月22日 20:42:12 +0000 (UTC) schrieb "David G. Pickett" via Bug reports for GNU grep <bug-grep <at> gnu.org>:
> Most users consider a line at EOF lacking a trailing newline as still a line, but perhaps some do not?
Well, POSIX doesn't: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
The definition may cause trouble with shell's read - e.g. when reading a file created on Windows with notepad where it is easy to accidentally create an incomplete line (compared to vi where I don't know an easy way).
Best regards,
Martin

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

From: "David G. Pickett" <dgpickett <at> aol.com>
To: Martin Schulte <gnu <at> schrader-schulte.de>
Cc: "69929 <at> debbugs.gnu.org" <69929 <at> debbugs.gnu.org>,
 "bug-grep <at> gnu.org" <bug-grep <at> gnu.org>,
 "nisse <at> lysator.liu.se" <nisse <at> lysator.liu.se>,
 "eggert <at> cs.ucla.edu" <eggert <at> cs.ucla.edu>
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月24日 13:06:13 +0000 (UTC)

[Message part 1 (text/plain, inline)]

 Perhaps the man page should warn users that such last lines are ignored. Is there a mention under an option to include or disclude them?
 On Saturday, March 23, 2024 at 05:08:08 PM EDT, Martin Schulte <gnu <at> schrader-schulte.de> wrote: 
 
 Hello David!
Am 2024年3月22日 20:42:12 +0000 (UTC) schrieb "David G. Pickett" via Bug reports for GNU grep <bug-grep <at> gnu.org>:
> Most users consider a line at EOF lacking a trailing newline as still a line, but perhaps some do not?
Well, POSIX doesn't: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
The definition may cause trouble with shell's read - e.g. when reading a file created on Windows with notepad where it is easy to accidentally create an incomplete line (compared to vi where I don't know an easy way).
Best regards,
Martin
 

[Message part 2 (text/html, inline)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "David G. Pickett" <dgpickett <at> aol.com>,
 Martin Schulte <gnu <at> schrader-schulte.de>
Cc: "69929 <at> debbugs.gnu.org" <69929 <at> debbugs.gnu.org>,
 "bug-grep <at> gnu.org" <bug-grep <at> gnu.org>,
 "nisse <at> lysator.liu.se" <nisse <at> lysator.liu.se>
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月24日 18:35:43 -0700

On 2024年03月24日 06:06, David G. Pickett wrote:
> Perhaps the man page should warn users that such last lines are ignored.
They aren't ignored. And the documentation already covers this issue, on 
its very first page:
https://www.gnu.org/software/grep/manual/html_node/Introduction.html
This says, "If the final byte of an input file is not a newline, grep 
silently supplies one."
I doubt whether this minor issue should be covered in the man page, as 
it is merely a brief summary of the documentation.

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

From: Gary Johnson <garyjohn <at> spocom.com>
To: bug-grep <at> gnu.org
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月24日 23:47:11 -0700

On 2024年03月24日, Paul Eggert wrote:
> On 2024年03月24日 06:06, David G. Pickett wrote:
> > Perhaps the man page should warn users that such last lines are ignored.
> 
> They aren't ignored. And the documentation already covers this issue,
> on its very first page:
> 
> https://www.gnu.org/software/grep/manual/html_node/Introduction.html
> 
> This says, "If the final byte of an input file is not a newline, grep
> silently supplies one."
> 
> I doubt whether this minor issue should be covered in the man page,
> as it is merely a brief summary of the documentation.
I would call the man page a _concise_ summary of the behavior of the
topic program or function, but I don't think it should be an
abridged summary. It should be complete. There should not be any
feature or behavior of the program or function completely missing
from the man page. Other documentation may expand upon and further
explain behavior, but it should not contain the only mention of some
behavior.
Exceptions may be made for larger, more complicated programs such
as gnuplot, make or gdb, that do require a full manual apart from
a man page, but grep is small enough in concept that it shouldn't
require the user to read anything outside of the man page.
My unsolicited 0ドル.02.
Regards,
Gary

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-grep <at> gnu.org
Subject: Re: bug#69929: Can grep -q report matches in incomplete lines?
Date: 2024年3月25日 06:11:06 -0700

On 2024年03月24日 23:47, Gary Johnson wrote:
> grep is small enough in concept that it shouldn't
> require the user to read anything outside of the man page.
Maybe grep's concept is simple, but the program itself is not that 
simple. For example, the grep man page doesn't document all the ins and 
outs of PCREs. (Not even the manual does that!)
The GNU Coding Standards are pretty clear that man pages are 
secondary.[1] To some extent the GNU grep man page is already too long 
and detailed. FreeBSD's grep man page[2] is a better length (and 
amusingly, it also doesn't mention the minor detail of files ending in 
non-newline).
[1]: https://www.gnu.org/prep/standards/html_node/Man-Pages.html
[2]: https://man.freebsd.org/cgi/man.cgi?query=grep

Previous Next

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