Characters sometimes (rarely) echoed when using getchar

[Stefan-Code]

Please consider the following example:

from click import getchar
ESC = '\x1b'
i = 0
while True:
    c = getchar()
    i += 1
    if c == ESC:
        print("\n total characters typed:", i)
        exit()

(Press ESC to exit when running it)
When I run this in gnome-terminal under Linux User 3.13.0-37-generic #64-Ubuntu x86_64 x86_64 x86_64 GNU/Linux and randomly smash on the keyboard, the output is similar to the following:

~/Programming/click $ python click-test.py 
dfsjakfh
total characters typed: 205
~/Programming/click-test $ 

I am actually trying to solve this bug in case anyone is wondering why I am smashing on my keyboard ;)
So the problem is that a handful of characters gets printed instead of being catched by getchar(). I also suspect this is because of the nearly simultaneous key presses.
Does anyone know a solution to this problem?

[Stefan-Code]

Please also note that this does not happen with this code:

import os
import sys
import tty
f = open('/dev/tty')
fd = f.fileno()
tty.setraw(fd)
ESC = '\x1b'
i = 0
while True:
    c = os.read(fd, 32)
    #print(c.decode("utf-8"))
    i += 1
    if c.decode("utf-8") == ESC:
        print("total characters typed:", i)
        exit()

Please forgive the crappy example. You will have to reset your terminal after running it and you will not see that you're typing reset while doing so... And it will only work on Linux. Sorry about that.
Could it be the case that all the stuff in the getchar function (especially the terminal configuration for every char) makes it so slow that it can't cope with all the characters coming in?

[untitaker]

It seems it's impossible to fix this race condition without breaking the API.

[Stefan-Code]

Thanks for the quick reply. Do you know what exactly is causing this behaviour? Am I correct with the assumption that tty.setraw(fd) isn't set fast enough again between key presses?

[untitaker]

Yes exactly, but "making it fast enough" is not a good fix. As said in the other issue, setraw should be done and undone only once each to avoid that race condition.

[Stefan-Code]

So introducing something like a function to enable/disable a "raw state" for the length of the desired getchar capture would fix this problem? Do you think that could work without breaking the API?

[untitaker]

Well, if you want to use getchar without experiencing this bug, you'll have to change your code.

Right now you'd write:

while True:
    click.getchar()

To avoid this bug, you'd write:

# hypothetical API
with click.raw_terminal() as x:
    while True:
        x.getchar()

I don't think a bugfix that only changes code in Click is possible.

[Stefan-Code]

Allright, I'll use the solution you suggested over at the other issue for now and maybe look into the details here later if I have some time. Should we close this issue as not fixable in the meantime?

[untitaker]

Let's keep this open.

[Stefan-Code]

@untitaker One more question: Is it intended behaviour that the echo function does only produce a newline and no carriage return? Because this leads to this problem when echoing in raw mode, so it's not possible to stay in raw mode while using echo. Would it break anything to add \r to the echo function?

[untitaker]

That's definetly intentional. Sending \r looks like a workaround to me.

Please open a new issue for that if you think that's an issue Click should be
concerned with.

On Sat, Oct 10, 2015 at 02:53:12PM -0700, Stefan wrote:

@untitaker One more question: Is it intended behaviour that the echo function does only produce a newline and no carriage return? Because this leads to this problem when echoing in raw mode, so it's not possible to stay in raw mode while using echo. Would it break anything to add \r to the echo function?

---

Reply to this email directly or view it on GitHub:
#435 (comment)

[JosiahDub]

Fixed this in #1007