I will put in the entire script here

Why?! Please post the minimum amount of code required to replicate the problem.

And why do you think it's a good idea to forgo adding error checking when something doesn't work?

Did you even check the error log for messages?

By the way, you messed up the readmore tags. They aren't part of your code.

Thanks. I'm fixing the Readmore stuff. I tried to post the minimum with readmore. I did think it was a good idea to get rid of error checking. Sorry, I'm a newbie, I just want it to work first. I looked for the logs. Haven't found them yet. I will look again. That's probably the best place to look, thanks.

Sorry, I'm a newbie, I just want it to work first.

This is a not uncommon, but utterly wrong-headed "newbie" notion.

Error checking, like the use strict and use warnings pragmas, is helpful in getting "it to work....", not some sort of add-on for use afterwards.

I'm trying to execute the unzipper from a command in a popular upload script.

And for some reason, that "unzipper" is named "no-frills.exe". Okay, fine. When I searched your code for "no-frills", I found this line (not quite half-way down, at line #464):

open my $wfh, "| no-frills.exe $uploadedfile";
[download]

What would you expect to happen, given that the pipeline file handle receives no input?

BTW, while you're fixing that, you might also want to give the full path name to the program when opening the pipe -- there's no guarantee that the web server process knows where it is (has this program in its execution PATH).

I tried to execute the unzipper with back ticks/quotes too and it didn't work.

`no-frills.exe $uploadedfile`;
[download]

I just want to unzip a file first. I have a lot more additional (also sloppy but it works) code to add but I can't proceed if I can't get the script to execute an unzip...

Thanks very much for the valuable suggestion to try the full path. We'll see if that helps.

system('no-frills.exe', $uploadedfile)
   or die("no-frills: $?/$!\n");
[download]

Using the multi-argument form of system will help handle non-trivial file names.

Make sure the current work directory is what you expect it to be.

Pete, I am a newbie squared. The script is mostly canned stuff from a commercial vendor, not me. This exercise is for me and my purposes. Yes it would certainly be scary if I was providing this Perl script (at least my little part) as a service.

I'm sorry then, my comments should be redirected to the "commercial" vendor that is releasing low-quality code. Or at least code that does little to inspire confidence in its quality.
I would suggest that your first course of action should be to add use strict and use warnings to the top of the script and fix any problems that fall out from doing so.


-pete
"Worry is like a rocking chair. It gives you something to do, but it doesn't get you anywhere."

Hmm...Maybe not. It's freeware but maybe not postable. How do I take it down?

From the 755 permissions you mention, it seems that you're on a unix-like system; yet the executable you mention ends in .exe, which is typically used for dos/windows executables.

Are you sure the executable is compatible with the OS on your host?

Ahh! I think that's the answer. Sorry for being so dense to miss this one.

I would try creating a very simple test script, with the full path and filename hardcoded, etc, just to prove that the unzipper utility will do what you want.

Assuming that it turns out to be incompatible with the host's system, you're going to need to handle the unzipping yourself. Never fear, someone has already done all the hard work for you and put it on CPAN. I'd suggest trying IO::Uncompress::AnyInflate for simple gzip/zip type files.

The reason I have been using no-frills.exe (based on Delphi Zip) and also CakeCmd.exe, is that they are tolerant of zip corruption. I am trying to unzip corrupt Word and Excel 2007 files, which are in a zipped state. I've tried zlib, it does not unzip corrupt docx and xlsx files even after using the repair function it has.