Menu
▾
▴
#393 Can't read NUL, BEL, BS and DEL from stdin
echo -e 'foo\abar' | joe -
Expected: the BEL (0x07) character is preserved, just as if I did
echo -e 'foo\abar' > /tmp/foo
joe /tmp/foo
Actual: the BEL character is dropped, the edit buffer contains "foobar".
Similarly the NUL (0x00) character is also dropped, while BS (0x08) and DEL (0x7F) remove the previous byte from the buffer rather than appearing as themselves.
This is fixed in the latest check-in. Note that you will also get the CR (0x0D) from the echo because there is no '-n'.
I'm wondering if there should be an option to enable the old way.. perhaps there are cases where we want CR translated to LF on input.
So when you pipe data into JOE, it runs '/bin/sh -c /bin/cat' as a background process to read the data from pipe.
This allows the editor to run in case you do something like this:
while true; do echo hi; sleep 1; done | joe
It also allows you to kill the pipe with Ctrl-C (but you have to move cursor off of last line of buffer).
I'm not sure I get the CR story. "echo" doesn't add this character, it only adds a LF because there's no "-n".
It's either "joe" adding it explicitly, or there's a tty involved which does an [io]crnl or [io]nlcr thingy... or anything else?
The "while true; ..." example is indeed a nice one, a functionality I wasn't aware of. I'm wondering, is there a way to retain this functionality, and at the same time make reading from stdin absolutely binary safe?
Thanks!
On a side note, while doing this:
while true; do echo hi; sleep 1; done | joe
pressing Ctrl+C asks "Kill program?" iif the cursor has been moved back to an earlier position in the file. If the cursor is at the last (default) position, it inserts a literal "^C". Is this intentional? Being new to this feature, it has confused me. :)
Oh yeah, what am I talking about. It's going though a tty/pty pair and onlcr is set. I'll continue to work on it since I agree this should be binary safe.
The Ctrl-C you see is another bug.
Well, if there's a tty involved then I honestly don't know if it can be made binary safe.
Maybe it can, it's just cumbersome. You've just fixed it for NUL and a few others, maybe only CR-LF to go using those bunch of relevant stty settings. Fingers crossed :)
It's now fixed.
The easiest fix was to use a pipe instead of tty/pty pair. (tty/pty can be binary safe by disabling opost, but it's a pain to mess with the termio settings). Also I lied about running /bin/cat- it did not do this. I was misled by some old code (now deleted).
Awesome, thanks a lot!