[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-module-build
Subject:    Re: what was intended?  Fwd: prompt() needs a rethink?
From:       Michael G Schwern <schwern () pobox ! com>
Date:       2007-03-05 22:50:53
Message-ID: 45EC9ECD.8080906 () pobox ! com
[Download RAW message or body]

Eric Wilhelm wrote:
> Not sure if you've been following this one.  You've probably answered 
> this before and it probably bores you to tears, so I've included 
> svn.cpan.org candy.

Nope, this is the first I've heard of this.


> Can you help me understand what was intended here and/or what 
> Module::Build should do?

The intent was to make sure prompt() reads from STDIN even if its not a TTY. 
  In 6.05 it would not accept piped input, it would just take the default. 
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.

I wasn't considering the case of a user piping Makefile.PL output.

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.

     some_prompt.plx > foo.out            # takes defaults

     foo.in > some_prompt.plx > foo.out   # reads from STDIN until exhausted
                                          # then takes defaults

But what if its piped to tee or some other program, such as a CPAN shell 
which logs everything, which is taking the output and spitting it back to a 
user?

     some_prompt.plx | tee foo.out    # ???

Tricky.  In the case of STDOUT pointing to a file it seems obvious.  When 
its piped its not so obvious.  Let's look at some user scenarios.

     some_prompt.plx | less

The user intends to capture the output in a pager but probably doesn't want 
to enter input.  With the existing behavior the pager will wait *before* 
displaying the prompt, because it flushes the buffer on newlines, and thus 
the user will not see the prompt patiently waiting for input, not know 
what's going on and probably kill the program.  Thus, failure.  If we change 
it to take the default it will be much more obvious what's happening.

     some_prompt.plx | tee foo.out

In this case tee behaves better than less and displays the prompt 
immediately.  Thus its clear what's going on and what the user should do. 
So the current behavior works out.  If we change it then the code will zip 
by and take the default.  However, its pretty obvious what happened and 
PERL_MM_USE_DEFAULT can be used to override that behavior.

     a logging CPAN shell

In this case the CPAN shell author can use PERL_MM_USE_DEFAULT to override 
the behavior either way so I doubt it really matters.

So it seems pretty clear that if STDOUT is not a TTY the best thing to do is 
read from STDIN until exhausted and then use the defaults.  The worst thing 
you can do to a user is mysteriously hang without showing the output and 
that should be avoided.

Unless there's some clever way to detect a tee-style thing going on.

I leave it to someone else to figure out how to do all this. :)
[prev in list] [next in list] [prev in thread] [next in thread]