Mid-Term Report

Aljaž Srebrnič g5pw at macports.org
Tue Jul 1 03:45:57 PDT 2014


On 28/giu/2014, at 10:22, Joshua Root <jmr at macports.org> wrote:

> On 2014-6-28 02:48 , Rainer Müller wrote:
>> On 2014-06-27 07:47, Joshua Root wrote:
>>> On 2014-6-27 05:29 , Shashwat Pandey wrote:
>>> 
>>> Sounds like good work for the most part. One note:
>>> 
>>> 
>>> This will break people's scripts. If users don't do anything different,
>>> the behaviour should stay the same. I would provide a different
>>> executable name for interactive use, but I guess a command line and/or
>>> config option to make port(1) behave that way would be OK too.
>> 
>> We have broken the backwards compatibility of the port command multiple
>> times already by changing strings and its output formats. We don't make
>> any guarantees for that, do we?
> 
> No, but changing a command that never asked for user input to now do so
> is a much bigger change. You can't even just run something and check the
> exit code then.

Well, yes you can, it will just ask for user input. Also, I think the majority of situations described
in the [wiki](https://trac.macports.org/wiki/SummerOfCode2014_interactive) are not
actions usually done in scripts IMO.

> 
>> 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?

If that’s implemented, I think it’s fine.

> 
>> Maybe we should also have an option in macports.conf to force
>> non-interactive mode?
> 
> A different executable name for interactive operation is simpler.

Yeah, but that way the user will have to learn and use a new command name and update his/her aliases to use the interactive command.

--
Aljaž Srebrnič a.k.a g5pw
My public key:  http://bit.ly/g5pw_pubkey



More information about the macports-dev mailing list