3 ms·
I submitted the proposal for `tcgetwinsize` to POSIX a few years ago. I originally wrote it because I was sick of having to turn off _POSIX_C_SOURCE for just a
by clausecker 2y ago
I submitted the proposal for `tcgetwinsize` to POSIX a few years ago. I originally wrote it because I was sick of having to turn off _POSIX_C_SOURCE for just a single file to get glibc to expose TIOCGWINSZ.
SIGWINCH and the TIOCGWINSZ ioctl() were originally omitted from POSIX as they were considered relevant for windowing systems only and GUI-stuff was considered out of scope for POSIX. Furthermore, POSIX only specifies ioctl() for STREAMS; other interfaces that traditionally use ioctl() calls are specified in POSIX using wrapper functions (which is what the new interface is; it is specified such that you can implement it just by wrapping the traditional TIOCGWINSZ/TIOCSWINSZ ioctl calls).
My original proposal had functions tcgetsize() and tcsetsize(), but it turns out that QNX already uses these identifiers with an incompatible signature, so a last minute change was made to name these tcgetwinsize() and tcsetwinsize().
Furthermore, the winsize structure traditionally also has ws_xpixel and ws_ypixel members indicating the resolution of the terminal. This existed primarily becaus on some historical virtual terminals, a client could change the video mode by calling the TIOCSWINSZ ioctl, providing resolution and row/column count for the desired video mode. While no current virtual terminal known to me supports this, the POSIX spec mandates that if a slave PTY calls tcsetwinsize(), the window size update is propagated to the master, allowing terminal emulators to implement this feature if desired. Another objection raised was that the traditional unsigned short type may be insufficient for future high-definition screens and a resolution may not be well defined for some types of terminals like hardcopy or braille terminals.
I maintain that submitting a feature to POSIX and waiting for a new version of the standard to be released is probably the easiest way to get glibc to implement a feature you want.
- aumerle 2y agoLots of modern terminals support ws_xpixel and ws_ypixel. Hell even the venerable xterm supports it. It is used primarily for displaying raster graphics in modern terminals, see for example: https://sw.kovidgoyal.net/kitty/graphics-protocol/#getting-the-window-size https://sw.kovidgoyal.net/kitty/graphics-protocol/#getting-t... And nowadays modern terminals even support in-band resize notification so there is no need for SIGWINCH: https://gist.github.com/rockorager/e695fb2924d36b2bcf1fff4a3704bd83 https://gist.github.com/rockorager/e695fb2924d36b2bcf1fff4a3...
- clausecker 2y agoMy point was not that the terminals don't report ws_xpixel and ws_ypixel, but rather that none support the application setting the resolution using tcsetwinsize() with the terminal subsequently changing its video mode / resizing itself to the requested size.
- aumerle 2y agoAh yes, in that case there no terminals that implement it indeed. Though there are a few that implement changing window size via escape code, though in units of cells not pixels. Generally speaking I dont see how applications can use tcsetwinsize() robustly, given that the size in pixels of a cell is determined by font properties and applications runing in the terminal have no knowledge of these, therefore cannot set both the pixel and cell sizes at the same time.
- clausecker 2y agoCorrect, that was one of the concerns. Note that tcsetwinsize() is mainly provided so that the pty master (i.e. the terminal emulator) can set the window size to be seen by the slave (i.e. the application running in the emulated terminal). The other direction is not explicitly banned though.
- j4_james 2y agoFYI, there are a few terminals that can set the window size in pixels (with `CSI 4 t`). And it's also worth mentioning that there were already terminal emulators back in the 1980s that supported in-band resize notifications (lookup `VTEEWR` - Enable Window Event Reports).
- high_na_euv 2y ago>tcgetwinsize >_POSIX_C_SOURCE >TIOCGWINSZ >SIGWINCH >TIOCSWINSZ Jesus christ, this whole fashion among the C and linux people focused on writing shorter, but unreadable names is really terrible habbit
- wwalexander 2y agoI believe this stems from C originally only having 8 significant characters for identifiers.
- cesarb 2y agoNot only that, but screen space was really limited back then; it was not uncommon to develop on terminals with as low as 80 columns and 24 lines. Having shorter names meant more of the code could fit on the screen at the same time.
- rbanffy 2y agoThe limited size helps with keeping the code short and simple. ;-)
- kps 2y agoHistorically there was a bifurcation between scientific/technical computing and business computing. The former wanted to write something close to E = mc², while the latter wanted `MULTIPLY MASS-IN-GRAMS TIMES SPEED-OF-LIGHT-IN-A-VACUUM-IN-METERS-PER-SECOND TIMES SPEED-OF-LIGHT-IN-A-VACUUM-IN-METERS-PER-SECOND GIVING ENERGY-IN-JOULES`. With the dotcom boom, the last vestiges of the old republic were finally swept away, and now even C programmers get slapped for writing `c`.
- marssaxman 2y agoI still develop on a terminal with 80 columns, to this day! ...but it has 96 rows, and there are five of them, side by side across my monitor. Definitely an improvement! - but I still prefer not to have long rambling Java-style identifiers.