<div dir="ltr">I'm very late in responding to this, as I was on vacation and then procrastinating. <div><br></div><div>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 <span style="color:rgb(0,0,0);font-size:13px">\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. </span><div><br><div>For those playing along at home here is the summary:<div><br></div><div> * I submitted a BIF os:isatty/1 that took the atoms stdin/stderr/stdout and would say if the file descriptor was a tty. </div><div> * 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</div><div>* Detecting the type of device was never a goal of this PR. Checking $TERM on most *nix systems is acceptable.</div><div>* 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.</div><div>* 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).</div><div>* This second patch was deemed unacceptable by the OTP team since isatty would not be relevant to windows users.</div><div>* 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.</div><div>* 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</div><div>* I declined to do that work, and it is up for grabs.</div><div><br></div><div>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?</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Andrew </div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 6, 2014 at 12:04 PM, Tuncer Ayaz <span dir="ltr"><<a href="mailto:tuncer.ayaz@gmail.com" target="_blank">tuncer.ayaz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Lukas and Andrew,<br>
<br>
as the original ticket[1] was closed and it was suggested to continue<br>
the discussion on the mailing list, let's try to conclude the<br>
discussion regarding the usefulness of isatty/1 here.<br>
<br>
Lukas wrote:<br>
> The only check that I can think of that you can do with isatty is<br>
> checking if the IODevice definitely does not support any escape<br>
> sequences. Getting true back does (afaik) not give you any details<br>
> about how you can communicate with it.<br>
<br>
>From what I understood, detecting that it's not an interactive<br>
terminal is sufficient for Andrew to decide that the output should<br>
automatically go to a file. This appears to be reasonable and useful<br>
regardless of escape codes. Thoughts?<br>
<br>
<br>
[1] <a href="https://github.com/erlang/otp/pull/480" target="_blank">https://github.com/erlang/otp/pull/480</a><br>
</blockquote></div><br></div></div></div></div></div>