Hi,

zip can't handle file names beginning with a dash:

$ zip foo "-=[hello]=-.txt"

zip error: Invalid command arguments (no such option: =)

However, one may provide the file names via stdin and use the -@ option
but this is not possible for the project I'm working on without
rewriting a lot of code.

I just hacked support for the common double dash stop-switches-scanning
option into zip.c. It definitely needs more work (help information etc.)
but it basically works already:

$ zip foo -- "-=[hello]=-.txt"
  adding: -=[hello]=-.txt (stored 0%)

Best Regards,
Claudio

Doh!

Actually I intended to attach a patch to my bug report and I thought reportbug would handle this auto-magically for me when I direct it to include a specific file into the message.

Now, here it is (or so I hope ;-))

Regards.
Claudio

Where is the patch?

zip foo ./-=[hello]=-.txt

Hello.

I've received the following report from the Debian bug system:
[ Please keep the Cc: lines when replying. Thanks ].

Package: zip
Version: 2.30-5
Severity: normal
Tags: patch

Hi,

zip can't handle file names beginning with a dash:

$ zip foo "-=[hello]=-.txt"

zip error: Invalid command arguments (no such option: =)

However, one may provide the file names via stdin and use the -@ option
but this is not possible for the project I'm working on without
rewriting a lot of code.

I just hacked support for the common double dash stop-switches-scanning
option into zip.c. It definitely needs more work (help information etc.)
but it basically works already:

$ zip foo -- "-=[hello]=-.txt"
  adding: -=[hello]=-.txt (stored 0%)

Best Regards,
Claudio
---------------------------------------

The patch:
--- zip-2.3/zip.c	1999-11-16 21:08:10.000000000 +0100
+++ zip-2.30/zip.c	2002-11-07 17:05:44.000000000 +0100
@@ -52,6 +52,7 @@
 #define UPDATE  2
 #define FRESHEN 3
 local int action = ADD; /* one of ADD, UPDATE, FRESHEN, or DELETE */
+local int more_options = 1; /* expect more options on the command line */
 local int comadd = 0;   /* 1=add comments for new files */
 local int zipedit = 0;  /* 1=edit zip comment and all file comments */
 local int latest = 0;   /* 1=set zip file time to time of latest file */
@@ -1058,9 +1059,13 @@

   for (i = 1; i < argc; i++)
   {
-    if (argv[i][0] == '-')
+    if (more_options && argv[i][0] == '-')
     {
-      if (argv[i][1])
+      if (argv[i][1] == '-' && ! argv[i][2])
+      {
+	more_options = 0;
+	continue;
+      } else if (argv[i][1])
         for (p = argv[i]+1; *p; p++)
           switch (*p)
           {

Christian Spieler wrote:

Yes, but the report included a patch to implement `--'.
Do you mean the patch is rejected?

I think handling this generally requires that Zip know which of its options
were quoted.  This is possible on some platforms but I sure don't know a
way to handle it generally for all.

----- Original Message -----
From: Paul Kienitz <paul@gning.org>
Date: Mon, 11 Nov 2002 16:44:57 -0800

No, it wouldn't be necessary to know which options were quoted. You just could stop scanning for options after the first non-option argument resp. the archive name.

Anyway, it's OK for me now since I can use the ./<file> workaround which I already tried before reporting that here but it didn't work due to another problem (with wildcards). Nevertheless, it's kind of a PITA and it would be much easier to have an option (the usual double dashes) to stop option processing. (zip foo -- -hallo-.txt).

What eventually confused me is: Why doesn't work unzip like zip (or vice versa) in this respect? It seems unzip just stops scanning for options after reading the archive name. What about consistency? Wouldn't that be nice?

Regards,
Claudio