On 9/9/18 11:20 AM, Eli Schwartz wrote: > On 9/3/18 7:50 AM, Levente Polyak via arch-projects wrote: >> From: anthraxx <anthr...@archlinux.org> >> >> bsdtar doesn't like it when the stream gets closed before it finishes >> which may be the case when grep found its match on potentially huge >> archives. Instead of suppressing the whole strerr , we just pipe >> the output through cat which ensures the stream remains open for bsdtar >> but we may still catch and see useful messages on stderr. > > This is functionally 23c2b82c336bf19b7a29a90d19bca4423d8b8839 again, but > for more locations. I'm never going to understand why some people get > this SIGPIPE but I don't, but I guess it makes sense to do this change > -- especially as we do the same elsewhere. > > (We need to buffer it somehow with some extra command, grep doesn't have > a way to only output the first result but still avoid propagating > SIGPIPE. Why does bsdtar care about this anyway...)
As discussed on IRC, I can finally reproduce this, e.g. bsdtar xOf /path/to/file | grep --binary-files=text a (many matches for the string "a") With grep -q or grep -m1, it errors with cat | grep -q/-m1 it still errors due to the buffer going *into* grep, having insufficient room :( with grep | head -1 it only errors, if the matching buffer going *out* of grep is too large. For our uses it should only ever match exactly once. So this is what we should do. (Or complain to libarchive. :p) -- Eli Schwartz Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature