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 _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
