On 1/3/23, Grant Edwards <grant.b.edwa...@gmail.com> wrote: > > That's definitely a better option, but I'm pretty sure I've seen > multiple examples over the decades where fd 0 was used instead. Was > /dev/tty a "recent" enough invention that I would have seen > application code that was written before it existed? Or maybe I was > just looking at code written by people who weren't aware of /dev/tty?
POSIX has required "/dev/tty" for 20 years, or longer. It's in the 2004 edition of the spec, which was a minor update to the 2001 edition. https://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap10.html > No, the whole point is _not_ to write to stdout (which would corrupt > the program's output). The way I remember it was that you wrote the > prompt to fd 0, and then read the password from fd 0. That way it > worked even when fd 1 (stdout) was redirected. It still failed if > stdin was redirected... FYI, that wouldn't work on Windows. The "\\.\CONIN$" and "\\.\CONOUT$" files can be opened with read-write access, but it's for a different purpose. A console input buffer can be read from via read() or WinAPI ReadFile(). It can also be read from using IOCTLs that work with 16-bit wide-character strings, which is the basis of WinAPI ReadConsoleW() and ReadConsoleInputW(). A console input buffer can be *written to* via the IOCTL-based function WriteConsoleInputW(). A console screen buffer can be written to via write() or WinAPI WriteFile(). It can also be written to using IOCTLs that work with 16-bit wide-character strings, which is the basis of WriteConsoleW() and WriteConsoleOutputW(). A console screen buffer can be *read from* via the IOCTL-based function ReadConsoleOutputW(). -- https://mail.python.org/mailman/listinfo/python-list