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