Mid-Term Report

[Clemens Lang]

Hi,

> I don't want to tell every user to use a different command now. What
> would you call it? Wouldn't it make more sense to introduce a new binary
> name for use in batch mode? However, that would be the same change as
> using a 'port -N' flag...
> 
> >> If you redirect the command output or it is not connected to a terminal,
> >> port(1) will automatically behave non-interactively as it did before.
> > 
> > OK, that's not as bad. But does that prevent the use of tools like expect?

My take on this is that enabling interactivity when the port process is
connected to a terminal and disabling it in all other cases is enough to deal
with the case of scripts.

Recall the change printing progress information I made for rev-upgrade and the
new progress bars. You wouldn't want those either when run from a script (i.e.,
noninteractive) and in fact they are hidden. If the output is connected to a
terminal, I think we can expect a user to see and respond to the questions
asked by MacPorts, especially since almost all of them occur in situations
where port would previously abort right away.

I don't think expect-compatibility (if it really doesn't work the way we handle
this at the moment) is that big of a deal. Remember we still have the MacPorts
API for people that want to do serious MacPorts scripting.

-- 
Clemens Lang