Re: Module::Build->y_n does not seem to set $|
On Jan 30, 2007, at 12:01 AM, Andreas J. Koenig wrote: This morning I found one of my batch jobs hanging and the logfile only revealed that it was during installation of DMAKI/DateTime-Util-Calc-0.11.tar.gz but there was no apparent sign for a reason. I found the following in the Build.PL: my $proceed = Module::Build->y_n($message, "n"); It looks like this was the cause of the hang. And I would guess one can argue that it's Module::Build's duty to set $| for these cases. It does already set $|=1. Both in y_n() and prompt(). Since before version 0.28, if I'm reading svn correctly. -Ken
Re: Module::Build->y_n does not seem to set $|
> On Wed, 31 Jan 2007 21:46:09 -0600, Ken Williams <[EMAIL PROTECTED]> said: > On Jan 30, 2007, at 12:01 AM, Andreas J. Koenig wrote: >> This morning I found one of my batch jobs hanging and the logfile only >> revealed that it was during installation of >> DMAKI/DateTime-Util-Calc-0.11.tar.gz but there was no apparent sign >> for a reason. I found the following in the Build.PL: >> >> my $proceed = Module::Build->y_n($message, "n"); >> >> It looks like this was the cause of the hang. And I would guess one >> can argue that it's Module::Build's duty to set $| for these cases. > It does already set $|=1. Both in y_n() and prompt(). Since before > version 0.28, if I'm reading svn correctly. Thanks for looking into it! So there's definitely something broken, I don't know what. It looks like the prompt function in Module::Build::Base is not called when the output is redirected to a non-terminal. If I add a C at the beginning of the prompt subroutine, it is reached in the debugger but not when I run the Build.PL with output redirected. I cannot investigate more right now. These are the facts: (1) perl is bleadperl @30080 (verified again with 30087) (2) Module::Build is 0.2806 (3) distro is DMAKI/DateTime-Util-Calc-0.11.tar.gz (4) Math::BigInt::GMP and Math::Pari must NOT be installed, so that y_n() is triggered (5) I call 'perl Build.PL > /tmp/ttt' and it hangs forever and /tmp/ttt remains empty I'm grateful for any pointers you have. -- andreas
Re: Module::Build->y_n does not seem to set $|
> On Thu, 01 Feb 2007 08:53:56 +0100, [EMAIL PROTECTED] (Andreas J. Koenig) > said: > On Wed, 31 Jan 2007 21:46:09 -0600, Ken Williams <[EMAIL PROTECTED]> said: >> On Jan 30, 2007, at 12:01 AM, Andreas J. Koenig wrote: > So there's definitely something broken, I don't know what. It looks > like the prompt function in Module::Build::Base is not called when the > output is redirected to a non-terminal. If I add a C at the > beginning of the prompt subroutine, it is reached in the debugger but > not when I run the Build.PL with output redirected. > I cannot investigate more right now. These are the facts: > (1) perl is bleadperl @30080 (verified again with 30087) > (2) Module::Build is 0.2806 > (3) distro is DMAKI/DateTime-Util-Calc-0.11.tar.gz > (4) Math::BigInt::GMP and Math::Pari must NOT be installed, so that y_n() is triggered > (5) I call 'perl Build.PL > /tmp/ttt' and it hangs forever and /tmp/ttt remains empty Introduced between 0.27_10 and 0.28 with SVN rev. 5919 The offending line: + return $ENV{PERL_MM_USE_DEFAULT} || ( !$self->_is_interactive && eof STDIN ); This hangs forever when the STDOUT is redirected and STDIN is not redirected. -- andreas
Re: Module::Build->y_n does not seem to set $|
On Feb 1, 2007, at 5:42 PM, Andreas J. Koenig wrote: The offending line: + return $ENV{PERL_MM_USE_DEFAULT} || ( !$self->_is_interactive && eof STDIN ); This hangs forever when the STDOUT is redirected and STDIN is not redirected. Indeed. I think I've got a reasonable fix, does it look reasonable to you? Of course, STDIN could be something more exotic like a tied fh, and then I guess we'd be at the mercy of whomever tied it... I found this by looking in the perl source for the smallest wrapper around the PerlIOValid() macro. -Ken --- lib/Module/Build/Base.pm(revision 2264) +++ lib/Module/Build/Base.pm(local) @@ -471,7 +471,8 @@ sub _is_unattended { my $self = shift; - return $ENV{PERL_MM_USE_DEFAULT} || ( !$self->_is_interactive && eof STDIN ); + return $ENV{PERL_MM_USE_DEFAULT} + || ( !$self->_is_interactive && !defined fileno STDIN ); } sub _readline {
Re: Module::Build->y_n does not seem to set $|
# from Ken Williams # on Sunday 04 February 2007 07:13 pm: >On Feb 1, 2007, at 5:42 PM, Andreas J. Koenig wrote: >> The offending line: >> >> + return $ENV{PERL_MM_USE_DEFAULT} || ( !$self->_is_interactive && >> eof STDIN ); >> >> This hangs forever when the STDOUT is redirected and STDIN is not >> redirected. > >Indeed. > >I think I've got a reasonable fix, does it look reasonable to you? >Of course, STDIN could be something more exotic like a tied fh, and >then I guess we'd be at the mercy of whomever tied it... > >I found this by looking in the perl source for the smallest wrapper >around the PerlIOValid() macro. >+ return $ENV{PERL_MM_USE_DEFAULT} >+ || ( !$self->_is_interactive && !defined fileno STDIN ); From my experiment, this doesn't change the behavior. It just causes it to hang later in _readline() instead. return $ENV{PERL_MM_USE_DEFAULT} || ( !$self->_is_interactive && (-t STDIN ? 1 : eof(STDIN)); I think this gives you the correct answer for _is_unattended() -- where STDOUT is being redirected, we are unattended unless we're being fed a set of scripted answers on STDIN. --Eric -- hobgoblin n 1: (folklore) a small grotesque supernatural creature that makes trouble for human beings --- http://scratchcomputing.com ---
Re: Module::Build->y_n does not seem to set $|
On Feb 5, 2007, at 12:53 AM, Eric Wilhelm wrote: From my experiment, this doesn't change the behavior. It just causes it to hang later in _readline() instead. In my experiment it seems to work. I set things up with the scenario Andreas described (STDOUT is redirected to a file, STDIN is live). blib/ has the new code, otherwise it's hitting M::B 0.2806: - [scotchie:~/src/Module-Build-svk] ken% cat prompt.pl use Module::Build; my $unatt = Module::Build->_is_unattended; warn "Unattended: $unatt\n"; my $ans = Module::Build->prompt("Answer?", "default"); print "You say $ans!\n"; [scotchie:~/src/Module-Build-svk] ken% perl -Mblib prompt.pl Unattended: Answer? [default] nondefault You say nondefault! [scotchie:~/src/Module-Build-svk] ken% perl prompt.pl Unattended: Answer? [default] nondefault You say nondefault! [scotchie:~/src/Module-Build-svk] ken% perl -Mblib prompt.pl > foo Unattended: 1 [scotchie:~/src/Module-Build-svk] ken% cat foo Answer? [default] default You say default! [scotchie:~/src/Module-Build-svk] ken% perl -Mblib prompt.pl | tee foo Unattended: Answer? [default] nondefault You say nondefault! [scotchie:~/src/Module-Build-svk] ken% cat foo Answer? [default] You say nondefault! [scotchie:~/src/Module-Build-svk] ken% perl prompt.pl > foo ^C (hangs) - Note that when you 'tee' output you get to answer, but when you use '>' you don't. Which I think makes some kind of sense - with the former you get to see the question, with the latter you don't. I think it's okay for it to "hang" in _readline(), because STDIN is live and we're asking the user a question - recall that his initial proposed fix was just to unbuffer STDOUT with $| = 1. What I think Andreas was saying is not okay is to hang while just trying to determine whether STDIN is live. -Ken
Re: Module::Build->y_n does not seem to set $|
> On Sun, 4 Feb 2007 21:13:04 -0600, Ken Williams <[EMAIL PROTECTED]> said: > I think I've got a reasonable fix, does it look reasonable to you? While it seems to solve my problem, I got a recommendation from Slaven Rezic to look at perlfaq8 "How do I find out if I'm running interactively or not?" and what he made out of it in Tk::Pod::Util sub is_interactive { if ($^O eq 'MSWin32' || !eval { require POSIX; 1 }) { # fallback return -t STDIN && -t STDOUT; } # from perlfaq8 open(TTY, "/dev/tty") or die $!; my $tpgrp = POSIX::tcgetpgrp(fileno(*TTY)); my $pgrp = getpgrp(); if ($tpgrp == $pgrp) { 1; } else { 0; } } Of course, this has a different focus on an X11 application, but when Module::Build is run from an X11 app, it might be relevant. -- andreas
Re: Module::Build->y_n does not seem to set $|
On Feb 5, 2007, at 10:32 PM, Andreas J. Koenig wrote: Of course, this has a different focus on an X11 application, but when Module::Build is run from an X11 app, it might be relevant. Yeah, but I'm a little hesitant to rely so strongly on /dev stuff, for cross-platform reasons. For instance, I think it's only recent versions of OS X that had a /dev filesystem at all, though I can't seem to find a reference saying so. I looked at EU::MM and noticed that it too calls eof(STDIN), so does it have a similar problem? -Ken
Re: Module::Build->y_n does not seem to set $|
> On Wed, 7 Feb 2007 18:38:00 -0600, Ken Williams <[EMAIL PROTECTED]> said: > On Feb 5, 2007, at 10:32 PM, Andreas J. Koenig wrote: >> >> Of course, this has a different focus on an X11 application, but when >> Module::Build is run from an X11 app, it might be relevant. > Yeah, but I'm a little hesitant to rely so strongly on /dev stuff, for > cross-platform reasons. For instance, I think it's only recent > versions of OS X that had a /dev filesystem at all, though I can't > seem to find a reference saying so. Fair enough. > I looked at EU::MM and noticed that it too calls eof(STDIN), so does > it have a similar problem? I've reviewed MakeMaker and found this spot: local $|=1; local $\; print "$mess $dispdef"; my $ans; if ($ENV{PERL_MM_USE_DEFAULT} || (!$isa_tty && eof STDIN)) { This means that MakeMaker does that after it has printed the prompt. I think this is always OK. -- andreas