FS#76905 - [unzip] zipgrep fails to search files named "-e" or "-n" (among others)

Attached to Project: Arch Linux
Opened by Lex (lexbailey) - Wednesday, 21 December 2022, 17:41 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:17 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Jonas Witschel (diabonas)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

zipgrep fails to search files with specific file names inside zip files.
This issue is peculiar to systems where /bin/sh is bash, as is (afaict) the default for Arch. (For example, this works fine on debian where /bin/sh is dash by default)

any zip file that contains files with the following names will show this bug:
-e
-n
-E
-en
...etc

In summary: if the file name starts with a dash and is followed only by characters in [neE] then this problem occurs.

zipgrep tries to process each file name by echoing it into another command, but bash's echo interprets files with names like these as if they are options to echo and thus does not echo them.

A fix that works for me is to swap the echo for a printf:

72c72
< i=` echo "$i" | \
---
> i=` printf '%s' "$i" | \

However, given that this works fine on not-bash shells I suspect that the upstream response to a patch like this would be "just use dash or similar".
This is of course a valid option, to make this package depend on dash and then change the #! line

Additional info:
* package version: 6.0-19

Steps to reproduce:

Consider the following bash session...

$ echo bar > -e
$ zip e.zip -- -e
adding: -e (stored 0%)
$ zipgrep bar e.zip
caution: filename not matched:
$

I would not expect to see "caution: filename not matched:"
instead, I would expect "-e: bar"
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:17 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/unzip/issues/2
Comment by Toolybird (Toolybird) - Wednesday, 21 December 2022, 23:25 GMT
This is clearly an upstream issue. Please refer to the bug guidelines [1]. Upstream would surely like to know if it doesn't work when /bin/sh is bash so please report it there.

[1] https://wiki.archlinux.org/title/Bug_reporting_guidelines#Upstream_or_Arch%3F
Comment by Lex (lexbailey) - Friday, 20 January 2023, 13:42 GMT
I remain convinced that this is a packaging bug and not an upstream bug.
However, I did attempt to contact the upstream maintainers to ask if they were interested in this issue, it has been about a month since I tried, I got no reply.
Perhaps you already have a relationship with the upstream maintainers and know a better way to contact them?
Comment by Toolybird (Toolybird) - Sunday, 22 January 2023, 01:26 GMT
Well, at least you tried. Upstream does seem rather unresponsive (judging by the large amount of patches) which means there are grounds to just apply this locally for the Arch pkg.

Loading...