exec("zip ...) works very infrequently.

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View


I'm running a PHP script on my ISP's server to zip some files. I can exec
'unzip', 'touch' and 'rm' to my hearts content, but when I try any of:

exec("zip -j ./Secure/$zipfilename ./Secure/Temp/*");
exec("zip -j ./Secure/$zipfilename ./Secure/Temp/* 2>&1");
exec("zip -j ./Secure/$zipfilename ./Secure/Temp/* > /dev/null 2>&1 & echo

...the results are the same. Once in a very long while it works and I get
the requested archive, but most of the time nothing happens!

My directory and file permissions are:

./Secure                         drwxr-xr-x
./Secure/$zipfilename     -rw-rw-rw-
./Secure/Temp               drwxr-xr-x
./Secure/Temp/*            -rw-rw-rw-

...but they don't seem to be the problem (?).


Any clues anyone?


Re: exec("zip ...) works very infrequently.

Op 31-12-2009 21:02, Murray R. Van Luyn. schreef:
Quoted text here. Click to load it






Re: exec("zip ...) works very infrequently.

Quoted text here. Click to load it

Hi Luuk,

Thanks very much for the links. Unfortunately my ISP only has 'zip'
installed and not the desired 'ziparchive'. Hence, the reversion to shell


Re: exec("zip ...) works very infrequently.

Quoted text here. Click to load it

Hi Luuk,

Thanks again for the link.

Gee, the documentation for PHP is really good, isn't it? I especially like
the user contributions that www.php.net let you add to various sections. If
you're having a problem with a command, chances are someone else has already
encountered it and posted a solution for others to read. That's a really
smart way to run a documentation site.

I love PHP!


Re: exec("zip ...) works very infrequently.

Op 1-1-2010 8:45, Murray R. Van Luyn. schreef:
Quoted text here. Click to load it

in the same manual:

So, you might add a second parameter to the 'exec' function.
This way you will able to see the output of the exec command

for example: "bash: zip: No such file or directory"
"zip warning: name not matched: <some-filename>"


Re: exec("zip ...) works very infrequently.

Quoted text here. Click to load it

Hi Luuk,

That's a good suggestion. Yeah, I tried a couple of things such as:

echo exec("zip -j ./Secure/$zipfilename ./Secure/Temp/*");

exec("zip -j ./Secure/$zipfilename ./Secure/Temp/* > output.txt");

exec("zip -j ./Secure/$zipfilename ./Secure/Temp/*", $output);
echo print_r($output);

...but couldn't get any output whatsoever! I agree that the best way to
efficiently solve the problem is to get all the debugging information
available, but for some reason there doesn't seen to be any available. Maybe
that's a clue in itself?

Thanks for the useful direction, Luuk. I appreciate you availing me of your
valuable experience.


Re: exec("zip ...) works very infrequently.

Op 1-1-2010 10:34, Murray R. Van Luyn. schreef:
Quoted text here. Click to load it

        $output = array();
        $return_code = 0;

        exec("zip $zipfilename /tmp/ftp*", $output, $return_code);
        echo print_r($output);
        echo "<br>\n". "Returncode: $return_code";

if $return_code <> 0 than something is wrong, use 'man zip' to see what
is wrong

i got a value of '15' because i was not allowed to overwrite my test.zip
in the tmp-folder ;-)


Re: exec("zip ...) works very infrequently.

Quoted text here. Click to load it

Hi Luuk,

Golly, you are being very kind to me going to all this effort, Luuk. Thank
you very much. :-)

Hmm...I'll have to try to remember to initialise my variables in the way
that you have done in your good example. Yes, the exec() return code might
be helpful also, so thanks for including it in the code snippet you have

Well I went the long way around and have a slightly better idea of what the
problem with the zip command is. When I run zip from a shell script, that I
initiate with PHP's exec() function, I can redirect the command's output to
a file for post-mortem analysis. The output reads "./touchzipfilepayloads:
line 6: zip: command not found". At least I have this important clue now,
whereas when I initiated zip directly within the PHP exec() function, I
unexpectedly got no textural output whatever.

I'll see what my ISP has to say about the apparent, predominately
un-locatable zip executable. They're not known for their fabulous customer
service, so I fear this may be where the current avenue of exploration ends.
At least I know the problem wasn't related to using PHP's exec() function to
initiate the zip command, so I can happily drop the shell script concept. I
also have a better idea of how to get good feedback from the exec() function
itself, so I'm very grateful for that too.

I'll try to let you know what happens.


Re: exec("zip ...) works very infrequently.

Luuk wrote:
Quoted text here. Click to load it

No, just:
Quoted text here. Click to load it

It also helps to format if you put your print_r() in <pre>...</pre>
tags, i.e.

   echo "<pre>\n";
   echo "</pre>\n";

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: exec("zip ...) works very infrequently.

Quoted text here. Click to load it
Hi Jerry,

Thanks very much for the helpful PHP tips. Yes, putting the extra echo
before the print_r() function was a mistake on my part. I copied that from
somewhere out on the Net before I confused everyone by reproducing it here.
It printed an extra 'i' character after the array contents, so obviously
it's not something I want.

Well, it's all very strange. My ISP's server seems to be able to find the
elusive zip command again for the moment. The following code snippet gives
me a nice printout of the zip command's progress message:

$output = array();
$return_code = 0;
exec("zip -j ./Secure/$zipfilename ./Secure/Temp/* ", $output,
echo "<pre>\n";
echo "</pre>\n";
echo "<br>\n". "Returncode: $return_code";

    [0] => updating: CFlash.c (deflated 77%)
    [1] => updating: Cflash_Header_Circuit.pdf (deflated 8%)
    [2] => updating: Cflash.pcb (deflated 83%)
    [3] => updating: CFlash.h (deflated 70%)
    [4] => updating: Cflash.chm (deflated 36%)
    [5] => updating: Header.chm (deflated 34%)
    [6] => updating: Cflash.tif (deflated 48%)

Returncode: 0

That's definitely a marked improvement over the previous result, so thank
you to all who made it possible.


Re: exec("zip ...) works very infrequently.

Quoted text here. Click to load it

Hi all,

Nope, my ISP has lost track of the zip executable again. My unenlightened
guess is that I'm being bounced around between different server machines, at
least one of which does not have the zip executable present (?). It's all a
bit of a mystery, one which I can faithfully rely on my wonderful ISP to


Re: exec("zip ...) works very infrequently.

Murray R. Van Luyn. wrote:
Quoted text here. Click to load it
Well of course, the joys of a  'professional' ISP versus hosting your
own server are that:

- they can be relied upon to have a backup mechanism that they assure
you is 100% reliable, but in fact is managed by a moron who regularly
loses the tapes.

- their security policy does not take account of the over worked
sysadmin, who left a glaring hole in it, and allowed a malicious co user
of the system to spread his spam code all across everyone's sites.

- the previous sysadmin, who left because of overwork and underpayment,
has left back doors and Trojans all over it, to show that he was a lot
smarter than his pay grade. And quietly circulates them on the Internet.
Revenge is a dish best served cold.

- because they are shirty bastards, they are a natural target for
hackers anyway.

- Any 'feature' they make available to you will be either so crippled as
to be useless, or yet another glaring security hole.

- any performance the machine might have had, will be nullified by a
bunch of users running overweight joomlas and virtue mart code on it.

host your own machine, mate. Either physically or as a virtual machine.
Shared hosting is crap by and large. It needn't be, it shouldn't be, but
it is.

Do your own backup.

That way, when things go wrong, its a technical issue you can solve. Not
a legal issue and a complete bloody nightmare.

AFAIAC, the stages are:

prototype on a machine on a private ADSL link. Its enough to show it works.

If bandwidth is not adequate, move to a hosted VIRTUAL server that you
can completely control. And mirror it onto your own local server for backup.

If that cant manage the requirement, put your OWN box up at a hosting

Re: exec("zip ...) works very infrequently.

Quoted text here. Click to load it

Hi NP,

Oh, I enjoyed that. I guess the poor sysadmin guy's do have a rough lot, but
you might expect a slightly higher level of service from a major national

I have a couple of sites running at GoDaddy.com. My only complaint with them
is the 4MB webpages you encounter whilst navigating the hosting management
portion of the GoDaddy.com website. It takes all day to get your e-mail on a
dial-up connection like mine. Other than that, I would certainly recommend
such a hosting provider. Their accounts are really well set-up, and easy to
manage (if you have broadband). I definitely wouldn't expect to be having
any of the problems I'm having with my ISP dealing with them. Super
professional in my humble opinion.

I suppose hosting one's own server would be the option that provides the
greatest functionality and flexibility. Every time I've gotten involved with
setting-up and running my own machine however, it's taken more time than I
really have available. You never really seem to get on top of it. I guess I
should be more considerate of those that will run a shared system.for
others. I just wish they would make themselves a little more accessible,

Hmm...PHP's exec() function will return the console output message from any
program which it runs. Should the shell fail to run the program however, ie
it can't be located in the path, then any warning message from the shell
will be entirely lost. The only indication that something has gone wrong is
in the non-zero return code:


Returncode: 127

It's interesting to note that attempts to log program output to a file fail
when the executable doesn't run after being initiated with exec():

exec("zip -j ./Secure/$zipfilename ./Secure/Temp/* > output.txt");  //
output.txt is empty when call fails

...but when the same logging process is employed within a shell script, then
the shell's failure message is faithfully logged in place of the program's
expected output:

zip -j ./Secure/$zipfilename ./Secure/Temp/* > output.txt  // output.txt
says "zip: file can't be found" message from shell.
exit 0

Not what I would have expected. Well, I don't expect to have much more
difficulty debugging exec() calls when they go wrong, and I now have some
worthy experience of what to try when I do.

I've learnt a bundle with this experience, guy's. Thank you all so very much
for allowing me to share, and for helping me through it. I don't think I
would have cracked it without the diversity of perspectives that have been
generously made available to me.


Re: exec("zip ...) works very infrequently.

On Sat, 2 Jan 2010 01:01:23 +0800, Murray R. Van Luyn. wrote:
Quoted text here. Click to load it

Hint: Poke around and see if they have a 'mobile' URL access.
I have the same bloated 'experience' with Comcast's email access (which
I use very infrequently.)
The 'mobile' URL is
            http://m.comcast.net /

Other possible URLs might be mob.example.com or mobile.example.com.

(I use `fetchmail` , under normal circumstances, to pull what little
email I get at Comcast over into my _real_ ISP shell account.  It's
just when my _real_ ISP's mailserver or shell host goes kah-kah (very
rarely) that I might need to use Comcast email directly.)

  ((And, before you ask, _no_ -- they are not taking on any new shell

  Marvin L Jones    | jonz          | W3DHJ  | linux
   38.24N  104.55W  |  @ config.com | Jonesy |  OS/2
    * Killfiling google & XXXXbanter.com: jonz.net/ng.htm

Re: exec("zip ...) works very infrequently.

Murray R. Van Luyn. wrote:
Quoted text here. Click to load it

well, no!

There are in my experience three sorts of ISP.

(1) totally pro outfits. People like oracle and IBM who run the sort of
hosting center that makes your eyes water. Absolutely by the book, no
nonsense top salaried admins, bound in blood to contracts that will see
them terminated if so much as one bit of customers private data drips
onto the floor. Use by banks etc.

(ii) so call 'major national ISP's whose contracts look exactly like
those of the above, but whose prices are mysteriously 50% less, (or
more). Some are better some are worse, but I know of no way to tell,
till things go wrong. And then its too late to change.

(iii) extremely small outfits, who have a room in a dark office, full of
cheapish servers and half a dozen dedicated owners of the company who
also run the systems, using sheer hard work, and man hours to produce
the quality they cant afford to buy off the shelf. Guarantees are less,
but the actual customer service is IME better, and the reliability
higher, than the 'major national ISP'. Simpply because the company is
owned and run by the same people. Its their livelihood: If they lose
you, they feel it straight in their pockets. That's the whole thing
about large organisations. employees come and go, their loyalty is to
themselves, their egos and their careers, and to the next employer. They
otherwise often dont give a shit. If they stay till 4 a.m. to restore a
machine from the few tapes the moron HAS managed to find, will they get
a bonus? Nope. It will simply be a good reason to not fire the moron!

The only way to counter the fact that a direct employees interest do not
coincide with the organisations is to implement massive policies and
strict guidelines. These are expensive. And inefficient. The worst of
all possible worlds is somewhat in between. Its not cheap, the staff are
not motivated, and the service is not good. And the systems are not
really fool proof.

Such componies make money by massive marketing: its cheaper to spend a
million on national advertising and get 10,000 more customers, than it
is to spend  a million on staff wages and better systems, and keep the
ones they have already.

The small outfits cant afford ANY advertising. They have to keep their
customers happy, and hope that word gets around.

Quoted text here. Click to load it
YMMV. I needed to proto sites for people. I already had a machine. It
runs several sites. The friends and family customers think its fast
enough, and reliable enough, and don't complain at the zero cost.

Should they ever start to smash my bandwidth, then they will have to pay
to move their sites.

It's got a full backup policy, that I know works. Its better uptime than
one of them got on their 'fully hosted service' - down for three days
and all data lost bar the database, when someone hacked it.Not their
site, The whole damned machine.

Quoted text here. Click to load it

Thats the spirit!

Quoted text here. Click to load it

If its a unix/linux host, lookup the 'which' command. and the Uname command

This may provide you with conrete evidence as to where teh zip
executable is, on any given instance of te a given server.

Your ISP cant walk a way from that one. If lack of zip executable is teh

My experience with these larger outfits is that somewhere within them,
is a man who does actually know what he is doing, but he is surrounded
by support droids whose business is to stop you reaching him.

Or her, these days. Ra for femlib! Anyway a detailed dump that the droid
cant understand, usually shuts them up and forces them to escalate the

I'll share with you a story..the company..was Interactive Unix IIRC. The
product was an X server to run on a SCO Unix platform. It didn't.

Call to UK distributor support centre 'I am sorry sir, da bios he is
incompatible' In other words., fob me back to the hardware and blame the
vendor. In barely comprehensible pidgin english.

Call to US support code centre. 'Ah, hang one while I get the source
code, yep..where does it crash again, Right that's where its testing the
maths co processor' 'But I haven't got a maths co processor' 'well if
its got there, it thinks you have. There's probably a jumper on the
board you need to set to tell it you haven't'.

THAT is support!

Same deal with Cisco. Couldn't get ISDN working. Cisco local hadn't a
clue. Cisco US gave me a bloke who listened politely and said 'set the
ISDN type to net3 (or something along those lines) 'Are you sure that
will work' 'Sure did when I spent three weeks in 5 countries in europe
testing my code'

THAT is support.

I don't get that from 'major national ISP's'. I get it from seriously
large IBM type organisations, and I get it from 3 man and a dog outfits.

I cant afford serious IBM style organisations


Re: exec("zip ...) works very infrequently.

.oO(Murray R. Van Luyn.)

Quoted text here. Click to load it

The problem seems to be that exec() doesn't capture the error device
STDERR, where such messages usually appear. But you can tell it to
redirect both the standard output STDOUT and STDERR to a file for
example. The possible redirections are described here:


Quoted text here. Click to load it

Use 2> to log just STDERR or &> to log both STDOUT and STDERR.

You can also use 2>&1 without a filename and add a second parameter to
exec(), which will then capture all the output.

Quoted text here. Click to load it

The message should appear on screen and output.txt should be empty like
in the first example above - in both cases there's no content on STDOUT
that could be captured.


Re: exec("zip ...) works very infrequently.

.oO(The Natural Philosopher)

Quoted text here. Click to load it

Improperly set-up servers, run by spare time "admins" are a much easier
and cheaper target.

Quoted text here. Click to load it

A good host listens to his customers. If something is missing or broken,
drop them a note (politely) and it will be fixed or added if possible.

Quoted text here. Click to load it

There are ways to prevent that. A good host doesn't just make promises,
but keeps them and actually delivers what you pay for. If you're not
satisfied, change to another host. Usually the smaller companies offer
a much better service and reliability than the big players.

Quoted text here. Click to load it

A root server in the hands of an unexperienced is a time bomb. You don't
become a sysadmin over night just by reading a book.

Quoted text here. Click to load it

Yes, but nothing more. An ADSL uplink is just ridiculous when compared
to the bandwidth of a real server's connection. But if your visitors
have the time to have a tea or two while waiting for your site ...

Quoted text here. Click to load it

A paradise for script kiddies. There are reasons why _managed_ servers
are recommended if you want to run your own machine.


Re: exec("zip ...) works very infrequently.

Michael Fesser wrote:
Quoted text here. Click to load it

..so don't code with overweight javascript libraries, huge flash movies,
  and so on.

Heck, the first shared host server I built ran on 256Kbps and ran 50
sites!! In those days, not many people had that bandwidth for anything.

The first one that moved, did so because his flash movies were ***ing
the link.

A typical page on any server should be no more than 15-60kbytes. Only
big images need more than that, or heavy JavaScript libraries, and its
questionable as to whether you SHOULD be using heavy JavaScript
libraries on any site that serves a public that may not have JavaScript

A decently compressed 1024x768 image is well under 100kbytes. less than
a second to push down a 448k link. And a lot less latency than many a
big hosting centre can provide.

Now if the site is getting more than a hit a second on big images, its
sure is generating enough money to move.

Quoted text here. Click to load it

why? You can strip it dwon to only what is required, you can set up a
firewall so that only you from your IP address can get to it?

You can in principle set up a VPN to it, ify ou are that paranoid. Its
WAY more secure than a shared hosted server.

Quoted text here. Click to load it

yes, because you are even dumber than the admins that run it.

Of course that's what the big hosting centers *want* you to think: that
they somehow have some special knowledge and approach that makes their
expensive bloated solution better than anything you might do yourself.

whereas its INHERENTLY insecure by virtue of the fact that it is
publicly accessible at a much deeper level of privilege than a machine
on a private network whose ONLY connection to the outside world is via
its USER facing web pages.

Or a virtual machine that has been set up to have precisely similar

Quoted text here. Click to load it

Re: exec("zip ...) works very infrequently.

Murray R. Van Luyn. wrote:
Quoted text here. Click to load it

That's possible,  guess.  But there are other possibilities just as
likely - like maybe the zip just isn't in your path for some reason.

Try using the absolute path to the zip executable.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: exec("zip ...) works very infrequently.

Murray R. Van Luyn. wrote:
Quoted text here. Click to load it

You're not saving the output of the command.

Quoted text here. Click to load it

Redirection is performed by the command processor.  exec() does not
invoke the command processor, so your output is not redirected.

Quoted text here. Click to load it

This should work, except you don't "echo print_r()".  print_r() writes
the data itself.

Additionally, you should look at the return code from the exec() command.

Quoted text here. Click to load it

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Site Timeline