Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"perl single step doesn't write steps to stderr" #12971

Open
p5pRT opened this issue May 15, 2013 · 19 comments
Open

"perl single step doesn't write steps to stderr" #12971

p5pRT opened this issue May 15, 2013 · 19 comments

Comments

@p5pRT
Copy link

p5pRT commented May 15, 2013

Migrated from rt.perl.org#118003 (status was 'open')

Searchable as RT118003$

@p5pRT
Copy link
Author

p5pRT commented May 15, 2013

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

According to our records, your request regarding
  "perl single step doesn't write steps to stderr"
has been resolved.

If you have any further questions or concerns, please respond to this message.

For other topics, please create a new ticket.

<URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=118001 >
------------

  Except that it wasn't resolved. It was closed without allowing
any comment. That's not a resolution. The fact was I copied the
directions from the perl run page -- thinking that would be enough
for me -- just being able to trace it and watch the execution as it
happened does wonders sometimes. But it doesn't work. The examples
given on the perl run page don't work. They just spew output and
give no way to pause it.

There is no reason why perl should do that to a user's terminal. If it
detects it is at a terminal, it should behave like any and every other
trace facility I'm familiar with -- and allow the output tob e directed to
stderr so the user can pause it.

As this topic is about why perl's default behavior doesn't comply with other
utils and why the only examples on the perlrun page are completely worthless
not one mention that one has to use an output file to watch an interactive
trace... which sorta misses the point of watching it while it is executing.

So the other issue may be closed in that there is a workaround documented no
some other page -- but that doesn't solve the problem of the stated directions
on the perl run page are fairly worthless as they are -- and that perl really
should be a bit smarter about spewing output.

Please note -- I am following the instructions above to submit a new ticket just as asked.

Also note that they directions above are wrong-- I can't respond to that message as my email never gets recorded .

Perl Info

Flags:
    category=core
    severity=medium

This perlbug was built using Perl 5.16.2 - Fri Feb 15 01:17:37 UTC 2013
It is being executed now by  Perl 5.16.2 - Fri Feb 15 01:12:05 UTC 2013.

Site configuration information for perl 5.16.2:

Configured by abuild at Fri Feb 15 01:12:05 UTC 2013.

Summary of my perl5 (revision 5 version 16 subversion 2) configuration:
   
  Platform:
    osname=linux, osvers=3.4.6-2.10-default, archname=x86_64-linux-thread-multi
    uname='linux build34 3.4.6-2.10-default #1 smp thu jul 26 09:36:26 utc 2012 (641c197) x86_64 x86_64 x86_64 gnulinux '
    config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl'
    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='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector'
    ccversion='', gccversion='4.7.2 20130108 [gcc-4_7-branch revision 195012]', 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='cc', ldflags =' -L/usr/local/lib64 -fstack-protector'
    libpth=/lib64 /usr/lib64 /usr/local/lib64
    libs=-lm -ldl -lcrypt -lpthread
    perllibs=-lm -ldl -lcrypt -lpthread
    libc=/lib64/libc-2.17.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.17'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector'

Locally applied patches:
    


@INC for perl 5.16.2:
    /home/law/bin/lib
    /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/site_perl/5.16.2
    /usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.16.2
    /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/5.16.2
    /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi
    /usr/lib/perl5/site_perl/5.16.2
    /usr/lib/perl5/site_perl
    .


Environment for perl 5.16.2:
    HOME=/home/law
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_COLLATE=C
    LC_CTYPE=en_US.UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=.:/home/law/bin/lib:/sbin:/usr/local/sbin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/opt/dell/srvadmin/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib
    PERL5OPT=-CSA -I/home/law/bin/lib
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented May 15, 2013

From @doughera88

On Wed, 15 May 2013, Linda Walsh wrote​:

# New Ticket Created by Linda Walsh
# Please include the string​: [perl #118003]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=118003 >

This is a bug report for perl from perl-diddler@​tlinx.org,
generated with the help of perlbug 1.39 running under perl 5.16.2.

-----------------------------------------------------------------
[Please describe your issue here]

According to our records, your request regarding
"perl single step doesn't write steps to stderr"
has been resolved.

If you have any further questions or concerns, please respond to this message.

For other topics, please create a new ticket.

<URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=118001 >
------------

Except that it wasn't resolved\.  It was closed without allowing

any comment. That's not a resolution. The fact was I copied the
directions from the perl run page -- thinking that would be enough
for me -- just being able to trace it and watch the execution as it
happened does wonders sometimes. But it doesn't work. The examples
given on the perl run page don't work. They just spew output and
give no way to pause it.

Now that you know how to fix those directions, would you be willing
to offer a specific patch?

--
  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented May 15, 2013

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented May 15, 2013

From perl-diddler@tlinx.org

On Wed May 15 05​:33​:27 2013, doughera wrote​:

Now that you know how to fix those directions, would you be willing
to offer a specific patch?

--
Andy Dougherty doughera@​lafayette.edu


Does that include a patch to have it redirect to stderr if the user is
at a terminal?

@p5pRT
Copy link
Author

p5pRT commented May 15, 2013

From perl-diddler@tlinx.org

On Wed May 15 08​:07​:36 2013, LAWalsh wrote​:

----
Does that include a patch to have it redirect to stderr if the user is
at a terminal?


I.e. making it a useful example can involve fixing it in perl as well.

@p5pRT
Copy link
Author

p5pRT commented May 15, 2013

From @demerphq

On 15 May 2013 17​:10, Linda Walsh via RT <perlbug-followup@​perl.org> wrote​:

On Wed May 15 08​:07​:36 2013, LAWalsh wrote​:

----
Does that include a patch to have it redirect to stderr if the user is
at a terminal?
----
I.e. making it a useful example can involve fixing it in perl as well.

Patches are accepted based on their merits alone. We dont
"pre-authorize" patches.

So basically you need to write one, and then we can talk.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented May 15, 2013

From @doughera88

On Wed, 15 May 2013, Linda Walsh via RT wrote​:

On Wed May 15 05​:33​:27 2013, doughera wrote​:

Now that you know how to fix those directions, would you be willing
to offer a specific patch?

--
Andy Dougherty doughera@​lafayette.edu

----
Does that include a patch to have it redirect to stderr if the user is
at a terminal?

It doesn't have to. I was referring specifically to the directions in
perlrun.pod. Of course if you want to do more you certainly
may, but changing the debugger to write to stderr is likely to be a much
bigger problem, and may not have an easy solution.

--
  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented May 15, 2013

From perl-diddler@tlinx.org

On Wed May 15 08​:26​:23 2013, demerphq wrote​:

On 15 May 2013 17​:10, Linda Walsh via RT <perlbug-followup@​perl.org>
wrote​:

On Wed May 15 08​:07​:36 2013, LAWalsh wrote​:

----
Does that include a patch to have it redirect to stderr if the user is
at a terminal?
----
I.e. making it a useful example can involve fixing it in perl as well.

Patches are accepted based on their merits alone. We dont
"pre-authorize" patches.

So basically you need to write one, and then we can talk.


Pre-authorizing a patch is 1 thing, agreeing it's a problem that needs
to be fixed and could use a patch is something else.

@p5pRT
Copy link
Author

p5pRT commented May 16, 2013

From @ikegami

On Wed, May 15, 2013 at 12​:06 PM, Linda Walsh via RT <
perlbug-followup@​perl.org> wrote​:

Pre-authorizing a patch is 1 thing, agreeing it's a problem that needs
to be fixed and could use a patch is something else.

It works better if you deal in *solutions*. Start by specifying what the
patch would do exactly, and why.

@p5pRT
Copy link
Author

p5pRT commented May 26, 2013

From perl-diddler@tlinx.org

On Wed May 15 19​:39​:40 2013, ikegami@​adaelis.com wrote​:

It works better if you deal in *solutions*.


The patch would redirect output to stderr if runnonstop is set.

Note -- this fixed a unreported bug in the code -- as above, runnonstop
is set when there is no "/dev/tty"....

Yet less than a page below that, "/dev/tty" is used for default output.

Checking if runonstop is set and setting output /dev/stderr make perl's
trace facility work the same as most other trace facilities users are
familiar with. It also looks better since setting the output to
/dev/tty when above you just checked if it existed, and, at the point
output is assigned to /dev/tty, perl should be using 'runnonstop' as a
determiner of whether or not to use /dev/tty.

Anyway, patch for perl5db.pl with an update to its pod is attached.

(I actually went in to try to fix the lack of history... but then
remembered this problem...) Such a simple change -- and fixing another
bug at the same time! Worked the first time (which is a first for my
perl coding of late).

@p5pRT
Copy link
Author

p5pRT commented May 26, 2013

@p5pRT
Copy link
Author

p5pRT commented May 28, 2013

From @doughera88

On Sun, 26 May 2013, Linda Walsh via RT wrote​:

On Wed May 15 19​:39​:40 2013, ikegami@​adaelis.com wrote​:

It works better if you deal in *solutions*.
----
The patch would redirect output to stderr if runnonstop is set.

Unfortunately, this patch uses /proc/self/stderr, which appears to be a
Linux-ism. It's not present in Solaris11 or NetBSD 6.0, for example. I
don't know about HP-UX or AIX.

--
  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented May 28, 2013

From @Leont

On Tue, May 28, 2013 at 7​:09 PM, Andy Dougherty <doughera@​lafayette.edu> wrote​:

On Sun, 26 May 2013, Linda Walsh via RT wrote​:

The patch would redirect output to stderr if runnonstop is set.

Unfortunately, this patch uses /proc/self/stderr, which appears to be a
Linux-ism. It's not present in Solaris11 or NetBSD 6.0, for example. I
don't know about HP-UX or AIX.

How about this?

(I have no opinion on this, and haven't tested this patch either, just
tried to fix it).

Leon

@p5pRT
Copy link
Author

p5pRT commented May 28, 2013

From @Leont

perl5db.diff

@p5pRT
Copy link
Author

p5pRT commented May 28, 2013

From @Tux

On Tue, 28 May 2013 13​:09​:30 -0400 (EDT), Andy Dougherty
<doughera@​lafayette.edu> wrote​:

On Sun, 26 May 2013, Linda Walsh via RT wrote​:

On Wed May 15 19​:39​:40 2013, ikegami@​adaelis.com wrote​:

It works better if you deal in *solutions*.
----
The patch would redirect output to stderr if runnonstop is set.

Unfortunately, this patch uses /proc/self/stderr, which appears to be a
Linux-ism. It's not present in Solaris11 or NetBSD 6.0, for example. I
don't know about HP-UX or AIX.

None of my HP-UX's (10.20 … 11.31) have /proc at all
AIX-5.2.0.0/ML12 does hav /proc, but no /proc/self

--
H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/
http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

@p5pRT
Copy link
Author

p5pRT commented May 28, 2013

From perl-diddler@tlinx.org

Indeed. I think a better one is attached using ">&* STDERR". It also
works in the Cygwin case allowing that special case to be considered
part of the unix case. Note​: rather than simply testing for the
existence of /dev/tty, I changed the test to at least require it be a
character device.

I didn't have a test setup, but it seems it would work for the normal
MSDOS case as well (though not the check for /dev/tty...;-))...

It might work under other OS's as well as a more general solution for
all(?) of them.

Note Cygwin doesn't evidence the behavior of not having its output
redirectable, as it was already not using /dev/tty.

@p5pRT
Copy link
Author

p5pRT commented May 28, 2013

@p5pRT
Copy link
Author

p5pRT commented May 28, 2013

From perl-diddler@tlinx.org

NOTE​: FWIW, this patch was against released 5.18.0, not against 5.16.x

@p5pRT
Copy link
Author

p5pRT commented May 28, 2013

From perl-diddler@tlinx.org

On Tue May 28 10​:52​:19 2013, LeonT wrote​:

How about this?


Sorry, missed your attachment until I saw a 3rd patch listed after my
update..

Is there a reason why not to use STDERR in all cases? I.e. it seems
to be quite functional for the Cygwin and Unix cases whether run under
trace or interactively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants