bug#57095: another "inappropriate ioctl" bug :)

[Josselin Poiret via Bug reports for GNU Guix <bug-guix@gnu.org>]

Hi!

Csepp <raingloom@riseup.net> writes:

> ```
> ./pre-inst-env guix import pypi -r linode-cli | tee -a gnu/packages/python-xyz.scm
>
> ...
> In guix/build/syscalls.scm:
>   2284:35  1 (_)
>    2273:8  0 (terminal-window-size _)
>
> guix/build/syscalls.scm:2273:8: In procedure terminal-window-size:
> In procedure terminal-window-size: Inappropriate ioctl for device
> ```
>
> I assume the progress bar code does not gracefully handle the very
> common case when stdout is not a terminal.

There is some code in place to handle this issue, and it works most of
the time, but not here.  The issue is that we handle any error coming
from ioctl by first throwing a `'system-error`, and handling it with a
`catch` that checks whether the errno is ENOTTY (and deprecated
equivalents) and in that case falls back to a good default.  In the case
where the error is not of that type, it is rethrown.  This works well in
most cases, but here comes the Guile shenanigans:

We also use a big wrapping `with-error-handling` to display errors
properly in the case when they are not caught.  The difference is that
`with-error-handling` adds a non-unwinding handler, while catch is
unwinding.  My first thought was that non-unwinding handlers, even outer
ones would get priority over unwinding ones, since once the stack's
unwound you can't really go back (I have no idea if that last part is
actually true).  In practice this is actually false, I tested with a
very simple example, but that lead me to test by setting `#:unwind? #t`
for the `guard*` definition in guix/ui.scm and the issue went away, so I'm
clueless as to why this happens.  What seems weird is that the error is
not caught at all!

Does anyone have a clue?

Best,
-- 
Josselin Poiret