Mailing List Archive: Perl: porters

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

Index | Next | Previous | View Threaded

xning at redhat

Apr 9, 2012, 3:08 AM

Post #1 of 15 (170 views)
Permalink

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

Hi,
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...

I also think it's better for perl5db.pl to support linux current
terminal emulation applications, so I make a patch. I have test the
patch on gnome (ubuntu 10.04, Fedora 16), kde (opensuse 12), xfce
(xubuntu 10.04.2), and lxde (mint 12). The patch works well.

The patch makes perl5db.pl support gnome-terminal, konsole,
xfce4-terminal, terminal (xfce), lxterminal, and xterm in linux system.
So, xterm becomes one of the terminal emulation applications supported
in linux system, not the only one as before.

How to reproduce the problem? Rename xterm or move it to other
directory, then debug a script that will execute fork() function.

I put a test case and the patch in attachments. And perlbug collects
some information as follows, hope it's helpful.

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=medium
---
This perlbug was built using Perl 5.14.2 in the Fedora build system.
It is being executed now by Perl 5.14.2 - Thu Feb 23 10:37:48 UTC 2012.

Site configuration information for perl 5.14.2:

Configured by Red Hat, Inc. at Thu Feb 23 10:37:48 UTC 2012.

Summary of my perl5 (revision 5 version 14 subversion 2) configuration:

Platform:
osname=linux, osvers=2.6.32-220.4.1.el6.x86_64,
archname=x86_64-linux-thread-multi
uname='linux x86-05.phx2.fedoraproject.org
2.6.32-220.4.1.el6.x86_64 #1 smp thu jan 19 14:50:54 est 2012 x86_64
x86_64 x86_64 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-Dccdlflags=-Wl,--enable-new-dtags -DDEBUGGING=-g -Dversion=5.14.2
-Dmyhostname=localhost -Dperladmin=root [at] localhos -Dcc=gcc -Dcf_by=Red
Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local
-Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5
-Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl
-Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl
-Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64
/usr/lib64 -Duseshrplib -Dusethreads -Duseithreads
-Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db
-Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
-Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly
-Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto
-Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto
-Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing
-pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.6.2 20111027 (Red Hat 4.6.2-1)',
gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -fstack-protector'
libpth=/usr/local/lib64 /lib64 /usr/lib64
libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread
-lc -lgdbm_compat
perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.14.90'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef,
ccdlflags='-Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic'

Locally applied patches:

---
@INC for perl 5.14.2:
/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5
.

---
Environment for perl 5.14.2:
HOME=/home/tsllst
LANG=en_US.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)

PATH=/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/tsllst/.local/bin:/home/tsllst/bin
PERL_BADLANG (unset)
SHELL=/bin/bash

Attachments:

perl5db.pl-linux.patch (5.27 KB)

test.pl (0.32 KB)

tony at develop-help

Apr 9, 2012, 4:42 PM

Post #2 of 15 (164 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

On Mon, Apr 09, 2012 at 06:08:57PM +0800, Xibo Ning wrote:
> Hi,
> 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:
>
...
>
> I also think it's better for perl5db.pl to support linux current
> terminal emulation applications, so I make a patch. I have test the
> patch on gnome (ubuntu 10.04, Fedora 16), kde (opensuse 12), xfce
> (xubuntu 10.04.2), and lxde (mint 12). The patch works well.
>
> The patch makes perl5db.pl support gnome-terminal, konsole,
> xfce4-terminal, terminal (xfce), lxterminal, and xterm in linux
> system. So, xterm becomes one of the terminal emulation applications
> supported in linux system, not the only one as before.
>
> How to reproduce the problem? Rename xterm or move it to other
> directory, then debug a script that will execute fork() function.
>
> I put a test case and the patch in attachments. And perlbug collects
> some information as follows, hope it's helpful.
...
> + elsif ( $^O eq 'linux' # If this is Linux
> + and defined $ENV{DISPLAY} # and what display it's on,
> + )
> + {
> + *get_fork_TTY = \&linux_get_fork_TTY; # use the linux version
> + }
...
> + my $tempfile = qq[perl5db-$$-$id];
> + do {
> + $tempfile .= q[-];
> + $tempfile .= int 10**12 * rand;
> + } while ( -e qq[/tmp/$tempfile] );
> + system( q[touch], qq[/tmp/$tempfile] );

This is probably a race condition, though difficult to take advantage
of.

...
> + my %terminals = (
> + q[gnome-terminal] =>
> + qq[gnome-terminal -e 'sh -c "$cmd"' --window --title "$title" |],
> + q[konsole] => qq[konsole --title "$title" -e sh -c '$cmd' |],
> + q[xfce4-terminal] => qq[xfce4-terminal --title "$title" -e 'sh -c "$cmd"' |],
> + q[terminal] => qq[terminal --title "$title" -e 'sh -c "$cmd"' |],
> + q[lxterminal] => qq[lxterminal --title "$title" -e 'sh -c "$cmd"' |],
> + q[xterm] => qq[xterm -title "$title" -e 'sh -c "$cmd"' |],
> + );
> + my $support_terms = join qq[\n], sort keys %terminals;
> + for my $emul ( sort keys %terminals ) {
> + if ( which $emul) {
> + open XT, qq[$terminals{$emul}];
> +
> + # Get the output from 'tty' and clean it up a little.
> + # We need wait a while before tty command outputs result to $tempfile
> + sleep 1 while ( -z qq[/tmp/$tempfile] );
> + open TEMP_HANDLE, qq[/tmp/$tempfile];
> + unlink qq[/tmp/$tempfile];
> + my $tty = <TEMP_HANDLE>;
> + close TEMP_HANDLE;
> + chomp $tty;
> + $pidprompt = ''; # Shown anyway in titlebar
> + # We need $term defined or we can not switch to the newly
> + # created a new terminal window or tab
> +
> + if ( $tty ne '' && !defined $term ) {
> + require Term::ReadLine;
> + if ( !$rl ) {
> + $term = Term::ReadLine::Stub->new( 'perldb', $IN, $OUT );
> + }
> + else {
> + $term = Term::ReadLine->new( 'perldb', $IN, $OUT );
> + }
> + }
> +
> + # There's our new TTY.
> + return $tty;
> + }
> + }

My main problem with this change is that if I happen to have
gnome-terminal installed (which I use, but rarely), it's going to
start that instead of my preferred xterm. I'm not given a choice.

None of those terminal programs aren't Linux specific, as far as I'm
aware.

Also, please send perlbug reports to the perlbug address, so they can
be tracked by Request Tracker.

Tony

mcmahon at ibiblio

Apr 9, 2012, 9:31 PM

Post #3 of 15 (160 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

On Mon, Apr 9, 2012 at 4:42 PM, Tony Cook <tony [at] develop-help> wrote:

>
> My main problem with this change is that if I happen to have
> gnome-terminal installed (which I use, but rarely), it's going to
> start that instead of my preferred xterm. I'm not given a choice.
>
Simple enough - just pick an order as the default (start with xterm; beyond
that it's arbitrary) and then add an option setting to pick a preferred
order. I don't have any spare cycles at the moment to add this, but the
internal docs should make it reasonably easy to do, Xibo.

>
> None of those terminal programs aren't Linux specific, as far as I'm
> aware.
>
Tony, did you mean "all of those programs are Linux-specific" or that they
aren't? Were you thinking that this should cover FreeBSD/OpenBSD/other Unix
as well?

tony at develop-help

Apr 9, 2012, 10:07 PM

Post #4 of 15 (161 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

On Mon, Apr 09, 2012 at 09:31:12PM -0700, Joe McMahon wrote:
> On Mon, Apr 9, 2012 at 4:42 PM, Tony Cook <tony [at] develop-help> wrote:
>
> >
> > My main problem with this change is that if I happen to have
> > gnome-terminal installed (which I use, but rarely), it's going to
> > start that instead of my preferred xterm. I'm not given a choice.
> >
> Simple enough - just pick an order as the default (start with xterm; beyond
> that it's arbitrary) and then add an option setting to pick a preferred
> order. I don't have any spare cycles at the moment to add this, but the
> internal docs should make it reasonably easy to do, Xibo.
>
> >
> > None of those terminal programs aren't Linux specific, as far as I'm
> > aware.
> >
> Tony, did you mean "all of those programs are Linux-specific" or that they
> aren't? Were you thinking that this should cover FreeBSD/OpenBSD/other Unix
> as well?

Urk, double negative.

I believe they can all run on operating systems other than Linux.

And yes.

I plan to fill it out to make the terminal selectable - assuming I
remember.

If it were in RT I'd track it there, now it's buried in the mess that
is my inbox.

Tony

xning at redhat

Apr 10, 2012, 5:01 AM

Post #5 of 15 (161 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

On 04/10/2012 12:31 PM, Joe McMahon wrote:
>
>
> On Mon, Apr 9, 2012 at 4:42 PM, Tony Cook <tony [at] develop-help
> <mailto:tony [at] develop-help>> wrote:
>
>
> My main problem with this change is that if I happen to have
> gnome-terminal installed (which I use, but rarely), it's going to
> start that instead of my preferred xterm. I'm not given a choice.
>
> Simple enough - just pick an order as the default (start with xterm;
> beyond that it's arbitrary) and then add an option setting to pick a
> preferred order. I don't have any spare cycles at the moment to add
> this, but the internal docs should make it reasonably easy to do, Xibo.
>
>
> None of those terminal programs aren't Linux specific, as far as I'm
> aware.
>
> Tony, did you mean "all of those programs are Linux-specific" or that
> they aren't? Were you thinking that this should cover
> FreeBSD/OpenBSD/other Unix as well?

Hi,
Thanks, Joe and Tony.

I have submitted a bug using perlbug, but don't receive replay, so no
bug number now. I have change the patch, reference your advice. Pls
check. Thanks a lot.

Attachments:

perl5db.pl-unix.patch (7.17 KB)

test.pl (0.32 KB)

xning at redhat

Apr 10, 2012, 7:08 PM

Post #6 of 15 (160 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

On 04/10/2012 08:01 PM, Xibo Ning wrote:
> On 04/10/2012 12:31 PM, Joe McMahon wrote:
>>
>>
>> On Mon, Apr 9, 2012 at 4:42 PM, Tony Cook <tony [at] develop-help
>> <mailto:tony [at] develop-help>> wrote:
>>
>>
>> My main problem with this change is that if I happen to have
>> gnome-terminal installed (which I use, but rarely), it's going to
>> start that instead of my preferred xterm. I'm not given a choice.
>>
>> Simple enough - just pick an order as the default (start with xterm;
>> beyond that it's arbitrary) and then add an option setting to pick a
>> preferred order. I don't have any spare cycles at the moment to add
>> this, but the internal docs should make it reasonably easy to do, Xibo.
>>
>>
>> None of those terminal programs aren't Linux specific, as far as I'm
>> aware.
>>
>> Tony, did you mean "all of those programs are Linux-specific" or that
>> they aren't? Were you thinking that this should cover
>> FreeBSD/OpenBSD/other Unix as well?
>
> Hi,
> Thanks, Joe and Tony.
>
> I have submitted a bug using perlbug, but don't receive replay, so no
> bug number now. I have change the patch, reference your advice. Pls
> check. Thanks a lot.

Create a ticket, #112382, the url is:
https://rt.perl.org/rt3//Public/Bug/Display.html?id=112382

Update the patch, to support if xterm exists, then use it; if xterm
doesn't exist, then try terminal emulation applications one bye one, use
the first application that we find.

I have test on linux system, the ForkTerm option works well.

Attachments:

perl5db.pl-unix.patch (7.46 KB)

craig.a.berry at gmail

Apr 10, 2012, 8:05 PM

Post #7 of 15 (163 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

On Tue, Apr 10, 2012 at 9:08 PM, Xibo Ning <xning [at] redhat> wrote:
> if xterm exists, then use it; if xterm doesn't
> exist, then try terminal emulation applications one bye one

*All* terminal emulation applications? Does it support TeraTerm,
PuTTY, Reflection, DECTerm, Apple Terminal, iTerm2, GLTerm, and the
various Java- and Javascript-based emulators that run in a browser, to
mention only the ones I've used recently? Does it support starting
these applications under all the different shells and command-line
interfaces where commands to start them may be found? Does it support
actual, physical VT520 terminals?

If the answer to any of these things is no, I'm fine with that. I
don't think the Perl debugger should have intimate knowledge of
anything but Perl. Hard-coded information about specific devices and
how to use them in specific environments is highly susceptible to bit
rot and maintainability problems. We probably shouldn't have such
things in the Perl debugger and we certainly shouldn't add any more.

xning at redhat

Apr 10, 2012, 10:03 PM

Post #8 of 15 (164 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

On 04/11/2012 11:05 AM, Craig A. Berry wrote:
> On Tue, Apr 10, 2012 at 9:08 PM, Xibo Ning<xning [at] redhat> wrote:
>> if xterm exists, then use it; if xterm doesn't
>> exist, then try terminal emulation applications one bye one
>
> *All* terminal emulation applications?Does it support TeraTerm,
> PuTTY, Reflection, DECTerm, Apple Terminal, iTerm2, GLTerm, and the
> various Java- and Javascript-based emulators that run in a browser, to
No. I think it's ok to support the most common terminal emulation
applications. I select the terminal emulation applications of most
common desktop environments: gnome, kde, xfce, and lxde. And easily
extend, need add terminal emulation applications to %terminals.
> mention only the ones I've used recently? Does it support starting
> these applications under all the different shells and command-line
> interfaces where commands to start them may be found? Does it support
> actual, physical VT520 terminals?
These terminal emulation applications are graphical interface. Before
this patch, perl5db.pl support xterm only, it did not support physical
VT520 terminals also. The command line to start these terminal emulation
applications is simple, it runs well in common/standare 'sh' shell.
>
> If the answer to any of these things is no, I'm fine with that. I
> don't think the Perl debugger should have intimate knowledge of
> anything but Perl. Hard-coded information about specific devices and
> how to use them in specific environments is highly susceptible to bit
> rot and maintainability problems. We probably shouldn't have such
> things in the Perl debugger and we certainly shouldn't add any more.
I think it's better to make perl5db.pl could support current terminal
emulation applications, perl is a current language, not an old one. When
debug a script that executes fork() call, perl5db.pl need open a new
terminal and redirect to the new terminal. So, debugger need knowledge
outside perl. All debugger need knowledge in a function. Craig, do you
think we make debugger get these information by environment variables or
rc files?

Thanks, Craig.

xning at redhat

Apr 10, 2012, 10:22 PM

Post #9 of 15 (161 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

On 04/11/2012 01:03 PM, Xibo Ning wrote:
> On 04/11/2012 11:05 AM, Craig A. Berry wrote:
>> On Tue, Apr 10, 2012 at 9:08 PM, Xibo Ning<xning [at] redhat> wrote:
>>> if xterm exists, then use it; if xterm doesn't
>>> exist, then try terminal emulation applications one bye one
>>
>> *All* terminal emulation applications?Does it support TeraTerm,
>> PuTTY, Reflection, DECTerm, Apple Terminal, iTerm2, GLTerm, and the
>> various Java- and Javascript-based emulators that run in a browser, to
> No. I think it's ok to support the most common terminal emulation
> applications. I select the terminal emulation applications of most
> common desktop environments: gnome, kde, xfce, and lxde. And easily
> extend, need add terminal emulation applications to %terminals.
>> mention only the ones I've used recently? Does it support starting
>> these applications under all the different shells and command-line
>> interfaces where commands to start them may be found? Does it support
>> actual, physical VT520 terminals?
> These terminal emulation applications are graphical interface. Before
> this patch, perl5db.pl support xterm only, it did not support physical
> VT520 terminals also. The command line to start these terminal emulation
> applications is simple, it runs well in common/standare 'sh' shell.
>>
>> If the answer to any of these things is no, I'm fine with that. I
>> don't think the Perl debugger should have intimate knowledge of
>> anything but Perl. Hard-coded information about specific devices and
>> how to use them in specific environments is highly susceptible to bit
>> rot and maintainability problems. We probably shouldn't have such
>> things in the Perl debugger and we certainly shouldn't add any more.
> I think it's better to make perl5db.pl could support current terminal
> emulation applications, perl is a current language, not an old one. When
> debug a script that executes fork() call, perl5db.pl need open a new
> terminal and redirect to the new terminal. So, debugger need knowledge
> outside perl. All debugger need knowledge in a function. Craig, do you
> think we make debugger get these information by environment variables or
> rc files?
>
> Thanks, Craig.
My patch only add support for new common terminal emulation applications
and keep compatability. And only replace xterm_get_fork_TTY with
unix_get_fork_TTY.

vadim.konovalov at alcatel-lucent

Apr 10, 2012, 11:17 PM

Post #10 of 15 (162 views)
Permalink

RE: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

> From: Craig A. Berry

> On Tue, Apr 10, 2012 at 9:08 PM, Xibo Ning <xning [at] redhat> wrote:
> > if xterm exists, then use it; if xterm doesn't
> > exist, then try terminal emulation applications one bye one
>
> *All* terminal emulation applications? Does it support TeraTerm,
> PuTTY, Reflection, DECTerm, Apple Terminal, iTerm2, GLTerm, and the
> various Java- and Javascript-based emulators that run in a browser, to
> mention only the ones I've used recently? Does it support starting
> these applications under all the different shells and command-line
> interfaces where commands to start them may be found? Does it support
> actual, physical VT520 terminals?
>
> If the answer to any of these things is no, I'm fine with that. I
> don't think the Perl debugger should have intimate knowledge of
> anything but Perl. Hard-coded information about specific devices and
> how to use them in specific environments is highly susceptible to bit
> rot and maintainability problems. We probably shouldn't have such
> things in the Perl debugger and we certainly shouldn't add any more.

+1, this is very true.

Regards,
Vadim.

xning at redhat

Apr 10, 2012, 11:54 PM

Post #11 of 15 (162 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

On 04/11/2012 02:17 PM, Konovalov, Vadim (Vadim)** CTR ** wrote:
>> From: Craig A. Berry
>
>> On Tue, Apr 10, 2012 at 9:08 PM, Xibo Ning<xning [at] redhat> wrote:
>>> if xterm exists, then use it; if xterm doesn't
>>> exist, then try terminal emulation applications one bye one
>>
>> *All* terminal emulation applications? Does it support TeraTerm,
>> PuTTY, Reflection, DECTerm, Apple Terminal, iTerm2, GLTerm, and the
>> various Java- and Javascript-based emulators that run in a browser, to
Do you have methods to support all terminal emulation applications, or
have plan to do this? If yes, that's so good. I don't know how to
support *All* terminal emulation applications. I don't say *All*
terminal emulation applications either, pls see codes in attachment.
>> mention only the ones I've used recently? Does it support starting
>> these applications under all the different shells and command-line
>> interfaces where commands to start them may be found? Does it support
>> actual, physical VT520 terminals?
When debug script execute fork() call, does perl5db.pl support physical
VT520 or all terminal emulation applications when it call xterm_get_fork
TTY function?
>>
>> If the answer to any of these things is no, I'm fine with that. I
>> don't think the Perl debugger should have intimate knowledge of
>> anything but Perl. Hard-coded information about specific devices and
>> how to use them in specific environments is highly susceptible to bit
>> rot and maintainability problems. We probably shouldn't have such
>> things in the Perl debugger and we certainly shouldn't add any more.
>
> +1, this is very true.
Why we couldn't support current terminal emulation applications, if we
could keep compatability? Perl debugger can not work is better than
update it to support current terminal emulation applications, right?
>
> Regards,
> Vadim.

Attachments:

perl5db.pl-unix.patch (7.46 KB)

vadim.konovalov at alcatel-lucent

Apr 11, 2012, 1:04 AM

Post #12 of 15 (160 views)
Permalink

RE: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

> From: Xibo Ning

> Why we couldn't support current terminal emulation
> applications, if we
> could keep compatability? Perl debugger can not work is better than
> update it to support current terminal emulation applications, right?

as it was already said, attempt to guess current "xterm"-s is a suspect for
bit rot, and also a maintenance burden.

If you invent a way to generically support such terminals - this would be
just the right solution!

Ideally - if this could be done in a modularized way - for example -
support for all such terminals gathered in some script/module/file (so it
could be maintained more easily) - that would be just it!

All in all, thank you for your attention and efforts on the matter :)
Vadim.

xning at redhat

Apr 11, 2012, 1:33 AM

Post #13 of 15 (159 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

On 04/11/2012 04:04 PM, Konovalov, Vadim (Vadim)** CTR ** wrote:
>> From: Xibo Ning
>
>> Why we couldn't support current terminal emulation
>> applications, if we
>> could keep compatability? Perl debugger can not work is better than
>> update it to support current terminal emulation applications, right?
>
> as it was already said, attempt to guess current "xterm"-s is a suspect for
> bit rot, and also a maintenance burden.
>
> If you invent a way to generically support such terminals - this would be
> just the right solution!
>
> Ideally - if this could be done in a modularized way - for example -
> support for all such terminals gathered in some script/module/file (so it
> could be maintained more easily) - that would be just it!
>
> All in all, thank you for your attention and efforts on the matter :)
> Vadim.

Thank you, Konovalov. I will try.
Could you give me more advice? Can I use commands like this in
perl5db.pl patch:
my $tempfile = `mktemp`;

Thanks a lot, Craig, Tony. Thanks for your help.

malmberg at Encompasserve

Apr 11, 2012, 3:47 PM

Post #14 of 15 (159 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executesfork() calls [In reply to]

On 4/10/2012 10:05 PM, Craig A. Berry wrote:
> On Tue, Apr 10, 2012 at 9:08 PM, Xibo Ning<xning [at] redhat> wrote:
>> if xterm exists, then use it; if xterm doesn't
>> exist, then try terminal emulation applications one bye one
>
> *All* terminal emulation applications? Does it support TeraTerm,
> PuTTY, Reflection, DECTerm, Apple Terminal, iTerm2, GLTerm, and the

DECTerm works on VMS platform as an alias to xterm transparent to the
perl5db.pl script.

On 4/11/2012 3:33 AM, Xibo Ning wrote:
> Could you give me more advice? Can I use commands like this in
> perl5db.pl patch:
> my $tempfile = `mktemp`;

perl5db.pl should not be checking the TERM environment variable to
determine if it can fork an xterm. Most times I am running a different
terminal emulator than xterm, yet I have an X11 display available.
This is particularly an issue with running TERM=screen.

Also, it is very desirable sometimes to start off in the forked
debugger. You can do this with setting the PERLDB_PIDS=XXX so that the
debugger initially starts as a daughter session.

I have used this hack on VMS, OS-X, Cygwin, and Linux.

It might be nice to just specify on the command line that you want a
forked debugger.

TODO: On VMS need to find a way to have Perl internally set the DISPLAY
environment variable as VMS uses a different method to find the X11
display. I have to set both the TERM and DISPLAY environment variables,
and then PERLDB_PIDS before debugging on VMS.

Regards,
-John
Personal Opinion Only

craig.a.berry at gmail

Apr 11, 2012, 9:02 PM

Post #15 of 15 (158 views)
Permalink

Re: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls [In reply to]

On Wed, Apr 11, 2012 at 1:54 AM, Xibo Ning <xning [at] redhat> wrote:
> On 04/11/2012 02:17 PM, Konovalov, Vadim (Vadim)** CTR ** wrote:
>>>
>>> From: Craig A. Berry
>>
>>
>>> On Tue, Apr 10, 2012 at 9:08 PM, Xibo Ning<xning [at] redhat> �wrote:
>>>>
>>>> if xterm exists, then use it; if xterm doesn't
>>>> exist, then try terminal emulation applications one bye one
>>>
>>>
>>> *All* terminal emulation applications? �Does it support TeraTerm,
>>> PuTTY, Reflection, DECTerm, Apple Terminal, iTerm2, GLTerm, and the
>>> various Java- and Javascript-based emulators that run in a browser, to
>
> Do you have methods to support all terminal emulation applications, or have
> plan to do this?

No, I don't. And I should say that it's certainly not your fault that
the debugger implements running itself in a subprocess via a
platform-specific and emulator-specific hack. I just question whether
we should add insult to injury by tacking more details onto the hack.

> If yes, that's so good. I don't know how to support *All*
> terminal emulation applications. I don't say *All* terminal emulation
> applications either, pls see codes in attachment.

I don't know how either. My point was that we have very
device-specific, platform-specific assumptions embedded in the Perl
debugger and your patch adds to those assumptions. The fact that I
don't have an alternate design ready to hand doesn't mean the existing
design is one that should be extended without any thought to what
we're doing and why.

>>>�Does it support actual, physical VT520 terminals?

> When debug script execute fork() call, does perl5db.pl support physical
> VT520 or all terminal emulation applications when it call xterm_get_fork TTY
> function?

While it's certainly possible to have multiple sessions in VT420s and
VT520s, I don't remember offhand if that can be initiated from the
host nor how to do it. My point, again, was that adding additional
hard-coded device and operating system information to the debugger
moves us further away from keeping the core cross-platform and device
neutral, so I cited what is now an extreme case (but used to the
"standard" case). Not being able to do Perl development on VT520s is
probably ok. Not considering that there are different shells and
different platforms is probably not ok.

On Wed, Apr 11, 2012 at 12:03 AM, Xibo Ning <xning [at] redhat> wrote:

> These terminal emulation applications [PuTTY, etc.] are graphical interface.

Yes, and so is xterm. X11 is a GUI. As far as I know, they can all
be started from the command line.

> The command line to start these terminal emulation
> applications is simple, it runs well in common/standare 'sh' shell.

There's nothing standard about Unix shells on non-Unix systems.

On Wed, Apr 11, 2012 at 5:47 PM, John E. Malmberg
<malmberg [at] encompasserve> wrote:

> DECTerm works on VMS platform as an alias to xterm transparent to the
> perl5db.pl script.

Yes, I know. One hack leads to another, and I'm the one stuck
supporting this one. Each and every command that starts a subprocess
on VMS is scanned for the strings " xterm ", "tty", and "sleep" and
the pipe implementation starts an extra subprocess to run the debugger
if it finds them. This will likely stop working with Xibo's patch
since the debugger may be sending various things other than "xterm".
But it probably won't even get that far since the which() function it
introduces to validate terminal emulators is not portable.

I think the trouble starts with renaming the xterm_get_fork_TTY()
function to unix_get_fork_TTY(). xterm is not a Unix program; it is an
X11 program. It would sure be nice if the UI features and the OS
features and the emulator features and the Perl features could be kept
straight and the features that are not Perl features could be dealt
with somewhere other than the Perl core or at least abstracted in ways
that keep them separate and define the boundaries between them.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads