Thu Jan 23 19:27:15 2014: Request 92402 was acted upon.
Transaction: Correspondence added by DAVIDO
Queue: Inline
Subject: Inline asks interactive question -- but doesn't have keyboard
Broken in: (no value)
Severity: Important
Owner: Nobody
Requestors: pa...@tlinx.org
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=92402 >
On Thu Jan 23 16:06:00 2014, LAWALSH wrote:
> On Thu Jan 23 01:25:12 2014, DAVIDO wrote:
> >
> > > Do you want to install Inline::C? [y] y
> >
> > At this point you're experiencing the Makefile.PL for Inline::C, as
> > the CPAN installer runs all Makefile.PL's within the distribution
> > recursively. The prompting is handled by ExtUtils::MakeMaker's
> > prompt() function. And as you see within the "[y]" square brackets,
> > prompt() is being directed to supply a default.
> ----
> Right -- but then it **waits*** for input.
>
> The input never comes, because my input is being redirected
> "elsewhere" (dunno).
I myself have taken a pretty close look at how prompt() works, because I've
stolen much of its guts into IO::Prompt::Hooked (one of my modules on CPAN).
If you are getting blocking behavior, that's a problem, but not an Inline
problem. From the prompt() documentation in EU::MM:
"If prompt() detects that it is not running interactively and there is
nothing
on STDIN or if the PERL_MM_USE_DEFAULT environment variable is set to
true, the
$default will be used without prompting. This prevents automated processes
from
blocking on user input."
So the question comes down to why is *your* automated process allowing
*prompt()* to block for user input? This line from EU::MM::prompt's source
makes me wonder....
if ($ENV{PERL_MM_USE_DEFAULT} || (!$isa_tty && eof STDIN)) {
Is it possible that you've got something waiting on STDIN, so the "eof STDIN"
test fails? Or is there a problem a few lines earlier when prompt() attempts
to detect if it's got a tty or not? One way to test this theory would be to
set the environment variable PERL_MM_USE_DEFAULT and see if you still get the
blocking behavior. Setting it to a true value will short-circuit the test of
STDIN being at an eof condition, and I suspect you will no longer block.
Either way, this seems to me to be an interaction between your configuration
and EU::MM::prompt. I don't see how it could be something relating to
Inline::C's Makefile.PL. If you know otherwise, please do point to the code in
Inline::C's Makefile.PL that is blocking... but we already know from the dump
of your run that prompt() is blocking.... so the finger points back at
prompt(), and how it's interacting with your system. Inline::C's makefile
doesn't have control over this, unless we decide that there's some more
reliable version of prompt that we could be using, which, given EU::MM's
ubiquity, is unlikely.
> It's not a matter of "like" -- it's a matter of it stopping at any
> interactive prompt (most have some default), and waiting for input.
> Then it "pseudo-dies"-- due to hitting the timeout value in my CPAN
> config file. (usually set to 15 seconds).
Yes, "like" was the wrong word. It's blocking for you, and that's irritating
at best, and definitely not what we have in mind. ...but the question is
"why?" And as you dive into the layers of code involved, everything I'm seeing
points to how ExtUtils::MakeMaker prompt interacts with your environment. I
haven't even looked at the EU::MM bug queue lately to see if others are
mentioning such issues... but if they are, that's where I'd expect to see them
mentioned.
> > The next issue to consider is how the cpan installer works. The
> > basic
> > 'cpan' installer (provided by App::cpan) doesn't (to my knowledge)
> > provide an option for interactive installations.
> ----
> The rest of this seems not relevant, as I don't want interactive, but
> during non-interactive build,
> 1) CPAN pauses at any such point to wait for input (even w/a default)
> until it hits the 'inactivity timeout value.
> 2) Then the exit via signal is detected by CPAN as an error and no
> default is taken.
Yes, I agree. If you want non-interactive to progress without blocking, setting
cpanminus to interactive mode isnt what you need. When I first read your post
you mentioned hitting "y" and not getting response from the keyboard, which is
where I derived the relevancy of the --interactive mode in cpanminus. But you
just want it to stop blocking. I would too. There are a limited number of
places to look for that problem; Makefile.PL, which uses prompt, which comes
from EU::MM.
