#58 -x option not always respected

[n]

Hello,
I noticed that when zipping a directory, the -x option is not always respected: some files matching the exclude pattern nevertheless get included.
Example command: zip -r dir.zip directory/ -x *pdf
Strangely, I have only observed this occurrence for files with extension .pdf specifically. It is true whether I use *.pdf or *pdf or *.p*. It is true even if I add other exclude patterns (those will get excluded correctly, but not the pdfs). It is true consistently (for several different directories that contain PDF files). If I instead explicitly specify the path to each pdf file to exclude, they are properly excluded.
I am using zip 3.0 on Mac OS 10.14.1. I tried the same exact command (with an exact clone of a directory that I tested on my Mac) on Ubuntu 16.04.5, and everything worked as expected (the pdf files were correctly ignored).

For further information about the bug, if I use -x *.p*, then no files with extensions containing "p" are excluded. (By contrast, if I use -x *.o*, for instance, the files with extensions containing "o" are in fact excluded.) Yet if I specify -x *.ppf or -x *.png, for instance, those files are correctly excluded (unlike -x *.pdf which never gets excluded). This is true whether or not .pdf files exist in the directory. If I specify -x *pf, then .ppf files get excluded - but if I specify -x *f, they do not get excluded (nor do .pdf files). By contrast, even -x *df does not exclude .pdf files.

While this bug is only a minor annoyance, I find it quite bizarre, and I am curious to know more about the cause. (I actually have some suspicions that I have run to a very similar, but transient, bug on Ubuntu Linux with the extension *.pt, but that's a story for another time.)

[n]

Apparently I may not edit my ticket. But just to clarify, the Ubuntu test also used Zip 3.0.

Actually, I'm seeing the same behavior with rsync... I therefore suspect this may be a bug in Mac OS instead. Sorry about that.

[Steven Schweda]

[...] I therefore suspect this may be a bug in Mac OS instead. [...]

User error is more likely.

  echo *.pdf

If you want Zip to see:
*.pdf
as a command-line argument, then you need to prevent your shell from
"globbing" it (that is, expanding the "*" wildcard). An easy way to do
that is to quote any special globbing characters ("*", "?") using
apostrophes. For example:

  zip -r dir.zip directory/ -x '*pdf'

Otherwise, Zip (or "rsync", any other program) will see the results of
the shell's wildcard expansion, which, in a case like this, will depend
on the files in your current directory. Around here, for example:

mba$ echo *.c  
siz.c

mba$ echo *.ccc
*.ccc

So, if one or more files exist in your current directory which match
such a wildcard file spec, then the program will see the wildcard
expansion (like "siz.c"), not the actual wildcard file spec (*.c). If
no matching files exist, then the original wildcard file spec (like
"*.ccc") gets passed along.

If you're not expecting this standard UNIX-shell behavior, it can be
confusing, because it depends on which files exist in your current
directory, which can depend on many things, leading to apparently
erratic results.

You can also use quotation marks ("), or backslash escapes (\*.pdf),
or a shell option which disables globbing.