port doesn't exit with proper return value
ryandesign at macports.org
Fri May 16 23:56:52 PDT 2008
On May 17, 2008, at 1:50 AM, Joshua Root wrote:
> Ryan Schmidt wrote:
>> On May 16, 2008, at 7:46 AM, Joshua Root wrote:
>>> Port's normal mode of operation is to run as many of the requested
>>> commands as possible and not exit when a command fails. It does
>>> this by
>>> suppressing the error status from the commands. This is certainly
>>> incorrect when there's only one command run and it fails, but
>>> it's less
>>> clear what should happen when some of the requested commands
>>> You can make the first failed command cause port to exit, with the
>>> appropriate return code, by using the -x option on the command line.
>>> Related tickets:
>> Seems like -x should be the default, or rather, that the -x option
>> should be removed, and port should always issue an error message
>> and stop with a nonzero exit status the moment something goes
>> wrong. Why would one not want that?
> I think the idea is that if you run `port install foo bar baz` or
> `port upgrade outdated`, and one of the ports fails to install/
> upgrade, you probably want it to still do the others. This is
> certainly the case when the operation will take a long time and you
> want to be able to leave it unattended.
On the contrary, I do want MacPorts to stop as soon as it runs into
an error. If I say "port upgrade cairo pango graphviz", and graphviz
depends on pango, and pango depends on cairo, and maybe the latest
version of graphviz requires the latest version of pango which
requires the latest version of cairo, and suppose that cairo fails to
upgrade, then I do not want MacPorts to attempt to upgrade pango or
I suppose I can see the point if you've asked for the installation of
various unrelated ports, that it should continue to install the other
ports even if one fails. But it seems like "most" people would want
MacPorts to stop and issue and error if an error occurs. The other
behavior could be available via a flag, for advanced users.
> On reflection, there should probably always be a non-zero exit
> status when any command fails, but a failure shouldn't cause the
> batch to stop.
More information about the macports-dev