It looks to me like "perl -d" has a terminal in the above scenario. And, no, "perl -d" does not expect/require that STDIN nor STDOUT be terminals. The default Perl debugger opens its own handles for input and output to "the terminal" (by opening "/dev/tty" or "con:" or such) which means it doesn't mind if at least some of STDIN, STDOUT, and STDERR are redirected. My guess is that "/dev/tty" doesn't "work" when all three of those handles are redirected while "con:" works even if all three are redirected. In the above example, it appears to me that STDIN is still connected to the tty (as is STDERR but not STDOUT).
It is unfortunate that Term::ReadKey::GetTerminalSize() destroys any evidence about why most of the listed attempts failed. Doing a little debugging of the debugger's start-up in order to recover exactly why each of the attempts failed seems the obvious next step. An easy way to do that is simply to edit ReadKey.pm to correct its silence.
It looks to me like this is a bug in the Perl debugger that wasn't there last time I worked on it. I certainly noticed this type of complaint a lot after some upgrade (likely perl 5.6 or 5.6.1) and have succeeded in mostly ignoring it.
My testing of the example invocation on a Unix system shows that, despite all of the code to the contrary, GetTerminalSize() is trying to get the terminal size of STDOUT (which isn't a terminal).
The crux of the problem is that $readline::term_OUT isn't being set to $DB::OUT despite $IN and $OUT being passed in $term = new Term::ReadLine 'perldb', $IN, $OUT;
|