>>>>> On Tue, 6 Mar 2007 19:25:35 -0800, Eric Wilhelm <[EMAIL PROTECTED]> said:
Thanks for the summary. I must apologize, this answer is going to
sound a bit violent and rude. I had to wait several days until I could
calm down to this level. I'm sure you know that this is not meant as a
personal attack, it's simple tech talk but with emotions.
> 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().
Good.
> 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.
I disagree. Schwern may have missed his coffee that day. If we could
agree that neither -f nor -c on STDOUT should give us a reason to not
listen at all then -p too and nothing else will going to be tricky. I
just confirmed to myself that this is how MakeMaker works at the
moment and it is good.
> # 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.)
If only Schwern would wake up now to shout "Stop, stop, stop, stop".
Only a completely broken design can make it necessary that we need
*two* environment variables to decide if a user wants to answer
questions or wants the defaults to be taken.
> 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.
Sure can we. If you would let the user use his terminal the way it was
designed. STDIN closed means: there's nothing to expect. User can do
this by "< /dev/null". Because we want to support more than one way:
PERL_MM_USE_DEFAULT=1 is the second way to get defaults only. The
third one is to pipe "yes ''|" to the Build.PL. I'm sure there are
plenty more ways.
Everything else shall wait for an answer, period. I have a right to
see the questions and I have a right to answer them. It's my decision
where I redirect the questions to and how I enter the answers. Please
don't get in the way.
> 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
No, "we" are not doing the wrong thing. This guy is either shooting
himself in the foot or he knows what he's doing. Let him.
> 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.
You say it yourself: silly is it when you try to find out what the
user might maybe probably eventually be doing on his end. So remove
code that is poking in his nose instead of writing code that makes
things worse.
> So, the question is: is anybody violently opposed
violently opposed, that's me!
> 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.)
I cannot find anthing special in running "| tee" and there's not much
special in running "> /dev/pts/5" and there's absolutely nothing
special in running "> capture-my-8-megabyte-installation-dialog.txt".
It's broken to call these usage scenarios "special".
> If anybody is opposed to this change, what's your suggestion to make
> the /dev/null (or logfile) redirect not silently await your answer?
I am strongly opposed.
For the "> /dev/null" case I'd venture that you are doing the wrong
thing for those who type "rm -rf /" too. So what?
I can speak for the "> logfile" crowd: we know how to use "tail".
After all, silence is golden, sometimes.
> 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".)
Goodness! <sarcasm>What about adding a mandatory dialog that asks the
user if he has read the manual. And when he answers no, we quit
immediately and shutdown the computer before he enters a wrong
command.</sarcasm>
--
andreas
