<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Lukas, I just tried with erlang R17 to check, and it seems to
    work fine with the newer homebrew version of bash as well as the
    older default /bin/bash. So maybe this helps confirm your suspicion.<br>
    <br>
    best,<br>
    Igor<br>
    <br>
    <div class="moz-cite-prefix">On 14/03/2017 15:40, Lukas Larsson
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAP3zBqNTaywE2v7LeXpDwvis+Ucs+3=zf1W6PHKQ2GcH00uvbA@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hello,
        <div><br>
        </div>
        <div>I think that it may be a change done in Erlang/OTP 18 that
          causes this behaviour. Specifically OTP-12239. Using
          non-blocking I/O on stdin/stdout seems to kind of work, until
          it doesn't. Different platforms and tools handle it very
          differently.</div>
        <div><br>
        </div>
        <div>The only "solution" that I can think of right now is to use
          dedicated read and/or write threads within the VM to handle
          stdin/stdout, but I was hoping to avoid having to do that.</div>
        <div><br>
        </div>
        <div>The problem, for those that are interested, is that the
          O_NONBLOCK flag is set on the file description, not the file
          descriptor. Which causes all kinds of problems, I thought I
          had handled them all, but apparently not enough. </div>
        <div><br>
        </div>
        <div>Lukas</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Tue, Mar 14, 2017 at 1:35 PM, Igor
          Clark <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:igor.clark@gmail.com" target="_blank">igor.clark@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello
            Matthias,<br>
            <br>
            Not sure if it's related, but I see bash v4.4.5 terminal I/O
            get really messed up on Mac OSX after the erlang runtime
            aborts. It happens whether through a NIF segfault during
            dev, or just by doing ^C and 'abort'. The terminal input
            becomes unusable, vim buffers don't display roughly half the
            text; 'reset' makes no difference, I have to close the
            Terminal.app window and start over. Haven't had time to dig
            into it at all, just kind of got used to it.<br>
            <br>
            I thought it might be R19, but I switched back to R18 and it
            still happened. Which made me wonder if it's anything to do
            with tmux, but I tried it in a standard Terminal window
            without tmux, and it happened then too. So I tried using the
            default OSX /bin/bash (which is v3.2.57) instead of the
            homebrew version (4.4.5) - and it didn't happen at all.<br>
            <br>
            Which is a long-winded way of saying, maybe this might also
            be a "recent bash" issue, rather than an erlang issue?<br>
            <br>
            Cheers,<br>
            Igor
            <div class="HOEnZb">
              <div class="h5"><br>
                <br>
                On 13/03/2017 20:32, Matthias Lang wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  Hi,<br>
                  <br>
                  Erlang 19.1 and 19.2 seems to break something to do
                  with terminal<br>
                  input on some but not all of my Debian x86-64
                  machines. I took a quick<br>
                  look through the recent mailing list archives and
                  haven't seen any<br>
                  mention of this. Maybe I missed it. Maybe it's just
                  me.<br>
                  <br>
                  Example:<br>
                  <br>
                      | ~ >uname -a<br>
                      | Linux hec 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1
                  (2017-02-27) x86_64 GNU/Linux<br>
                      | ~ >read x<br>
                      | hello world<br>
                      | ~ >erl<br>
                      | Erlang/OTP 19 [erts-8.1] [source] [64-bit]
                  [smp:4:4] [async-threads:10] [hipe]
                  [kernel-poll:false]<br>
                      |<br>
                      | Eshell V8.1  (abort with ^G)<br>
                      | 1><br>
                      | BREAK: (a)bort (c)ontinue (p)roc info (i)nfo
                  (l)oaded<br>
                      |        (v)ersion (k)ill (D)b-tables
                  (d)istribution<br>
                      | a<br>
                      | ~ >read x<br>
                      | bash: read: read error: 0: Resource temporarily
                  unavailable<br>
                  <br>
                  The "read error: 0: Resource temporarily unavailable"
                  part is unexpected.<br>
                  Using 'cat' instead of 'read' produces a similar
                  error:<br>
                  <br>
                      | cat: -: Resource temporarily unavailable<br>
                  <br>
                  'strace' tells me something is screwy about stdin:<br>
                  <br>
                      | read(0, 0x7f1010dbb000, 131072)         = -1
                  EAGAIN (Resource temporarily unavailable)<br>
                  <br>
                  read(2) tells me EAGAIN suggests that stdin has been
                  left in with O_NONBLOCK.<br>
                  Is that Erlang's problem to clean up, or is that
                  supposed to happen on<br>
                  program exit? I haven't read up on that.<br>
                  <br>
                  Doing the same thing on 17.4 works fine.<br>
                  <br>
                  Debian 3.16.39-1 and erts-8.2.1 produces a related by
                  different strangeness:<br>
                  <br>
                      | 1><br>
                      | BREAK: (a)bort (c)ontinue (p)roc info (i)nfo
                  (l)oaded<br>
                      |       (v)ersion (k)ill (D)b-tables
                  (d)istribution<br>
                      | a<br>
                      | $ sh: turning off NDELAY mode<br>
                  <br>
                  Can anyone else see this? Any idea what's up?<br>
                  <br>
                  Matt<br>
                  ______________________________<wbr>_________________<br>
                  erlang-questions mailing list<br>
                  <a moz-do-not-send="true"
                    href="mailto:erlang-questions@erlang.org"
                    target="_blank">erlang-questions@erlang.org</a><br>
                  <a moz-do-not-send="true"
                    href="http://erlang.org/mailman/listinfo/erlang-questions"
                    rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br>
                </blockquote>
                <br>
                ______________________________<wbr>_________________<br>
                erlang-questions mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:erlang-questions@erlang.org"
                  target="_blank">erlang-questions@erlang.org</a><br>
                <a moz-do-not-send="true"
                  href="http://erlang.org/mailman/listinfo/erlang-questions"
                  rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>