Re: Spawned debugger xterms say "sh: 1: 3: Bad file descriptor" (source)

[tye]

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.

[jabowery]

Indeed, sh is linked to dash:

$ ls -al `which sh`
lrwxrwxrwx 1 root root 4 Mar  1  2012 /bin/sh -> dash

Actually, I don't need all these forked debuggers opening up since I'm not debugging the (trivial) forked processes. (UPDATE: I discovered that  DB<1> undef $DB::inhibit_exit allows me to do this.)

I suppose I could go into the source and change it to use bash instead of dash (in the guise of sh) and see if that at least forks working debuggers.