Summarizing and aggregating parts of the discussion here...
# from Andreas J. Koenig on Wednesday 31 January 2007 11:53 pm:
>(5) I call 'perl Build.PL > /tmp/ttt' and it hangs forever and
> /tmp/ttt remains empty
Ok, we've identified that Module::Build was failing to print the prompt
before checking eof(STDIN) because the error-checking of whether a
default is defined in the API call is happening before prompting and
the assumption was that we are reading a pipe. That's fixable, and
yes, fixable without using eof().
However, we're still doing the wrong thing to prompt when "-t STDIN and
not -t STDOUT". To make matters worse, a historical accident/
side-effect in MakeMaker means this has been going on for some time
(long enough that I'm wary about changing it.)
# from Andreas J. Koenig
# on Sunday 04 March 2007 09:27 pm:
> > This simply took the default because STDOUT was not on the
> terminal. As > of 6.06_01, it waits for input, but does that make it
> correct? (Or at > least: is that they way all of the cool kids are
> using it these days?)
>
>I'm just a bear of small brain but I would expect that he who asks a
>question listens to my answer. And that he trusts that I am able to
>handle the device that we are using to communicate.
>
> > My take is that we have these four use-cases:
>
> > o leave me alone: PERL_MM_USE_DEFAULT
> > o ask me questions: -t STDIN and -t STDOUT
> > o I can't hear you: -t STDIN and not -t STDOUT
> > o harness/scripted: not -t STDIN and not -t STDOUT
>
>Very nice summary. I'd label the third one with "capture" though.
Ok, we're going to have to get into a finer-grained behavior. I think
-f and -c STDOUT are both cases where it should take the default. As
Schwern mentioned, -p is trickier.
# from Michael G Schwern on Monday 05 March 2007 02:50 pm:
>The use case is for a CPAN shell or other program to run a Makefile.PL
>and give it input via STDIN while capturing the output without having
>to emulate a TTY.
...
>It sounds like you're right, that if STDOUT points to a file prompt()
> should go non-interactive BUT take care to still try to read from
> STDIN if its a pipe.
<snipped issues of tee, less, etc>
Andreas, to support your "redirect to file, but prompt me anyway" usage,
I think we really need to just define an environment variable like
PERL_MM_NO_DEFAULT (or similar e.g. PERL_MM_ASK_ANYWAY or possibly even
a --prompt switch.) I can't see a way to behave reasonably *and* let
you answer questions that are being asked to a log file, or (as far as
we know) to the null device.
Is anybody else relying on this behavior being the default? IMO, it is
broken in that we do exactly the wrong thing here:
some_prompt.plx > /dev/null
Given a "prompt me anyway" variable, we can sidestep and/or postpone the
tricky tee/less pipe issues and silly, platform-specific, digging
around in /proc/ to find the name of the program on the downstream end
of the pipe.
So, the question is: is anybody violently opposed to changing the
default behavior of prompt() to take the defaults when "-t STDIN and
not -t STDOUT" unless $ENV{PERL_MM_NO_DEFAULT} ? (The logic being: if
you're doing something special, you can set a flag to say so.
Meanwhile, we won't be behaving unreasonably in reasonable situations.)
If anybody is opposed to this change, what's your suggestion to make
the /dev/null (or logfile) redirect not silently await your answer? If
we're stuck with that behavior, we should at least warn on STDERR that
questions are being asked (though that's not really a solution when
"2>&1 > /dev/null".)
--Eric
--
You can't whack a chisel without a big wooden mallet.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
