Bug: unzip does not recognize `--` "option"

[bjornbm]

Contact Details

bjorn.buckwalter@gmail.com

What happened?

I'm not sure this is a bug in cosmo unzip, but it breaks the vim zip browsing plugin.

What I see with cosmo unzip (UnZip 6.10b BETA of 10 Dec 10):

$ ./unzip -Z -1 -- my.zip
zipinfo:  cannot find or open --, --.zip or --.ZIP.

What I see with macos stock unzip (UnZip 6.00 of 20 April 2009):

$ /usr/bin/unzip -Z -1 -- my.zip
file1
file2

(The example zip file created withtouch file1 file2 && zip my.zip file1 file2)

Frankly, I'm not sure this is a bug as I don't see -- documented in the the stock unzip manpage. Also, I'm not sure exactly what it is expected to do… based on my testing it seems to ignore only the next valid flag. 🤷

Anyway, the reason I ran into this is that it breaks the vim zip plugin which complains that:

zipinfo:  cannot find or open --, --.zip or --.ZIP.

and then does a binary display.

When run without cosmo unzip on the PATH vim my.zip works correctly and displays a listing of the zipfile contents.

FYI one of the offending lines in the vim plugin (usr/share/vim/vim90/autoload/zip.vim in cosmo vim zipfile) is:

  exe "keepj sil! r! ".g:zip_unzipcmd." -Z -1 -- ".s:Escape(a:zipfile,1)

(But see https://github.com/vim/vim/blob/fb792374cf7ed1a965b57ca0071e67d07a613d6b/runtime/autoload/zip.vim#L141 for latest?)

I'm not sure what is the “right“ resolution. Is it a cosmo unzip peculiarity, or is it an upstream 6.10b BETA change that breaks zip.vim unrelated to cosmo? If so then sorry for filing a report here, but maybe consider providing stable (not BETA) unzip at https://cosmo.zip/pub/cosmos/bin/ ?

Version

bin $ ./unzip -v
UnZip 6.10b BETA of 10 Dec 10, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 14.1.0 for Unix on Jan  1 1970.

UnZip special compilation options:
        COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
        SET_DIR_ATTRIB
        SYMLINKS (symbolic links supported, if RTL and file system permit)
        TIMESTAMP
        UNIXBACKUP (-B creates backup files)
        USE_EF_UT_TIME
        USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
        USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
        LARGE_FILE_SUPPORT (large files over 2 GiB supported)
        ZIP64_SUPPORT (archives using Zip64 for large files supported)
        USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.8, 13-Jul-2019)
        VMS_TEXT_CONV
        [decryption, version 2.91 of 05 Jan 2007]

UnZip and ZipInfo environment options:
           UNZIP:  [none]
        UNZIPOPT:  [none]
         ZIPINFO:  [none]
      ZIPINFOOPT:  [none]

What operating system are you seeing the problem on?

Mac

Relevant log output

[GabrielRavier]

Frankly, I'm not sure this is a bug as I don't see -- documented in the the stock unzip manpage.

-- is typically the kind of thing that's just implemented in most tools and feels like the "default", in particular because it's directly implemented in getopt and many other options parsing libraries, so practically no program directly documents what it does - that is, -- is expected to terminate all options starting with - (that is, making it so later arguments starting with - are interpreted as normal non-option arguments), so that the user (here, Vim) can easily pass arguments with stupid names like -lol without unzip interpreting that as options.

So in conclusion it seems logical to me to consider this a bug - I don't think there's any usefulness to ignoring POSIX here, especially given it breaks actual users of unzip.

PS: yes i misclicked the close button, sorry x)