I don't understand the issue. How and when the EOF keyboard shortcut is not CTRL+d? Can it be configured? + # Add 64 to get the ASCII character. + eof_char = chr(ord(eof_num) + 64) I don't understand the trick '\x04' termios.tcgetattr(sys.stdin)[6][termios.VEOF] becomes 'CTRL+D'. Where does the 64 constant come from? To me, '\x04' is the character sent to signal the end of the file.
The existing Python text is uppercase D for Ctrl-D, so I maintained it. stty documentation also uses upper case for control characters. The EOF character can be viewed or set via the stty utility or the tcsetattr() or equivalent routine. Some platforms may not allow setting specific control characters. user@solar:~$ stty susp ^D eof ^Z user@solar:~$ stty speed 38400 baud; line = 0; eof = ^Z; susp = ^D; -brkint -imaxbel Changing the characters can be a matter of personal choice or could be an issue where something in the communications path is intercepting a control character, or the underlying platform may have different characters. Note that Linux has erase=^? and most commercial Unix has erase=^H. The constant 64 is from (ord('A') - 1). The termios.tcgetattr(sys.stdin)[6][termios.VEOF] returns the byte for the current EOF character. From the samme session above where I swapped susp and eof >>> print("Ctrl-%s" % chr(ord(termios.tcgetattr(sys.stdin[6[termios.VEOF]) + 64)) Ctrl-Z I was unable to find a symbolic constant for the array element[6] which has contains that control characters. Existing code found on the web just used [6], which can be derived from looking at documentation for the C library tcgetattr. An alternative would be always to to try termios.tcgetattr() before and only fall back to the default EOF character for a platform if that does not work.
