Ticket #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@…, 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:2 follow-up: ↓ 3 Changed 5 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 5 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 5 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 5 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 5 years ago by landonf@…
/bin/sh is only required to be a posix bourne shell
comment:7 in reply to: ↑ 6 Changed 5 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 5 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 4 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 4 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.


Cc Me!