<rumpelsepp>
I have a noob question according to (again) OSC52. This time I am struggling with pasting. How is reading the answer from the terminal supposed to work? When I try to read the answer, read() is stuck in reading from the keyboard, if I read a second time the answer from the terminal is read.
<rumpelsepp>
I'll put together a python snippet, one second.
<rumpelsepp>
The first f.read() is stuck until I press ctrl+d; the second one catches the OSC52 response (and a few newlines until I press ctrl+d again).
<rumpelsepp>
What am I doing wrong? Second question: Is it better to use /dev/tty for this OSC stuff or just stick to stdin/stdout? The former cannot by redirected while the latter is easier to debug.
<dnkl>
rumpelsepp: I don't see anything obvious wrong. Let me experiment a bit when I get to the office
<dnkl>
/dev/tty is definitely the right thing to use though
<dnkl>
armin: terminal emulators can be very personal, for sure :)
<dnkl>
I wouldn't hold my breath for clickable URLs. I understand it would make foot more "accessable" to new users. But that in itself isn't something we strive for
<dnkl>
rumpelsepp: hmm, could be your query isn't flushed? You want to make sure line buffering is disabled.
<dnkl>
But printing a newline after your query would be an easy way to test if buffering is the problem
<rumpelsepp>
It should be flushed, since I am writing to stdout directly. Let me verify.
<rumpelsepp>
Think you nailed it. strace revealed it… Thanks, I was searching at the wrong front…
<dnkl>
rumpelsepp: yeah... Stdout *is* line buffered by default (unless redirected)
<rumpelsepp>
yeah, you're right. I thought it is disabled in this .buffer. thing in python.
<dnkl>
rumpelsepp: probably better to write directly to /dev/tty
<rumpelsepp>
yeah… Thank you for the heads up according line buffering! :)