Upload file fails

[Stefan Braun]

Hello,



I'm trying to upload files (pictures) from browser to server using a perl
script.



If I run the script under windows/apache it works perfect. If I run the
script under linux/apache I get a empty file.



The relevant part of the script:



my $file = $cgi->param("myfile");



my $fname = 'file_'.$$.'_'.$ENV{REMOTE_ADDR}.'_'.time;
open DAT,'>'.$fname or die 'Error processing file: ',$!;



binmode $file;
binmode DAT;



my $data;
while(read $file,$data,1024) {
print DAT $data;
}
close DAT;



In the errorlog is no entry



Thanks for your ideas





Stefan

 

[Charlton Wilbur]

PG> Do not use binmode for Unix / Linux systems.

From perldoc -f binmode on perl 5.8.8, second and third paragraphs:

On some systems (in general, DOS and Windows-based systems)
binmode() is necessary when you're not working with a text file.
For the sake of portability it is a good idea to always use it
when appropriate, and to never use it when it isn't appropriate.
Also, people can set their I/O to be by default UTF-8 encoded
Unicode, not bytes.

In other words: regardless of platform, use binmode() on binary
data, like for example images.

There's further discussion there, but I assume you can find it and
read it yourself.

Charlton

 

[Bart Lateur]

Do not use binmode for Unix / Linux systems.

binmode on Unix does nothing. But it doesn't hurt.

Test and discover if this resolves your problem.

It won't, because binmode is a noop.

 

[Bart Lateur]

I'm trying to upload files (pictures) from browser to server using a perl
script.

If I run the script under windows/apache it works perfect. If I run the
script under linux/apache I get a empty file.

I think it must be a webserver configuration issue. In other words:
don't blame your script. Once you find the proper webserver
configuration, it'll likely just work.

 

[Gunnar Hjalmarsson]

I'm trying to upload files (pictures) from browser to server using a perl
script.

If I run the script under windows/apache it works perfect. If I run the
script under linux/apache I get a empty file.

Try the CPAN module CGI::UploadEasy. It's not known to have that limitation.

 

[Charlton Wilbur]

PG> What version of Perl is the originating author using? What
PG> version of CGI.pm is the originating author using?

PG> You do not know, yes?

Largely irrelevant; the "don't bother with binmode on Unixlikes"
advice is outdated. If it's a situation in which the binmode
statement is a no-op, having it in won't hurt; if it's a situation in
which binmode actually does something, leaving it out will hurt.

Charlton

 

[Charlton Wilbur]

PG> Are you factually stating there are no systems in use which
PG> are binmode sensitive?

Exactly the opposite, actually; there are many systems in use which
*are* sensitive to binmode. Including some that formerly were not.

PG> I am very skeptical about your statements. You are informing
PG> readers there are no longer any systems, no longer any reasons
PG> to be concerned about binmode being used, or not used.

Er, no. I'm informing readers of exactly the opposite - that when
they expect binary data, they should use the binmode statement.
You're the one advising people to omit them.

PG> Your statements are based upon a premise all systems,
PG> literally all systems run the most recent operating systems
PG> and most recent versions of Perl and based upon a premise
PG> there are no systems found which are binmode sensitive.

No, it's based on the *fact*, documented in the perldocs, that with
various encodings and line disciplines, it's relevant to indicate to
the system whether you expect the file to be binary or text.

Given that I'm advising people to follow the directions in the
perldocs -- namely, to use binmode when you expect binary data, and
not to use it otherwise -- I'm not sure why you're tilting at this
particular windmill. All the world can no longer be safely assumed to
run in ASCII, and input and output layers can make binmode meaningful
even on Unixlikes.

My premise is that when you expect to deal with raw binary data, you
use binmode, as documented in the perldocs. When you expect to deal
with text, you do not. On systems where this does not matter, the
binmode statement is a no-op; on systems where this does matter, the
binmode statement is meaningful. The use of different encodings and
input and output layers means that binmode is meaningful even on
systems where it formerly was not.

What it boils down to is this.

Some systems do not distinguish between text and binary files. On
these systems, using binmode does not change anything.

Other systems *do* distinguish between text and binary files. On
these systems, not using binmode causes problems.

And there are many systems which *formerly* did not distinguish
between text and binary files, but which are now. In particular, you
will get different results if you treat files encoded in UTF-8 or
UTF-16 as binary files than if you treat them as text files.

None of this is based on assuming that the whole world has ceased to
distinguish between binary and text files. On the contrary, it's
based on the evidence that text encodings are not all ASCII anymore.

It's also not based on assuming that the whole world is running 5.8.8.
On the contrary, it's based on future-proofing the script. Sooner or
later, that script is going to be run in a different environment --
possibly because a sysadmin upgraded to 5.8.8 without sending you the
memo - and it's better to be clear about what you intend and expect,
or it is likely to break.

Charlton

 

[Charlton Wilbur]

PG> (snipped - read thread for full context)

PG> You are practicing deceit. I wrote no such advice.

From (e-mail address removed), posted today:

PG> Do not use binmode for Unix / Linux systems.

PG> Which prompts a question. Previously you critique my advice
PG> based on a premise my suggestion to remove binmode code for a
PG> Linux machine is not needed. Currently you are writing
PG> precisely what I previously wrote; remove binmode when not
PG> needed. Why is this?

Because "not needed" is different in the two situations.

You're advising people to omit binmode when on a Linux machine. I'm
advising people to omit binmode when they're expecting textual data.

Continue your logorrhea if you will. I've made my point, and you've
demonstrated that you're unable or unwilling to understand it.

Charlton

 

[Stefan Braun]

Hello,



Thank for your help.



It's a SuseLinux with kernel 2.4.7 with Perl 5.6.1.



I tried the script on an other Linux (Redhat) and it works. I think the
problem is the apache configuration of our server.



Thanks



Stefan

 

[Peter Wyzl]

(snipped - read thread for full context)


You are practicing deceit. I wrote no such advice.

I find it fascinating that you still, after all these years, demonstrate a
complete failure to understand even relatively simple techno speak and yet
still persist in having rambilng arguuments which only demonstrate your
complete separation from reality.

Despite the repeated case that your offered solution bears not the slightest
relevance to the actual problem.

Though why you accuse people of deceit when it is patently obvious you can't
string a series of cohesive thoughts together is a little bewildering.

P

 

[Joe Smith]

This is confusing. What reason would you offer readers
for them to include Perl code which performs no function?

Yes, it is good advise for creating portable programs.
It means that the same script can be run, unmodified, on systems
where binmode does something and systems where binmode does not.

Are you stating there is not a single system in use which
will be effected by a binmode statement, when not needed
in programming?

Yes, that is correct, in regards to Perl.

I am very skeptical about your statements. You are informing
readers there are no longer any systems, no longer any reasons
to be concerned about binmode being used, or not used.

Your statements are based upon a premise all systems, literally
all systems run the most recent operating systems and most recent
versions of Perl and based upon a premise there are no systems
found which are binmode sensitive.

Yes, it is true for Unix, and it is true for all ports of Perl
that came afterword. It is because Larry Wall declared what
binmode() should and should not do. Each programmer that ported
Perl to a different operating system was required to ensure that
binmode() works as documented. And it does.

-Joe

 

[Joe Smith]

The originating author is using a Linux system, yes?

It doesn't matter.

What version of Linux?

It doesn't matter, perl is designed to work the same on all of them.

Is this a dual boot Windows / Linux version?

It doesn't matter.

Is this Linux being run with Windows in the background?

It doesn't matter.

Is the author's system running VM Ware?

It doesn't matter.

Does binmode behave the same for all versions of Perl?

Yes. Any version where it does not work is defective, and is not
allowed to be distributed until the defect if fixed.

You do not know, yes?

Yes, we do know. The behavior of binmode() is completely under the
control of the programmer who created the new version. Said programmer
will ensure that the new version of perl runs all the tests without
errors before announcing this new version is ready. In the source files
that comprise perl are thousands of regression tests, including ones
that explicitly test for binmode() working as documented.

Most obvious problem is binmode.

The most obvious problem is that Purl Gurl believes she knows more
about Perl than the people who created it.

-Joe