Opened 16 years ago

Last modified 16 years ago

#16223 new defect

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 (Rainer Müller), ryandesign (Ryan Carsten Schmidt)
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 (10)

comment:1 Changed 16 years ago by raimue (Rainer Müller)

Cc: raimue@… added

Cc Me!

comment:2 Changed 16 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 16 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 16 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 Changed 16 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 Changed 16 years ago by landonf (Landon Fuller)

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

comment:7 in reply to:  6 Changed 16 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 ; Changed 16 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 16 years ago by tobypeterson

Milestone: MacPorts base bugsMacPorts Future

Milestone MacPorts base bugs deleted

comment:10 in reply to:  8 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)

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.