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
