in reply to Spawned debugger xterms say "sh: 1: 3: Bad file descriptor"
Any ideas?
Read the source!
=head3 C<xterm_get_fork_TTY> This function provides the C<get_fork_TTY> function for X windows. If +a program running under the debugger forks, a new <xterm> window is open +ed and the subsidiary debugger is directed there. The C<open()> call is of particular note here. We have the new C<xterm +> we're spawning route file number 3 to STDOUT, and then execute the C<t +ty> command (which prints the device name of the TTY we'll want to use for + input and output to STDOUT, then C<sleep> for a very long time, routing this + output to file number 3. This way we can simply read from the <XT> filehandle + (which is STDOUT from the I<commands> we ran) to get the TTY we want to use. Only works if C<xterm> is in your path and C<$ENV{DISPLAY}>, etc. are properly set up. =cut sub xterm_get_fork_TTY { ( my $name = $0 ) =~ s,^.*[/\\],,s; open XT, qq[3>&1 xterm -title "Daughter Perl debugger $pids $name" -e sh -c 'tt +y 1>&3;\ sleep 10000000' |]; # Get the output from 'tty' and clean it up a little. my $tty = <XT>; chomp $tty;
The redirections look kosher to me. And it seems likely that they at least used to work. My first guess would be a bug in dash (there have been plenty of those) if your /bin/sh is a link to dash. My second guess is that your version of xterm is closing FD 3 before spawning the requested command.
- tye
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Spawned debugger xterms say "sh: 1: 3: Bad file descriptor" (source)
by jabowery (Beadle) on Aug 11, 2013 at 23:03 UTC |