CGI -upload and Perl 5.8?
I copied some Perl code about a year ago to do a file upload to an apache server file system. In 5.6, the system worked fine. Now in 5.8, I'm getting a failed filehandle read with the CGI-upload function. Here is the code: use CGI; use Fcntl qw(:DEFAULT :flock); $CGI::POST_MAX = 1024 * 1024 * 1024;#1 gig my $maxTries = 10; my $query = new CGI; #grab file handle from form my $fileHandle = $query-upload($fieldName); my $fileName = $fileHandle; Again, this worked perfect before 5.8. Any clues on the proper use? Thanks, mark
Re: error catching and hashes
[EMAIL PROTECTED] (Wren Argetlahm) writes: I've recently discovered the joys of return undef; for error catching, but I'm having problems when the subroutine returns a hash (unless there's an error). Something like the following: %hash = subroutine($input) or error($error); returns the expected odd number of elements in hash assignment warning. Is there a way around this aside from returning a hash reference instead? is there any particular reason to/not to return a reference instead? This is because 'return undef;' is good, but 'return;' is better. It returns the correct, context dependent representation of false.
confusing bullets
Now and then I copy data from the web and paste it into a perl script after __END__ or __DATA__. I plan to take the data apart with perl. The file is generally a BBEdit text file with unix line feeds. Sometimes there are bullets in the data. According to HexEdit these bullets are \xca characters, but when I try to spot these characters with m/\xca/ I find none. So I look at a line that contains just a bullet, nothing more. HexEdit shows that line as CA 0A, a bullet and a new line. On the other hand perl says that the line has length 3. Using ord I see that the line consists of C2 A0 0A. To prove its point perl has no trouble finding all bullets with the pattern m/\xc2\xa0/. What is going on here? HexEdit sees one byte for each bullet and perl sees two. I thought hex stuff was unambiguous, but, as a mathematician, I am pretty certain that 1 is not equal to 2. Regards, Vic -- *---* mailto:[EMAIL PROTECTED] | Victor Thane Norton, Jr. | Mathematician and Motorcyclist | phone: 419-353-3399 *---* http://vic.norton.name
Re: confusing bullets
At 11:22 am -0500 10/1/04, Vic Norton wrote:
What is going on here? HexEdit sees one byte for each bullet and perl
sees two. I thought hex stuff was unambiguous, but, as a mathematician,
I am pretty certain that 1 is not equal to 2.
Perl talks UTF-8. The bullet in utf-8 is chr (8226) \x{2022}
perldoc -X encoding | more
TMTOWTDI but it sounds as though you'd like to
work as though Unicode didn't exist and something
like this might be simplest.
binmode(STDOUT=':encoding(MacRoman)') ;
my $display_in_dumb_editor = 1 ;
my $f = '/tmp/bullet.txt' ;
open F, $f;
print F Here's a bullet \r ;
`open -a 'simpletext' $f` if $display_in_dumb_editor;
close F ;
open F, $f ;
for (F) {
// and print Got one ! or print :-
}
PS. for anyone rash enough, like me, to have
installed 5.8.3 and having problems finding
CongigLocal.pm, this will solve the problem:
enc2xs -C
JD
Re: error catching and hashes
--- Piers Cawley [EMAIL PROTECTED] wrote:
This is because 'return undef;' is good, but
'return;' is better. It
returns the correct, context dependent
representation of false.
That seems to have fixed my problem, but I'm not sure
why it works. My error($error) is now something to
the effect of {print shift; return;}, but why does
that return false?
~wren
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: error catching and hashes
On 1/10/04 wren argetlahm wrote:
--- Piers Cawley [EMAIL PROTECTED] wrote:
This is because 'return undef;' is good, but 'return;' is better. It
returns the correct, context dependent representation of false.
That seems to have fixed my problem, but I'm not sure why it works. My
error($error) is now something to the effect of {print shift;
return;}, but why does that return false?
See below. If the stuff about context isn't totally clear to you, that would be a good
area of Perl to study. That's what Piers was referring to above.
from perldoc -f return
return EXPR
return
Returns from a subroutine, eval, or do FILE
with the value given in EXPR. Evaluation of EXPR may be in list,
scalar, or void context, depending on how the return value will be
used, and the context may vary from one execution to the next (see
wantarray). If no EXPR is given, returns an empty list in list
context, the undefined value in scalar context, and (of course) nothing
at all in a void context.
(Note that in the absence of an explicit return, a subrou- tine,
eval, or do FILE will automatically return the value of the last
expression evaluated.)
(END)
1;
- Bruce
__bruce__van_allen__santa_cruz__ca__
Re: confusing bullets
I'm sorry, John. I was talking figuratively. I didn't mean real bullets.
How come Perl sees C2 A0 whenever HexEdit sees CA and visa versa?
I don't care what kind of characters we are talking here. To
paraphrase Gertrude Stein, a byte is a byte is a byte. At least
that's what I thought until now.
Regards,
Vic
At 5:33 PM + 1/10/04, John Delacour wrote:
At 11:22 am -0500 10/1/04, Vic Norton wrote:
What is going on here? HexEdit sees one byte for each bullet and perl
sees two. I thought hex stuff was unambiguous, but, as a mathematician,
I am pretty certain that 1 is not equal to 2.
Perl talks UTF-8. The bullet in utf-8 is chr (8226) \x{2022}
perldoc -X encoding | more
TMTOWTDI but it sounds as though you'd like to work as though
Unicode didn't exist and something like this might be simplest.
binmode(STDOUT=':encoding(MacRoman)') ;
my $display_in_dumb_editor = 1 ;
my $f = '/tmp/bullet.txt' ;
open F, $f;
print F Here's a bullet *\r ;
`open -a 'simpletext' $f` if $display_in_dumb_editor;
close F ;
open F, $f ;
for (F) {
/*/ and print Got one ! or print :-
}
PS. for anyone rash enough, like me, to have installed 5.8.3 and
having problems finding CongigLocal.pm, this will solve the problem:
enc2xs -C
JD
Re: confusing bullets
On Jan 10, 2004, at 9:26 PM, Vic Norton wrote: How come Perl sees C2 A0 whenever HexEdit sees CA and visa versa? I don't care what kind of characters we are talking here. To paraphrase Gertrude Stein, a byte is a byte is a byte. At least that's what I thought until now. Like John said - text encoding. The file you're viewing with HexEdit is most likely encoded using MacRoman, or possibly ISO 8859-1. Internally, Perl uses UTF8 encoding. Try this: Create a new text file in BBEdit, and enter a bullet (opt-8). Save it using the default text encoding. HexEdit shows a single byte in the file: A5. Now, open the file again, and save a copy of it using UTF8 encoding with no byte-order mark. HexEdit now shows *three* bytes: E2 80 A2. And, you have to tell BBEdit what encoding the file uses when you open it - without the byte-order mark, BBEdit can't tell it's UTF8. Just for grins, save it again, this time *with* the byte-order mark. HexEdit now reports *six* bytes in the file: EF BB BF E2 80 A2. In other words, yes - a byte is a byte is a byte. But you're not working with bytes, you're working with text. A character is not always a byte. It can be several bytes, depending on how it's encoded. sherm--
