Bug 811483 - perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls
perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
http://www.nntp.perl.org/group/perl.p...
:
Depends On:
Blocks: 807951
  Show dependency treegraph
 
Reported: 2012-04-11 04:50 EDT by xning
Modified: 2012-04-11 08:39 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-11 07:31:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Simple script to test this bug (328 bytes, application/x-perl)
2012-04-11 04:50 EDT, xning
no flags Details

  None (edit)
Description xning 2012-04-11 04:50:16 EDT
Created attachment 576710 [details]
Simple script to test this bug

Description of problem:
perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. download test case in attachment
2. perl -d test.pl
3. 
  
Actual results:
don't open a new xterm window

Expected results:
open a new xterm window

Additional info:
Comment 1 xning 2012-04-11 04:52:18 EDT
On Fedora 16, although environment variable 'TERM' has value 'xterm', xterm isn't
installed. So, when debug scripts which will execute fork(), perl5db.pl will fail
and quit when it executes the following codes, enters line 1493 ~ 1500, because
function xterm_get_fork_TTY need xterm program:

1487 if (not defined &get_fork_TTY)
1488 {
1489     if ( defined $remoteport ) {
1490
1491         *get_fork_TTY = \&socket_get_fork_TTY;
1492     }
1493     elsif (defined $ENV{TERM}
1494
1495         and $ENV{TERM} eq 'xterm'
1496         and defined $ENV{DISPLAY}
1497       )
1498     {
1499         *get_fork_TTY = \&xterm_get_fork_TTY;
1500     }
1501     elsif ( $^O eq 'os2' ) {
1502         *get_fork_TTY = \&os2_get_fork_TTY;
1503     }
1504     elsif ( $^O eq 'darwin'
1505             and defined $ENV{TERM_PROGRAM}
1506             and $ENV{TERM_PROGRAM}
1507                 eq 'Apple_Terminal'
1508             )
1509     {
1510         *get_fork_TTY = \&macosx_get_fork_TTY;
1511     }
1512 } ## end if (not defined &get_fork_TTY...
Comment 2 Petr Pisar 2012-04-11 07:31:35 EDT
How did you come the idea that TERM environment variable carries terminal emulator executable name? The TERM defines type of terminal. Not a binary. What is `VT100' or `linux'?

The current perl debuger code is just an ugly hack which must resolve upstream. Ask Free Desktop project for support in adding portable way how to spawn new terminal (emulator).
Comment 3 xning 2012-04-11 08:39:07 EDT
Good idea. I will.

Note You need to log in before you can comment on or make changes to this bug.