@_ zero byte problem

I have a sub where I pass in a "binary" and write it to a file


something like:

sub storeImage{
my ($image) = @_;


open(IF,">$ENV{DOCUMENT_ROOT}/test.jpg") or die "$!";
binmode IF;
while (read($image,$Buffer,1024)){print IF $Buffer;}
close (IF)|| die "$!";
}

Now, when I run that it prints a 0 byte file, it didn't used to.

If I modify the script to shift it off like this:


sub storeImage{

my $image=shift;
....}

This works correctly. What has changed on this server that this is
now failing?

Sometimes I like to use @_ because if you have a null element in the
middle of a list being passed in you get it in the correct order while
shifting off a list will get this wrong.

Jeff

Re: @_ zero byte problem

On 10/03/2007 08:03 PM, Jeff wrote:
> I have a sub where I pass in a "binary" and write it to a file
>
>
> something like:
>
> sub storeImage{
> my ($image) = @_;
>
>
> open(IF,">$ENV{DOCUMENT_ROOT}/test.jpg") or die "$!";
> binmode IF;
> while (read($image,$Buffer,1024)){print IF $Buffer;}
> close (IF)|| die "$!";
> }
>
> Now, when I run that it prints a 0 byte file, it didn't used to.
>
> If I modify the script to shift it off like this:
>
>
> sub storeImage{
>
> my $image=shift;
> ....}
>
> This works correctly. What has changed on this server that this is now
> failing?
>
> Sometimes I like to use @_ because if you have a null element in the
> middle of a list being passed in you get it in the correct order while
> shifting off a list will get this wrong.
>
> Jeff

I don't know what's wrong with the server, but try this:

my $image = $_[0];

Even better, use File::Slurp;

use File::Slurp;

sub storeImage {
my $image = shift;
write_file("$ENV{DOCUMENT_ROOT}/test.jpg", $image);
}

Is that not simpler? :-)

If you're still curious about what is in @_, use Data::Dumper:

use Data::Dumper;

sub storeImage {
print Dumper(\@_);
}

Re: @_ zero byte problem

On Oct 4, 2:03 am, Jeff wrote:

> something like:
>
> sub storeImage{
> my ($image) = @_;
>
> open(IF,">$ENV{DOCUMENT_ROOT}/test.jpg") or die "$!";
> binmode IF;
> while (read($image,$Buffer,1024)){print IF $Buffer;}
> close (IF)|| die "$!";
>
> }
>
> Now, when I run that it prints a 0 byte file, it didn't used to.
>
> If I modify the script to shift it off like this:
>
> sub storeImage{
>
> my $image=shift;
> ...}
>
> This works correctly.

There is no reason in the above code why the two should be different.
Either there's something you are not showing us or this is a bug in
Perl.

Please post a _minimal_ but _complete_ script to illustrate the
problem. Indicate also which version of Perl you are using.

> What has changed on this server that this is
> now failing?

I'd guess permissions,

> Sometimes I like to use @_ because if you have a null element in the
> middle of a list being passed in you get it in the correct order while
> shifting off a list will get this wrong.

Please produce a _minimal_ but _complete_ test case for that too, as
if what you say were true this too would be a bug in Perl.

Re: @_ zero byte problem

On 2007-10-04 01:36, Mumia W. wrote:
> On 10/03/2007 08:03 PM, Jeff wrote:
>> I have a sub where I pass in a "binary" and write it to a file
>> something like:
>>
>> sub storeImage{
>> my ($image) = @_;
>>
>>
>> open(IF,">$ENV{DOCUMENT_ROOT}/test.jpg") or die "$!";
>> binmode IF;
>> while (read($image,$Buffer,1024)){print IF $Buffer;}
>> close (IF)|| die "$!";
>> }
>>
>> Now, when I run that it prints a 0 byte file, it didn't used to.

Check for errors.

> I don't know what's wrong with the server, but try this:
>
> my $image = $_[0];

How should this be different from my ($image) = @_;? (But I don't
understand why shift should make a difference, either)

From the use of $ENV{DOCUMENT_ROOT} I guess that this is a script using
the CGI module, and that the parameter of storeImage is the result from
param('file_upload_parameter'), which is magic and sometimes behaves
strangely. perldoc CGI says:

However, there are problems with the dual nature of the upload fields.
[...]
To be safe, use the upload() function (new in version 2.47). When
called with the name of an upload field, upload() returns a filehandle,
or undef if the parameter is not a valid filehandle.


> Even better, use File::Slurp;
>
> use File::Slurp;
>
> sub storeImage {
> my $image = shift;
> write_file("$ENV{DOCUMENT_ROOT}/test.jpg", $image);
> }

That's not the same. In the OP's code, $image is (or should be) a file
handle, from which data is copied. write_file expects a string here.


> Is that not simpler? :-)

For every problem there is a solution which is simple, neat, and wrong.
:-)

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

Re: @_ zero byte problem

On 10/05/2007 02:29 AM, Peter J. Holzer wrote:
>
> That's not the same. In the OP's code, $image is (or should be) a file
> handle, from which data is copied. write_file expects a string here.
>

Oh yes. I completely overlooked Jeff's while statement wherein he used
read(). I read his text, and he said he was passing in a "binary."