It's a bit arbitrary which case combinations unpack currently supports, e.g. * .Z and .z are both recognised for files to be passed to gunzip, but only .tar.Z is for gunzip+tar (a .tar.z would presumably just be decompressed to give a .tar) * .ZIP, .7Z, .RAR and .LHA are recognised, but not upper-case versions of any other extensions (besides .Z) * .LHa is allowed as an alternative for .lha It would make sense to just make it case insensitive.
Portage does this already: for x in "$@"; do __vecho ">>> Unpacking ${x} to ${PWD}" suffix=${x##*.} suffix=$(LC_ALL=C tr "[:upper:]" "[:lower:]" <<< "${suffix}") # [...] case "${suffix}" in
Unfortunately, Portage added that without EAPI control, and pretty late on. We're already hitting issues in the tree.
(In reply to Ciaran McCreesh from comment #2) > Unfortunately, Portage added that without EAPI control, and pretty late on. > We're already hitting issues in the tree. Yeah, late in 2012: <http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;f=bin/phase-helpers.sh;h=3dea53c2be83088d05c82a0c3dbbe7e6e1a6edea> @Portage team: Could this be reverted please? We can do it properly for EAPI 6.
(In reply to Ciaran McCreesh from comment #2) > We're already hitting issues in the tree. Are we? I've scanned the tree for uppercase suffixes in SRC_URI, and all I can find are .Z (which is a supported extension, according to PMS) and a few .ZIP which are all properly mapped to .zip by -> arrows. So the Portage commit could still be reverted without negative impact on users.
In EAPI 6: https://gitweb.gentoo.org/proj/pms.git/commit/?id=a4eab188ea5086a581ad80b34c47601f6553f4ca