Основная сторона pty читает дополнительные \r\n после каждой записи в macOS
У меня есть скрипт Python, который pty.fork() s xterm -S/1 (задокументировано как -Sccn). Это должно позволить мне отладить его в IDE, консоль которого в противном случае не смогла бы обработать все управляющие символы.
И действительно, когда дело доходит до отображения результатов, все работает отлично. Тем не менее, для сценария всегда выглядит так, как будто пользователь спам Enter ключ в xterm окно. Реальные нажатия клавиш также принимаются, но смешиваются с фальшивыми Enter s.
Я проверил с dtruss и вот как это выглядит с точки зрения системного вызова:
read(0x5, "3\0", 0x1) = 1 0
write_nocancel(0x5, "/censored/ prompt> 3/censored/\0", 0x61) = 97 0
read(0x5, "\r\0", 0x1) = 1 0
read(0x5, "\n\0", 0x1) = 1 0
Первый read() соответствует мне нажатия 3, что правильно. Затем скрипт обновляет графический интерфейс, что тоже правильно. Тем не менее, тогда он получает фальшивку \r\n, которые интерпретируются как нажатия клавиш. Это не xterm сторона, которая отправляет их:
write(0x1, "3\0", 0x1) = 1 0
read(0x1, "/censored/ prompt> 3/censored/\0", 0x1000) = 96 0
Так что я думаю, что это что-то внутри macOS, которое внедряет эти символы - может быть, какой-то механизм подтверждения? Было бы здорово узнать, что вызывает эти дополнительные \r\n появиться, и как либо убедиться, что он больше этого не делает, либо заставить скрипт обрабатывать их изящно.
Обновление: это должно быть проблемой при взаимодействии с urwid "s raw_display, поскольку curses_display вариант отлично работает. Я загрузил текущую версию скрипта на GitHub. Следующее работает отлично:
via-xterm urwid/examples/input_test.py
и следующее показывает проблему:
via-xterm urwid/examples/input_test.py r
Обновление 2: после некоторых проб и ошибок я обнаружил, что очистка IEXTEN бит решает проблему. Тем не менее, у меня нет объяснения, почему это работает.