PTY rows/cols increased #2806
PTY rows/cols increased #2806
Conversation
Previously unspecified, which generally led to a default of 80x24. This meant that programs which default to using a pager (e.g. less/more) for long output, lines would be truncated at 80 characters, and showing more than ~24 lines of text would often result in a blocking prompt to show more. Increasing the cols by 2x and rows/lines by ~4x seems reasonable, it comes _closer_ to matching actual modern terminal window sizes, shows longer lines, and is less likely to trigger a blocking pager. Perhaps larger values would be good, especially for Rows. This doesn't fundamentally solve the issue, but perhaps reduces the likelihood and impact of pager interference.
|
A slightly more compelling before/after, where I emulate a command producing 30 lines of output through a pager ( Pipeline: steps:
- command:
- tput cols
- tput lines
- seq 30 | less -F
timeout_in_minutes: 1❌ Before: 
✅ After: 
|
|
Thinking a bit more about the right number of rows to claim, I have two ideas: The terminal output of a modern CLI command will likely be designed around the assumption it's being viewed in a modern terminal emulator on a modern display. Mine at fullscreen on a 27" monitor shows about 90 lines. Obviously a smaller window, or a pane in an editor/IDE is likely to show less, but I think 100 lines is a reasonable size to claim; it's generous enough to avoid pager for any output that would normally fit on a real screen, but not so large/rare/unrealistic as to trigger any edge-cases. The Buildkite user interface when showing the log for a build job shows roughly 80 lines of terminal output on my display. This also feels to me like it ~lines up with the 100 line display claimed by this PR. So, I'm feeling pretty good about 100 lines, as opposed to increasing it to e.g. 1,000 or more. |
The size of the fake PTY allocated to build jobs was previously unspecified, which generally led to a default of 80x24. That meant programs which checked the size of the terminal would assume it was very small, and that programs which default to using a pager (e.g. less/more) for long output, lines would be truncated at 80 characters, and showing more than ~24 lines of text would often result in a blocking prompt to show more.
Increasing the cols by 2x and rows/lines by ~4x seems reasonable, it comes closer to matching actual modern terminal window sizes, shows longer lines, and is less likely to trigger a blocking pager. Perhaps larger values would be good, especially for Rows. Maybe there's no harm and some upside to e.g. 1,000 rows?
This doesn't fundamentally solve the issue, but perhaps reduces the likelihood and impact of pager interference.
Before & after: