The portageq command abends when stdout is piped to head's input. Running the following command will produce the desired [int] lines of output: $ portageq --orphaned | head -n [int] It will also cause portageq to abend and produce the following error complaining of a broken pipe. ``` Traceback (most recent call last): File "/usr/lib/python-exec/python3.9/portageq", line 1474, in <module> sys.exit(main(sys.argv)) File "/usr/lib/python-exec/python3.9/portageq", line 1398, in main return pquery(parser, opts, args) File "/usr/lib/python-exec/python3.9/portageq", line 1212, in pquery writemsg_stdout("%s\n" % (cpv,), noiselevel=-1) File "/usr/lib/python3.9/site-packages/portage/util/__init__.py", line 121, in writemsg_stdout writemsg(mystr, noiselevel=noiselevel, fd=sys.stdout) File "/usr/lib/python3.9/site-packages/portage/util/__init__.py", line 116, in writemsg fd.flush() BrokenPipeError: [Errno 32] Broken pipe Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'> BrokenPipeError: [Errno 32] Broken pipe ``` Piping to `|&` suppresses the issue. Thus, `$ portageq --orphaned |& head -n [int]` works just fine. Confusingly neither `tail` nor `grep` trigger the bug when using a standard pipe. So, the following commands work just fine: $ portageq --orphaned | tail -n [int] $ portageq --orphaned | grep "[some pattern]" Several people in #gentoo on IRC were also able to reproduce the issue so it's not something unique to my setup. Have fun with this one!
I believe this was fixed portage-3.0.43 by setting the SIGPIPE handler to SIG_DFL. https://gitweb.gentoo.org/proj/portage.git/commit/?id=7141d7f0033bc7bf5bdf825271a0002657d4fb83
