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...
