Am Do., 10. Sept. 2020 um 21:58 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> On Thu, Sep 10, 2020 at 9:28 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> But if the Scheme implementation does not export any FDOs,
>> port-internal-fd won't help. I may have missed it earlier, but why
>> doesn't terminal? also work on a port?
>
>
> At this moment, I see terminal? is the same as POSIX isatty().  So if there's no FDO, terminal? can't return #t, I think.
> The equivalence of terminal? and isatty() can make differencet, because there's a case that isatty() returns -1 for a "terminal"--MinGW-w64/MSYS2 console uses named pipe to realize POSIX console features.  MinGW-w64 isatty() returns -1 for the fd connected to MSYS2 console, since technically it's a pipe, not a console device.
>
> If we take terminal? as an abstract sense---that it returns #t if the argument is somehow connected to what Scheme runtime thinks a terminal, then it may return #t for the default (current-input-port) running on MSYS2 console, even MSYS2 isatty() returns -1 for its internal fd.  If we make this choice, then it makes sense that (termina? port) => #t even if (port-internal-fd port) => #f.
>
> Well, MINGW/MSYS isn't strictly POSIX, but it'll be nice for srfi-170 to work on it consistently whenever possible.

For the application writer who doesn't care about fdos or other POSIX
internals, it would be nice to have a more or less reliable way to
find out whether the current input/output Scheme port is a terminal,
e.g. to decide whether to provide a REPL interface.