Re: [Bug-apl] Quick Question

[Juergen Sauermann]

Hi Mike, in GNU APL there are some interactions between stdin, stdout, and stderr. And it is doing some terminal handling like disabling cooked mode, signal handling,  and others. These are needed in order to make it work like IBM APL2. A simple pipe will not understand all this. A cleaner approach is to build GNU APL as a library and to provide your own I/O functions. You can then implement the interface to stdin/out/err as you like. /// Jürgen On 08/07/2015 05:16 AM, Mike Duvos wrote: Thanks.  That is an improvement. --rawCIN gets rid of the extra echo of input, but now I don't get the APL indent, which is somewhat uncosmetic. Regards Mike On Thu, Aug 6, 2015 at 8:08 PM, Elias Mårtenson <loke...@gmail.com> wrote: You might want to try to use the --rawCIN flag. Regards, Elias On 7 Aug 2015 11:04, "Mike Duvos" <m...@wolf359.net> wrote: In Cygwin, I set up GNU APL as a server I could connect to by doing the following. mkfifo /tmp/pipe cat /tmp/pipe |apl --noColor 2>&1 | nc -l 127.0.0.1 9999 > /tmp/pipe Now if I connect to this, GNU APL comes up, but it exhibits a rather odd echoing of my input where it prints the first character, five spaces, and then the rest of the input, before printing the output.  Like this...       1 2 3 4 5 1       2 3 4 5 1 2 3 4 5       'this is a test' '      this is a test' this is a test The odd thing is that it doesn't do this if I make the program I am redirecting a shell, or some C program that reads and writes stdio.  It only happens when I do it with GNU APL.  While I'm not suggesting this is a bug, I was wondering if anyone could suggest an explanation of this unexpected behavior.  Is there something uncommon about the way GNU APL reads and writes stdio? -- Mike Duvos m...@wolf359.net