Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement rudimentary version of module termios #1879

Merged
merged 4 commits into from
Jan 28, 2025

Conversation

BCSharp
Copy link
Member

@BCSharp BCSharp commented Jan 20, 2025

termios — a module for low-level terminal I/O system control. It doesn't do much beside defining a bunch of system-specific constants and a few direct POSIX calls.[1][2] The API is old, so old actually that I think it may be obsolete/unused. Anyone needing to set the baud rate to 300 bytes/second? 6 bits per character? On macOS, for instance, some mandatory but kind of obsolete POSIX flags are defined in the header files, but the syscalls don't support them (or not anymore). However, there are a few things that are still quite useful nowadays and perhaps impossible to perform in any other way in a portable fashion. The two common I have encountered:

  1. Setting the terminal input mode to raw (and back to control-break)
  2. Getting (sometimes also setting) the size of the terminal window (rows, columns)

The implementation of termios in this PR is quite rudimentary, meant primarily to be enough to support module tty from StdLib (and some other 3rd party ones). The constants defined here are the subset what termios from CPython defines. See also #1308

The Constants

I tried to be thorough but did not try to be complete. The constants defined are the ones in use from other modules (that I have noticed), but once a constant or flag was used, I tried to define the remaining ones from the same group, just for completeness (with the exception of the TIOC* codes). This PR comes from my stash some 4 years ago, before we had generate_os_codes.py, so all constants are hand-crafted, not generated. To generate them would be messy anyway, because of a lack of clear naming. Perhaps in the future the TIOC* codes can be generated.

The Functions

This is a mock implementation of termios; it doesn't actually do any syscalls. Instead it emulates the minimal functionality needed by tty by using .NET/IronPython internals, and only for stdin. Now that we have genuine file descriptors implemented, this mock code can be replaced by actual syscalls. This will have to be through P/Invoke, as Mono.Unix does not support the termios API (I saw it marked as TODO in Mono). The calls are simple, but the data structure marshalled not so.

@BCSharp BCSharp marked this pull request as ready for review January 27, 2025 21:45
Copy link
Contributor

@slozier slozier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!



// lflag
public static uint ECHOKE => RuntimeInformation.IsOSPlatform(OSPlatform.OSX) ? 0x0001u : 0x0800u; // visual erase for line kill
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess these will show up as System.UInt32 instead of int in the Python world. Not necessarily a big deal since this module is somewhat obscure, but something to keep in mind...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I was debating which type to use here. The issue with BigInteger is that it is not very efficient at storing values that don't fit in 32 bits. Here, all those constants are flags and are supposed be used as opaque values, evt. to be OR-ed together, not for some complex integer arithmetics (although it would still be OK, IronPython's support for mixed type integer arithmetics and automatic type conversions is quite extensive). The API that accepts them is/will be using long so that it will efficiently capture UIn32 and negative values of In32. Yes, something to keep in mind, though I don't expect it to be a problem.

@BCSharp BCSharp merged commit 0e4b0af into IronLanguages:main Jan 28, 2025
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants