[MacPorts] #16223: port doesn't check whether the extract target has failed
#16223: port doesn't check whether the extract target has failed ---------------------------------+------------------------------------------ Reporter: vinc17@macports.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.6.0 Keywords: | ---------------------------------+------------------------------------------ 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. -- Ticket URL: <http://trac.macports.org/ticket/16223> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16223: port doesn't check whether the extract target has failed ----------------------------------+----------------------------------------- Reporter: vinc17@macports.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.6.0 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by blb@macports.org): 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. -- Ticket URL: <http://trac.macports.org/ticket/16223#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16223: port doesn't check whether the extract target has failed ----------------------------------+----------------------------------------- Reporter: vinc17@macports.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.6.0 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by vinc17@macports.org): Replying to [comment:2 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. -- Ticket URL: <http://trac.macports.org/ticket/16223#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16223: port doesn't check whether the extract target has failed ----------------------------------+----------------------------------------- Reporter: vinc17@macports.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.6.0 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by blb@macports.org): 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. -- Ticket URL: <http://trac.macports.org/ticket/16223#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16223: port doesn't check whether the extract target has failed ----------------------------------+----------------------------------------- Reporter: vinc17@macports.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.6.0 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by vinc17@macports.org): So, [http://sourceforge.net/projects/pipestatus/ 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. -- Ticket URL: <http://trac.macports.org/ticket/16223#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16223: port doesn't check whether the extract target has failed ----------------------------------+----------------------------------------- Reporter: vinc17@macports.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.6.0 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by landonf@macports.org): /bin/sh is only required to be a posix bourne shell -- Ticket URL: <http://trac.macports.org/ticket/16223#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16223: port doesn't check whether the extract target has failed ----------------------------------+----------------------------------------- Reporter: vinc17@macports.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.6.0 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by vinc17@macports.org): Replying to [comment:6 landonf@macports.org]:
/bin/sh is only required to be a posix bourne shell
Yes, this is exactly what ''pipestatus'' assumes. -- Ticket URL: <http://trac.macports.org/ticket/16223#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16223: port doesn't check whether the extract target has failed ----------------------------------+----------------------------------------- Reporter: vinc17@macports.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.6.0 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by afb@macports.org):
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... -- Ticket URL: <http://trac.macports.org/ticket/16223#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16223: port doesn't check whether the extract target has failed ---------------------------------+------------------------------------------ Reporter: vinc17@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.6.0 Keywords: | Port: ---------------------------------+------------------------------------------ Changes (by ryandesign@…): * cc: ryandesign@… (added) Comment: Replying to [comment:8 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; [http://lists.macosforge.org/pipermail/macports- users/2009-January/013335.html see the mailing list].
-- Ticket URL: <http://trac.macports.org/ticket/16223#comment:10> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts