<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 18, 2017 at 6:51 PM, Ben Franksen <span dir="ltr"><<a href="mailto:ben.franksen@online.de" target="_blank">ben.franksen@online.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1mr" class="a3s aXjCH m15ae3a0d39960b58">What exactly is meant here with "conflate"?<br></div></blockquote><div><br></div><div>Confusing two distinct mechanisms that appear on the surface to be similar. See below for why this is an inappropriate conflation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1mr" class="a3s aXjCH m15ae3a0d39960b58">
<br>
When you turn off buffering for stdin, then of course backspace cannot<br>
work. That should be clear.</div></blockquote></div><br>Except that is not true anywhere but recent versions of ghc's runtime, and (specifically because they use readline or editline) things like Python's REPL. Try it in a simple C program.<br><br>Buffering means the program reads in chunks instead of character at a time. This is an attribute of a program, specifically of whatever I/O library it is using. It does not include line editing (you don't generally want to interpret a backspace in a text file you are reading. You *certainly* don't want to interpret control-C or control-D).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Things like backspace *do not live in the program*, unless you are using a library like readline or editline. For most programs, they rely on the tty driver to do this. This is why stty works from the shell, not as instrumentation for whatever program. The default on Unixlikes is line mode (stty icanon), which implements basic line editing and only sends a line to the program when you press Enter or the EOF character (in the middle of a line, this will send the incomplete line; press it a second time, or on an empty line, and the program gets a zero-character read response, which is the standard Unix EOF indication).<br clear="all"><div><br></div><div>In ghc this is complicated by two things:</div><div><br></div><div>- ghci uses haskeline, a readline alternative, so the tty is always in -icanon. Compiled ghc programs do not use haskeline unless specifically written to do so.</div><div><br></div><div>- At some point, the ghc runtime started tweaking termios settings in hSetBuffering. This is incomplete (per the IRC log I mentioned, apparently nothing at all is done with LineBuffering), and causes confusion when multiple ghc-compiled programs are involved (the program starts out in LineBuffering and assumes stty icanon, but whether the tty is in icanon or -icanon depends on what the invoking program did; this is the stack bug I linked).</div><div><br></div><div>On Windows, this works differently; IIRC, whether you see "character mode" or "line mode" depends on which API you use for reads, and line editing indeed lives within the program.</div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh                               sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>                                  <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad        <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div></div>