> From: Duy Nguyen <xxxxxx@gmail.com>
> Date: Thursday, September 10, 2020 4:16 AM
>
> On Thu, Sep 10, 2020 at 10:55 AM John Cowan <xxxxxx@ccil.org> wrote:
>
>>> With our retaining port-internal-fd, having terminal? take a port
>>> is duplicative, and I'm leaning strongly towards having terminal?
>>> only take an fd.
>
>> I agree, and I've changed the spec accordingly: fd only, with a
>> note saying it's safe to use the value of port-internal-fd here.
>
> That seems to encourage the use of port-internal-fd, which is
> something I'd rather to fall back to only when absolutely necessary
> (and preferably only for logging). The procedures that take an fd
> typically would get that fd from open-file or similar procedures, not
> through fd->port then port-internal-fd.

While I see your point, I'd counter by saying it's good to show one
safe example use of port-internal-fd in the SRFI doc.

Logging is also covered by a full implementation of the SRFI, by using
open-file with open/append, then fd->*-output-port with the
buffer/line or buffer/none optional argument.  Logging was in fact the
use case that motivated the addition of these fd->*-output-port optional
arguments, otherwise open/append made no sense as an open-file option.

> This may be out of scope, but what about (terminal? (current-output-port))?

That should work if you wrap (current-output-port) in port-internal-fd?,
i.e. (terminal? (port-internal-fd (current-output-port)))?

> A C program typically does isatty(1) (or 0 or 2) to check if it's
> attached to a terminal and adjust itself accordingly. That translates
> to either
>
> (terminal? 1)
>
> or
>
> (terminal? (current-output-port))
>
> in Scheme. I would prefer the latter as the current output port is not
> always "1" (output could be redirected to a string port, or something)
> and it feels less Schemey to just go with fd "1". Even in C sometimes
> people will use STDOUT_FILENO for clarity.

- Harold