fatal from submodule status --recursive when used with grep -q

> 
> If I try to grep the output I get a fatal error:
> 
> % git submodule status --recursive | grep -q "^+"
> fatal: failed to recurse into submodule 'tools/OpenROAD'
> 
> I didn't expect any output but did want the return status (0).  I'm
> guessing git is unhappy that grep -q exits on the first occurrence of
> the pattern.  I don't feel fatal is appropriate here.

> I can work around this by writing to a tmpfile but would like to see
> this addressed.
> 
> Thanks!
> Matt
> 

>
> Hi Matt
>
> On 16/09/2024 16:08, Matt Liberty wrote:
> >
> > If I try to grep the output I get a fatal error:
> >
> > % git submodule status --recursive | grep -q "^+"
> > fatal: failed to recurse into submodule 'tools/OpenROAD'
> >
> > I didn't expect any output but did want the return status (0).  I'm
> > guessing git is unhappy that grep -q exits on the first occurrence of
> > the pattern.  I don't feel fatal is appropriate here.
>
> I assume git is dying with SIGPIPE. As the only purpose of "git
> submodule status" is to write the status information to stdout that
> sounds reasonable. If you want to collect the exit status you need to
> consume the whole output so that the command runs to completion.
>
> Best Wishes
>
> Phillip
>
> > I can work around this by writing to a tmpfile but would like to see
> > this addressed.
> >
> > Thanks!
> > Matt
> >

> On 16/09/2024 16:08, Matt Liberty wrote:
>> If I try to grep the output I get a fatal error:
>> % git submodule status --recursive | grep -q "^+"
>> fatal: failed to recurse into submodule 'tools/OpenROAD'
>> I didn't expect any output but did want the return status (0).  I'm
>> guessing git is unhappy that grep -q exits on the first occurrence of
>> the pattern.  I don't feel fatal is appropriate here.
>
> I assume git is dying with SIGPIPE. As the only purpose of "git
> submodule status" is to write the status information to stdout that
> sounds reasonable. If you want to collect the exit status you need to
> consume the whole output so that the command runs to completion.

>
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
> > On 16/09/2024 16:08, Matt Liberty wrote:
> >> If I try to grep the output I get a fatal error:
> >> % git submodule status --recursive | grep -q "^+"
> >> fatal: failed to recurse into submodule 'tools/OpenROAD'
> >> I didn't expect any output but did want the return status (0).  I'm
> >> guessing git is unhappy that grep -q exits on the first occurrence of
> >> the pattern.  I don't feel fatal is appropriate here.
> >
> > I assume git is dying with SIGPIPE. As the only purpose of "git
> > submodule status" is to write the status information to stdout that
> > sounds reasonable. If you want to collect the exit status you need to
> > consume the whole output so that the command runs to completion.
>
> Yes, but isn't the main point of that complaint that "failed to
> recurse into" is not a good way to say "because you closed the
> reading end of the pipe, we are aborting the operation and not
> decending into 'tools/OpenROAD' submodule", is it?
>

> Matt
> 
> On Wed, Sep 18, 2024 at 3:05 AM Phillip Wood <phillip.wood123@gmail.com 
> <mailto:phillip.wood123@gmail.com>> wrote:
> 
>     Hi Matt
> 
>     On 16/09/2024 16:08, Matt Liberty wrote:
>      >
>      > If I try to grep the output I get a fatal error:
>      >
>      > % git submodule status --recursive | grep -q "^+"
>      > fatal: failed to recurse into submodule 'tools/OpenROAD'
>      >
>      > I didn't expect any output but did want the return status (0).  I'm
>      > guessing git is unhappy that grep -q exits on the first occurrence of
>      > the pattern.  I don't feel fatal is appropriate here.
> 
>     I assume git is dying with SIGPIPE. As the only purpose of "git
>     submodule status" is to write the status information to stdout that
>     sounds reasonable. If you want to collect the exit status you need to
>     consume the whole output so that the command runs to completion.
> 
>     Best Wishes
> 
>     PhillipSo
> 
>      > I can work around this by writing to a tmpfile but would like to see
>      > this addressed.
>      >
>      > Thanks!
>      > Matt
>      >
> 

>
> On 18/09/2024 15:28, Matt Liberty wrote:
> > I'm not trying to capture the exit status of git but of grep.  Compare
> > it to "yes|grep -q y" which doesn't generate any error even though yes
> > generates endless output.
>
> Sorry, I'd misunderstood your original message. So the problem is that
> you want "git submodule status" to be quiet (i.e. not print an error
> message) when it dies of SIGPIPE?
>
> Best Wishes
>
> Phillip
>
> > Matt
> >
> > On Wed, Sep 18, 2024 at 3:05 AM Phillip Wood <phillip.wood123@gmail.com
> > <mailto:phillip.wood123@gmail.com>> wrote:
> >
> >     Hi Matt
> >
> >     On 16/09/2024 16:08, Matt Liberty wrote:
> >      >
> >      > If I try to grep the output I get a fatal error:
> >      >
> >      > % git submodule status --recursive | grep -q "^+"
> >      > fatal: failed to recurse into submodule 'tools/OpenROAD'
> >      >
> >      > I didn't expect any output but did want the return status (0).  I'm
> >      > guessing git is unhappy that grep -q exits on the first occurrence of
> >      > the pattern.  I don't feel fatal is appropriate here.
> >
> >     I assume git is dying with SIGPIPE. As the only purpose of "git
> >     submodule status" is to write the status information to stdout that
> >     sounds reasonable. If you want to collect the exit status you need to
> >     consume the whole output so that the command runs to completion.
> >
> >     Best Wishes
> >
> >     PhillipSo
> >
> >      > I can work around this by writing to a tmpfile but would like to see
> >      > this addressed.
> >      >
> >      > Thanks!
> >      > Matt
> >      >
> >

> On Thu, Sep 19, 2024 at 7:22 AM <phillip.wood123@gmail.com> wrote:
>>
>> On 18/09/2024 15:28, Matt Liberty wrote:
>> > I'm not trying to capture the exit status of git but of grep.  Compare
>> > it to "yes|grep -q y" which doesn't generate any error even though yes
>> > generates endless output.
>>
>> Sorry, I'd misunderstood your original message. So the problem is that
>> you want "git submodule status" to be quiet (i.e. not print an error
>> message) when it dies of SIGPIPE?
>
> Yes and also to have a 0 exit code.  No error occurred from my perspective.

> Matt Liberty <mliberty@precisioninno.com> writes:
> > Yes and also to have a 0 exit code.  No error occurred from my perspective.
>
> I am sympathetic to the line of reasoning, but I wouldn't go that
> far.
>
> Running "yes | less" and killing it with 'q' saying "ok I've seen
> enough", and running "yes" and killing it with '^C' saying "ok I've
> seen enough" are pretty much the same from the end-user perspective.
> You told the command to go away, and the command complied.  But I
> haven't seen anybody complaining if they see a "Killed" message or
> "echo $?" immediately after it says 130 for the latter.

>
> On Thu, Sep 19, 2024 at 3:10 PM Junio C Hamano <gitster@pobox.com> wrote:
> > Matt Liberty <mliberty@precisioninno.com> writes:
> > > Yes and also to have a 0 exit code.  No error occurred from my perspective.
> >
> > I am sympathetic to the line of reasoning, but I wouldn't go that
> > far.
> >
> > Running "yes | less" and killing it with 'q' saying "ok I've seen
> > enough", and running "yes" and killing it with '^C' saying "ok I've
> > seen enough" are pretty much the same from the end-user perspective.
> > You told the command to go away, and the command complied.  But I
> > haven't seen anybody complaining if they see a "Killed" message or
> > "echo $?" immediately after it says 130 for the latter.
>
> Regarding the exit code, it's not even clear how that factors into
> this discussion considering that, in the presented example,
> git-submodule is upstream of a pipe, thus its exit code is lost
> anyhow.

> On Thu, Sep 19, 2024 at 12:40 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
>>
>> Regarding the exit code, it's not even clear how that factors into
>> this discussion considering that, in the presented example,
>> git-submodule is upstream of a pipe, thus its exit code is lost
>> anyhow.