Skip Menu |

This queue is for tickets about the TermReadKey CPAN distribution.

Report information
The Basics
Id: 120641
Status: new
Priority: 0/
Queue: TermReadKey

Owner: Nobody in particular
Requestors: haarg [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Subject: GetTerminalSize has bizarre failure modes
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Message-ID: <rt-4.0.18-21156-1489749796-1809.0-0-0 [...]>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 796
Download (untitled) / with headers
text/plain 796b
GetTerminalSize tries to use one of GetTermSizeVIO, GetTermSizeGWINSZ, GetTermSizeGSIZE, or GetTermSizeWin32 to get the terminal size. If those don't produce any results, it will fall back to calling `resize` or `stty`. If given a file handle other than STDOUT, using resize or stty would be entirely inappropriate. Additionally, if the file handle isn't connected to a terminal, the initial GetTerm* calls will produce no results. That is the correct value that should be returned, yet it will still fall back to `resize` or `stty`. On some systems a resize call like this will pause for 10 seconds before timing out. I don't think this module should be falling back to `resize` or `stty` at all, but if it is going to, it should only do so if it is checking STDOUT and -t *STDOUT is true.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to