[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-apl] Seeking clues regarding quote-quad prompt
From: |
David B. Lamkins |
Subject: |
[Bug-apl] Seeking clues regarding quote-quad prompt |
Date: |
Sat, 23 Aug 2014 22:12:39 -0700 |
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...
- [Bug-apl] Seeking clues regarding quote-quad prompt,
David B. Lamkins <=