New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #16223 (new defect)

Opened 6 years ago

Last modified 5 years ago

port doesn't check whether the extract target has failed

Reported by: vinc17@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts Future
Component: base Version: 1.6.0
Keywords: Cc: raimue@…, ryandesign@…
Port:

Description

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.

Change History

comment:1 Changed 6 years ago by raimue@…

  • Cc raimue@… added

Cc Me!

comment:2 follow-up: ↓ 3 Changed 6 years ago by 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.

comment:3 in reply to: ↑ 2 Changed 6 years ago by 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.

comment:4 Changed 6 years ago by 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.

comment:5 follow-up: ↓ 8 Changed 6 years ago by 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.

comment:6 follow-up: ↓ 7 Changed 6 years ago by landonf@…

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

comment:7 in reply to: ↑ 6 Changed 6 years ago by vinc17@…

Replying to landonf@macports.org:

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

Yes, this is exactly what pipestatus assumes.

comment:8 in reply to: ↑ 5 ; follow-up: ↓ 10 Changed 6 years ago by 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...

comment:9 Changed 5 years ago by toby@…

  • Milestone changed from MacPorts base bugs to MacPorts Future

Milestone MacPorts base bugs deleted

comment:10 in reply to: ↑ 8 Changed 5 years ago by ryandesign@…

  • Cc ryandesign@… added

Replying to afb@…:

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

But that only helps when the extract utility does not exist. It does not help when the extract utility exists but does not work, as has happened several times when a MacPorts-installed bzip2 is migrated to a new machine; see the mailing list.

Note: See TracTickets for help on using tickets.