I'm saying most unix tools do not error when the pipe is closed and I gave 'yes' as a simple example but there are many others. grep found what I was looking for and I don't care that git didn't recurse further (in fact I'm happy that it didn't waste time doing so). There is no problem except that git insists on complaining about the closed pipe. Matt On Wed, Sep 18, 2024 at 6:16 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Phillip Wood <phillip.wood123@xxxxxxxxx> 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? >
