Re: [Bug-apl] Seeking clues regarding quote-quad prompt

[Juergen Sauermann]

Hi David, this could be caused by how the input echo is implemented. If you look at CinOut::overflow(int c) then you will see that the echo of GNU APL input is sent to cerr rather than to cout. The reason was, as far as i remember, that when you pipe the APL output into something - say an HTML script - then you normally don't want to see it mixed with echo of the script. So we have, I believe: CIN (input echo) → cerr CERR → cerr UERR → cerr COUT→ cout /// Jürgen On 08/24/2014 07:12 AM, David B. Lamkins wrote: Back on the subject of aplwrap integration: I'm seeing a GNU APL behavior that I don't understand, and would appreciate some hints on where to look. I don't necessarily consider the following behavior to be buggy, I just want to be able to figure out how and why it's happening so I can dig into the code. Quick background: aplwrap spawns GNU APL with pipes for stdin, stdout and stderr. Pretty much everything works as expected, except for some puzzling behavior w.r.t. a ⍞ prompt followed by a ⍞ input. What I'm seeing (by dumping stdout and stderr) is that the prompt is showing up on both stdout and stderr. >From what I've been able to read so far, I think this is how it happens: With --rawCIN, get_user_line() calls no_readline() with the prompt text. no_readline() then ungetc()s the entire prompt so it'll be available for ⍞ input. I think that aplwrap must see the pushed-back prompt and echo it to stdout. That's fine. I can deal with that. But then almost the same prompt appears on stderr. I can't figure out how that happens. I say "almost the same" because the prompt text on stderr may have pad characters in place of blanks, assuming that the prompt used a nested vector. For that reason, I'm convinced that aplwrap isn't somehow involved; the stderr prompt must from GNU APL. What I can't understand is how the ⍞ prompt *ever* shows up on stderr. >From what I've read, it looks like the prompt always goes to COUT. Clues will be much appreciated...