Bug 811483

Summary: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls
Product: [Fedora] Fedora Reporter: Xibo Ning <xning>
Component: perlAssignee: Marcela Mašláňová <mmaslano>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: cweyl, iarnell, kasal, lkundrak, mmaslano, ppisar, psabata, rc040203, tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: http://www.nntp.perl.org/group/perl.perl5.porters/2012/04/msg185375.html
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-11 11:31:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 807951    
Attachments:
Description Flags
Simple script to test this bug none

Description Xibo Ning 2012-04-11 08:50:16 UTC
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 Xibo Ning 2012-04-11 08:52:18 UTC
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 11:31:35 UTC
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 Xibo Ning 2012-04-11 12:39:07 UTC
Good idea. I will.