> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
> Date: Thursday, September 10, 2020 2:28 PM
>
> Am Do., 10. Sept. 2020 um 21:23 Uhr schrieb <xxxxxx@ancell-ent.com>:
>>
>> Responding to the one question I can immediately answer:
>>
>>> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
>>> Date: Thursday, September 10, 2020 2:07 PM
>>>
>>> [...]
>>>
>>> PS How can I find out whether (current-input-port) or
>>> (current-output-port) is a terminal?
>>
>> Ummm, and copying from a REPL just to be sure:
>>
>>> (terminal? (port-internal-fd (current-input-port)))
>> #t
>>
>> port-internal-fd returns a FDO.  terminal? can accept a FDO.
>
> But if the Scheme implementation does not export any FDOs,
> port-internal-fd won't help.

In that case, you should have \words/ with your SRFI 170 implementor,
as long as you're using a POSIX system where this should be literally
trivial.  Obviously if you're not on top of a POSIX system, like
you're using raw Windows, you can only expect a best effort, perhaps
including an imperfect or unimplemented post-internal-fd and/or
terminal?  That's build into the pie when an implementor attempts such
a mapping to system with alien paradigms (and it's not entirely bad
we don't live in a POSIX monoculture ... for an all too short period
in the mid-1990s, it was an absolute pleasure to us NT instead of
UNIX(TM)).

> I may have missed it earlier, but why doesn't terminal? also work on
> a port?

Because it  duplicates code, including sanity checking, and SRFI
170 is already enough of a monster as it is; we weren't exactly
enthusiastic in going through every procedure that could take a
port (fd) and cutting that for *every* one except truncate-file
and file-info.  And using simple procedures as building blocks is
the Lisp way, after all.

- Harold