[erlang-questions] isatty/1 [erlang/otp#480]

[Andrew Stone]

I'm very late in responding to this, as I was on vacation and then
procrastinating.

Tuncer, I just want to know if I'm talking to a file so I can omit writing
escape codes with io:format when attempting to write a warning in red to
the user. If the escape codes do get written to a file by automated
tooling, the file it will have things like \e[0;31m in there, obscuring the
output. It'd be better if we swapped that for an [Err] or just omitted it
altogether in that case.

For those playing along at home here is the summary:

 * I submitted a BIF os:isatty/1 that took the atoms stdin/stderr/stdout
and would say if the file descriptor was a tty.
 * The stated purpose was to detect if the FD was NOT a tty and therefore
allow a user program to make a decision about whether it wanted to write
some escape code to that device
* Detecting the type of device was never a goal of this PR. Checking $TERM
on most *nix systems is acceptable.
* It was suggested that this be moved to the I/O subsystem (io:isatty/1),
to take a group_leader instead of the atoms stdin/stdout/stderr  and do the
check in the driver.
* A second patch was written that did the above for all systems except
windows, as windows does not support isatty nor ansi escape codes
(_isatty/1 does exist and provides similar guarantees to isatty).
* This second patch was deemed unacceptable by the OTP team since isatty
would not be relevant to windows users.
* OTP team declined both patches. Now, as before, we are left with a
situation where *nix and Windows users cannot determine whether the output
is going to a terminal.
* The OTP team suggested that instead the I/O protocol be modified to
handle all possible escape codes so that different backend code could be
written on windows to emulate the escape codes of ANSI and other terminals.
It was also suggested that an ncurses like interface may be provided
* I declined to do that work, and it is up for grabs.

I expect that most people on here don't use Windows for running their
Erlang code and they may find the patches in the attached PR useful. Feel
free to use that code in your own builds. There are also many other useful
posix functions that would benefit a lot of Erlang developers, but it looks
like for now that code will have to be relegated to NIFs or custom builds.
Maybe one day we can have a posix module included in the erlang
distribution that provides these functions. What do you all think?

-Andrew

On Mon, Oct 6, 2014 at 12:04 PM, Tuncer Ayaz <tuncer.ayaz@REDACTED> wrote:

> Hi Lukas and Andrew,
>
> as the original ticket[1] was closed and it was suggested to continue
> the discussion on the mailing list, let's try to conclude the
> discussion regarding the usefulness of isatty/1 here.
>
> Lukas wrote:
> > The only check that I can think of that you can do with isatty is
> > checking if the IODevice definitely does not support any escape
> > sequences. Getting true back does (afaik) not give you any details
> > about how you can communicate with it.
>
> From what I understood, detecting that it's not an interactive
> terminal is sufficient for Andrew to decide that the output should
> automatically go to a file. This appears to be reasonable and useful
> regardless of escape codes. Thoughts?
>
>
> [1] https://github.com/erlang/otp/pull/480
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141019/c7dd77b3/attachment.htm>