port doesn't check whether the extract target has failed

[vinc17@…]

port doesn't check whether the extract target has failed and always runs the configure target. If the extract target has failed, the configure target also fails very early, but the user may be confused by the error message, in particular if the -v option hasn't been used (the error message in the extract target is filtered out). As an example, see #16220.

If "port extract <portname>" has been used, port is completely silent.

[raimue@…]

Cc Me!

[blb@…]

Some experimenting suggests its the pipe that causes a loss of the error code; when portextract.tcl does

default extract.post_args {"| ${portutil::autoconf::tar_command} -xf -"}

and the program prior to the pipe fails, it's error code is then lost because of the pipe.

[vinc17@…]

Replying to blb@macports.org:

the program prior to the pipe fails, it's error code is then lost because of the pipe.

Do we know what shell is used? Is it always bash? bash has a variable PIPESTATUS to retrieve the error codes.

[blb@…]

SystemCmd() (in Pextlib) is what eventually gets called in this case, which simply uses sh so in theory it's bash, unless there are other places where /bin/sh may be something other than bash.

[vinc17@…]

So, pipestatus may be a solution: source file for POSIX shell that allows to obtain an exit status of every program in a pipe.

Or anything simpler could be implemented in the particular case of MacPorts.

[landonf@…]

/bin/sh is only required to be a posix bourne shell

[vinc17@…]

Replying to landonf@macports.org:

/bin/sh is only required to be a posix bourne shell

Yes, this is exactly what pipestatus assumes.

[afb@…]

Or anything simpler could be implemented in the particular case of MacPorts.

Checking whether "binaryInPath" actually succeeds when guessing bzip2/lzma/unzip/hdiutil seems like a good idea...