reuse lint chokes on broken pipe
reuse lint | head will choke on the output pipe being closed by head with the following messaeg:
Traceback (most recent call last):
File "/home/felix/.local/bin/reuse", line 11, in <module>
sys.exit(main())
File "/home/felix/.local/lib/python3.6/site-packages/reuse/_main.py", line 256, in main
return parsed_args.func(parsed_args, project, out)
File "/home/felix/.local/lib/python3.6/site-packages/reuse/lint.py", line 335, in run
result = lint(report, out=out)
File "/home/felix/.local/lib/python3.6/site-packages/reuse/lint.py", line 33, in lint
report, out
File "/home/felix/.local/lib/python3.6/site-packages/reuse/lint.py", line 220, in lint_files_without_copyright_and_licensing
_write_element(file_, out=out)
File "/home/felix/.local/lib/python3.6/site-packages/reuse/lint.py", line 20, in _write_element
out.write(str(element))
BrokenPipeError: [Errno 32] Broken pipe
reuse --version
reuse 0.11.1
In this commit (https://github.com/fwolfst/reuse-tool/commit/419d08026b13998349989664eac6ecc19f36f469) I attack the specific case in the lint() command.
For some background, https://stackoverflow.com/questions/14207708/ioerror-errno-32-broken-pipe-python might be a good starting point. Alternatively, one could globally handle SIGPIPE differently. However this could have implications if sockets are used somewhere (I guess that is the case for the license downloads).
The "solution" from the commit will add additional output to stderr if an IOError occurred. This might or might not be favored. Most likely it should only happen when reuse is run with the --debug flag.
I cannot put much more effort in this "solution" but can craft a PR and try to include the --debug behavior if that is appreciated and has merging-probability :)
Also, ideally the command would still exit with the correct code which reflects reuse compliance. In the current state and also with the commit/patch applied, it would still exit 1 even if the project is compliant, but the output pipe broke.
@fwolfst I am an outside on this project, but IMHO I think your current solution looks great (depending on --debug seems overkill), please can you submit a PR?
Actually, given that the normal end of the output is a summary to STDOUT rather than STDERR, it might be better if the truncation warning went to STDOUT too.
I rebased it on latest master and it works fine.
I took the liberty of submitting the PR, crediting you. Hope that's OK. I didn't change the warning to STDOUT yet.
Oh haha, changing to STDOUT actually causes the broken pipe to reoccur. However I've changed it to catch BrokenPipeError instead of IOError, to avoid incorrectly handling some other form of I/O error.
I took the liberty of submitting the PR, crediting you. Hope that's OK. I didn't change the warning to
STDOUTyet.
Fine. Thanks. Ya, IOError sounds pretty broad. I think you cannot use STDOUT (afaiu that is the point of the exception ;) ).