On 28/giu/2014, at 10:22, Joshua Root <[email protected]> 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 _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
