in reply to Why doesn't system("zip -D") exclude directories?

A common error is to make bad assumptions about the current work directory.

The only difference between system() and the command line is that the shell is interactive in the later. This can affect which startup files the shell executes, which could affect stuff like aliases.

Finally, the command you're running via system might be different than the one you run from the command line. You should check the contents of the relevant variables.

And that's assuming you're running the command as the same user.

  • Comment on Re: Why doesn't system("zip -D") exclude directories?

Replies are listed 'Best First'.
Re^2: Why doesn't system("zip -D") exclude directories?
by YuTsun (Initiate) on May 05, 2010 at 18:58 UTC

    Thank you. As near as I can tell, though, the relevant environments are the same (I'm self-taught though, so that may not be saying much).

    With the variables expanded, the command line looks like this, whether called from system() or from the commandline:

    /usr/bin/zip -D /var/apache2/htdocs/appspace/output/test.zip /var/apac +he2/htdocs/appspace/output/*.[Mm][Ii][Ff] 1>>/var/apache2/htdocs/apps +pace/log/job.log 2>>/var/apache2/htdocs/appspace/log/error.log

    I run both the command line and the script in /var/apache2/cgi-bin, and both run as "root". Moreover, the behavior is identical on my Mac OS X laptop and on a remote Solaris 11 server. I am using the same "zip" in each case, as nearly as I can tell:

    # which zip /usr/bin/zip

    Is there some shell variable that might affect this other than which executable shell points to in each case?

      Using the same paths as you (except for adding a leading /tmp), I was unable to replicate your problem.

        Thank you. That was the information I needed.

        Embarrassingly enough, I seem to have misread man zip. Your original solution--working directory--is right.

        I am humbled.

      Reading zip manual: there might be ZIPOPT variable holding options for zip.

        I first thought so, too.  But what option should be set in ZIPOPT, and in what environment, to explain the behavior the OP is getting?

        On the command line, where -D works as expected, no options in ZIPOPT would be needed, as -D is sufficient to get rid of the undesired directory entries.

        In the CGI environment, where -D appears to have no effect, what option would override the effect of -D on the command line? I couldn't find one, in particular, as options on the command line presumably have higher precedence anyway.  Also, why would ZIPOPT be set in the CGI environment? Of course, you never know... but more typical would be to have it set for the command line, e.g. in the shell's login profile.

        ___

        P.S.: my version of zip (2.32/Ubuntu) always produces identical zip files (when I compare them binary, that is), without any additional directories, irrespective of whether I use -D or not (on the command line, or in ZIPOPT) — despite the man page claiming that "directory entries are created by default". In other words, the OP's problem might also simply be related to a bug in the zip program...

        $ /usr/bin/zip -D test1.zip /usr/local/lib/perl5/5.10.1/*.p[ml] adding: ... $ /usr/bin/zip test2.zip /usr/local/lib/perl5/5.10.1/*.p[ml] adding: ... $ ls -l test1.zip test2.zip -rw-r--r-- 1 almut almut 526059 2010-05-06 01:23 test1.zip -rw-r--r-- 1 almut almut 526059 2010-05-06 01:23 test2.zip $ cmp test1.zip test2.zip (no output) $ md5sum test1.zip test2.zip # just in case cmp is wrong :) aa105cb65d74b31e4da18b2bd1a027d6 test1.zip aa105cb65d74b31e4da18b2bd1a027d6 test2.zip