> One thing that stands out is the call to ioctl - I have no idea why this is happening and it also appears to be causing an error. As far as I understand, the ioctl call signifies that the program is trying to do a terminal control operation. Dunno.
It's not an error, per se. (The ioctl is literally erroring, but that's an expected possibility for the calling code, and it handles that.)
The reason there's an ioctl is documented in the docs for `open`:
> buffering is an optional integer used to set the buffering policy. Pass 0 to switch buffering off (only allowed in binary mode), 1 to select line buffering (only usable in text mode), and an integer > 1 to indicate the size in bytes of a fixed-size chunk buffer.
You're not passing the `buffering` arg, so the subsequent text applies:
> When no buffering argument is given, the default buffering policy works as follows:
> * Binary files are buffered in fixed-size chunks; […]
(That doesn't apply, as you're not opening the file in binary mode, so it's the next bullet that applies)
> * Interactive” text files (files for which isatty() returns True) use line buffering. Other text files use the policy described above for binary files.
That ioctl is the underlying syscall that isatty() is calling. It's determining if the opened file is a TTY, or not. The file isn't a TTY, so the ioctl returns an error, but to our code that just means that "no, that isn't a TTY". (And thus, your opened file will automatically end up buffered. The flow here is a good default, for each of the cases it is sussing out.)
It's not an error, per se. (The ioctl is literally erroring, but that's an expected possibility for the calling code, and it handles that.)
The reason there's an ioctl is documented in the docs for `open`:
> buffering is an optional integer used to set the buffering policy. Pass 0 to switch buffering off (only allowed in binary mode), 1 to select line buffering (only usable in text mode), and an integer > 1 to indicate the size in bytes of a fixed-size chunk buffer.
You're not passing the `buffering` arg, so the subsequent text applies:
> When no buffering argument is given, the default buffering policy works as follows:
> * Binary files are buffered in fixed-size chunks; […]
(That doesn't apply, as you're not opening the file in binary mode, so it's the next bullet that applies)
> * Interactive” text files (files for which isatty() returns True) use line buffering. Other text files use the policy described above for binary files.
That ioctl is the underlying syscall that isatty() is calling. It's determining if the opened file is a TTY, or not. The file isn't a TTY, so the ioctl returns an error, but to our code that just means that "no, that isn't a TTY". (And thus, your opened file will automatically end up buffered. The flow here is a good default, for each of the cases it is sussing out.)