Re: Apache::File correction
Rob Nagler [EMAIL PROTECTED] writes:
undef $/; # enable slurp mode
I think the local is pretty important, especially in mod_perl:
local $/;
This has the same effect (the undef is unnecessary). It's also a
good idea to enclose the code in a subroutine with error checking:
sub read_file {
my($file) = @_;
open(FH, $file) || die(error opening $file: $!);
local($/);
my($content) = FH;
close(FH) defined($content) || die(error reading $file: $!);
return \$content;
}
A similiar idiom that I saw recently:
sub file_contents {
my $fn = shift;
open(FOO, $fn)
or die file_contents: open($fn): $!\n;
my $stuff;
read FOO, $stuff, -s FOO;
close(FOO);
return $stuff;
}
Take your pick as to which one is clearer...
-Dom
--
| Semantico: creators of major online resources |
| URL: http://www.semantico.com/ |
| Tel: +44 (1273) 72 |
| Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: Apache::File correction
Martin Haase-Thomas wrote: [snip] Secondly I wonder whether local $/ = undef will have any effect. But I've never tried overriding Perl's predefined variables. regards Dear Martin, this is the well-known file-slurp mode. E.g.: undef $/; # enable slurp mode $_ = FH; # whole file now here s/\n[ \t]+/ /g; Look for slurp in your perl docs. Ernest -- * * VIRTUALITAS Inc. * * ** * * European Consultant Office * http://www.virtualitas.net * * Internationales Handelszentrum * contact:Ernest Lergon * * Friedrichstraße 95 *mailto:[EMAIL PROTECTED] * * 10117 Berlin / Germany * ums:+49180528132130266 * * PGP-Key http://www.virtualitas.net/Ernest_Lergon.asc
Re: Apache::File correction
undef $/; # enable slurp mode
I think the local is pretty important, especially in mod_perl:
local $/;
This has the same effect (the undef is unnecessary). It's also a
good idea to enclose the code in a subroutine with error checking:
sub read_file {
my($file) = _;
open(FH, $file) || die(error opening $file: $!);
local($/);
my($content) = FH;
close(FH) defined($content) || die(error reading $file: $!);
return \$content;
}
Rob
Apache::File
Folks, The Apache::File man pages indicate that ($name,$fh) = Apache::File-tmpfile; returns a fh ready to write to. So far so good. In case of wanting to read from it, here is what I do: # Is this necessary? $fh-close() or die Could not close $name: $!\n; $opfh-open($name); local $/= undef; $output = $opfh; warn $output\n; $opfh-close() or die Could not close $name: $!\n; But $output is empty on each request. Is there an error somewhere that I am not seeing? I appreciate all comments.responses. Thanks in advance -r
Apache::File correction
Folks, The Apache::File man pages indicate that ($name,$fh) = Apache::File-tmpfile; returns a fh ready to write to. So far so good. In case of wanting to read from it, here is what I do: # Is this necessary? $fh-close() or die Could not close $name: $!\n; $fh-open($name); local $/= undef; $output = $fh; warn $output\n; $fh-close() or die Could not close $name: $!\n; But $output is empty on each request. Is there an error somewhere that I am not seeing? I appreciate all comments.responses. Thanks in advance -r
Re: Apache::File correction
At 1:44 PM -0700 4/10/02, Rasoul Hajikhani wrote: Folks, The Apache::File man pages indicate that ($name,$fh) = Apache::File-tmpfile; returns a fh ready to write to. So far so good. In case of wanting to read from it, here is what I do: # Is this necessary? $fh-close() or die Could not close $name: $!\n; $fh-open($name); local $/= undef; $output = $fh; warn $output\n; $fh-close() or die Could not close $name: $!\n; To me it appears that you have not written anything to your tmp file... Which would explain the empty $output. Usually temp file creators open in read/write mode. So if you say something like ($name,$fh) = Apache::File-tmpfile; print $fh Hello World; seek($fh,0,0); my $line = $fh; print $line; It should print Hello World; Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
Re: Apache::File correction
Robert Landrum wrote: At 1:44 PM -0700 4/10/02, Rasoul Hajikhani wrote: Folks, The Apache::File man pages indicate that ($name,$fh) = Apache::File-tmpfile; returns a fh ready to write to. So far so good. In case of wanting to read from it, here is what I do: # Is this necessary? $fh-close() or die Could not close $name: $!\n; $fh-open($name); local $/= undef; $output = $fh; warn $output\n; $fh-close() or die Could not close $name: $!\n; To me it appears that you have not written anything to your tmp file... Which would explain the empty $output. gpg writes to that file. Usually temp file creators open in read/write mode. So if you say something like ($name,$fh) = Apache::File-tmpfile; print $fh Hello World; seek($fh,0,0); my $line = $fh; print $line; It should print Hello World; Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
[Q] Apache::File-new
Hi, I searched in the book, I searched in the FAQs - no I ask u: Does Apache::File-new start a subrequest? There are some mystical lines in my rewrite_log, which might come from there. Thanx a lot Martin
Re: [Q] Apache::File-new
Martin Haase-Thomas wrote: Hi, I searched in the book, I searched in the FAQs - no I ask u: Does Apache::File-new start a subrequest? no. it is merely a layer over Perl's file IO methods (Perl_do_open from what I can see). There are some mystical lines in my rewrite_log, which might come from there. that seems strange. maybe post the lines if they are causing you grief.. HTH --Geoff
Re: [Q] Apache::File-new
Ok, these are the lines from httpd.conf. The default-handler in /app/jsp
is inserted because I hope that i'll get resin taking over the request in
case the .pm declines. (hope this is right)
RewriteRule ^(.*)/(intl|de)/(.*) $1/jsp/$3 [QSA]
RewriteRule ^/$ /app/jap/home.jsp/23323.html [NS,R,L]
RewriteMap shortnames txt:/etc/apache/shortnames.txt
RewriteCond %{REQUEST_FILENAME} ^/[a-zA-Z0-9]+/?$
RewriteRule /([a-zA-Z0-9]+)/? ${shortnames:$1} [T=text/html,R,L,NS]
RewriteRule .*/favicon\.ico$ /statics/favicon.ico [PT]
RewriteRule ^/s\.gif$ /statics/pics/space.gif [PT]
RewriteRule ^/robots.txt$ /statics/robots.txt [NS,PT]
#pictures vom cms-server
RewriteRule ^/pictures/(.*) http://cms-dev/pictures/$1
# This one has to be the last in row:
RewriteRule ^(.*)_jsp(.*)$ $1.jsp$2 [QSA]
Location /app/jsp
SetHandler default-handler
/Location
# serve static files:
Location /app/jsp
SetHandler perl-script
PerlHandler Apache::StaticServer
/Location
Some lines from the .pm. Its purposeis to serve a static file instead of
the requested jsp. For instance, if I send a request for
something like "/app/jsp/category.jsp/23323" or "/app/jsp/category.jsp/23323.html"
the handler has to look after a file named
%{DOCUMENT_ROOT}/app/html/category_jsp/23323.html, and if it doesn't exist,
decline.
$catid = $r-path_info || "/23323"; # ancient rewrite rule
$fname = $r-filename;
$fname =~ s/.jsp$/_jsp/;
$fname =~ s:/jsp/:/html/:;
$fname .= $catid;
$fname .= ".html" unless $fname =~ /\.html$/; $r-log()-debug($fname."\n".$r-filename);
$fh = Apache::File-new($fname) || return DECLINED;
$r-header_out('Content-Length', -s $fname);
$r-update_mtime((stat $fname)[9]);
$r-send_http_header;
$r-send_fd($fh);
close $fh;
OK;
Here's a line from error_log which comes from the $r-log()-debug(...)
verse and says exactly what it has to:
[Tue Feb 12 15:03:55 2002] [debug] /usr/local/share/perl/5.6.1/ApacheStaticServer.pm(37):
[client 192.168.255.75] /home/disp05/app/html/category_jsp/67567.html
/home/disp05/app/jsp/category.jsp
If I send a request trhough a simple LWP client, here's what it says:
./client.pl http://disp05/app/jsp/category.jsp/67567
500 (Internal Server Error) unexpected EOF before status line seen
Client-Date: Tue, 12 Feb 2002 13:57:18 GMT
Ans this is what I find in my rewrite_log:
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(2) init rewrite engine with requested uri /app/jsp/category.jsp/67567
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^(.*)/(intl|de)/(.*)' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '/([a-zA-Z0-9]+)/?' to uri '/app/jsp/category.jsp/67567'192.168.255.75
- - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(4) RewriteCond: input='/app/jsp/category.jsp/67567' pattern='^/[a-zA-Z0-9]+/?$'
= not-matched
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '.*/favicon\.ico$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/s\.gif$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/robots.txt$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/pictures/(.*)' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^(.*)_jsp(.*)$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(1) pass through /app/jsp/category.jsp/67567
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(2) init rewrite engine with requested uri /67567
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3) applying pattern '^(.*)/(intl|de)/(.*)' to uri '/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3) applying pattern '.*/favicon\.ico$' to uri '/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3) applying pattern '^/s\.gif$' to uri '/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3) applying pattern '^/pictures/(.*)' to uri '/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3
Can't Locate Apache::File
Hi All, I've just installed the latest version of Lincoln Stein's Apache::MP3 (nice job, Doc!), which offers support for caching MP3 ICY info. It uses Apache::File to do so. This the first time I've used Apache::File on this server, but was still surprised to find that it failed to load: [Wed Aug 23 10:14:53 2000] [error] Can't locate loadable object for module Apache::File in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 . /usr/local/apache/ /usr/local/apache/lib/perl) at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 As near as I can tell, it is in fact there, and when I do % perl -le 'use Apache::File;' It seems to load just fine. The module lives in /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/File.pm Anyone got any idea why it can't find it? I'm running Apache 1.3.12 with mod_perl 1.24 compiled in on RedHat Linux 6.2. TIA! David
RE: Can't Locate Apache::File
did you build mod_perl with EVERYTHING=1 or PERL_FILE_API=1? HTH --Geoff -Original Message- From: David E. Wheeler [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 29, 2000 1:56 PM To: [EMAIL PROTECTED] Subject: Can't Locate Apache::File Hi All, I've just installed the latest version of Lincoln Stein's Apache::MP3 (nice job, Doc!), which offers support for caching MP3 ICY info. It uses Apache::File to do so. This the first time I've used Apache::File on this server, but was still surprised to find that it failed to load: [Wed Aug 23 10:14:53 2000] [error] Can't locate loadable object for module Apache::File in @INC (@INC contains: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .. /usr/local/apache/ /usr/local/apache/lib/perl) at /usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535 As near as I can tell, it is in fact there, and when I do % perl -le 'use Apache::File;' It seems to load just fine. The module lives in /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/File.pm Anyone got any idea why it can't find it? I'm running Apache 1.3.12 with mod_perl 1.24 compiled in on RedHat Linux 6.2. TIA! David
Re: passing Apache::File to XS code that expects FILE *?
On Thu, 18 May 2000, Vivek Khera wrote:
"DM" == Doug MacEachern [EMAIL PROTECTED] writes:
DM On Wed, 17 May 2000, Matt Sergeant wrote:
Well, this may be true, but if you load IO::File before startup then it's
not too big a deal...
DM but it still adds a great deal of bloat to the server. and it's oo
DM interface, while very slick, adds quite a bit of runtime overhead, turn
DM the sugar sour imo.
In an embedded environment like mod_perl, then how do you suggest to
deal with the dangling file handles problem? That is, I'm processing
a file or two, and some error occurs. In a normal perl program, I'd
exit or return out and then when the program terminates, it
automagically closes all the files. In mod_perl, the auto-close
doesn't happen until much later. With the OO interface, when the
handle goes out of scope, such as a function call return, the file is
implicitly closed.
What other mechanism do you propose to handle this situation other
than IO::File? I use it all the time myself.
in addition to stas' hints, even local *FH does the job, e.g.:
#/dev/null so strace output is more readable
open my $fh, "/dev/null";
select $fh;
$| = 1;
{
print "enter";
local *FH;
open FH, $0;
print "leave"
}
print "done";
% strace ~/test/io.pl
write(3, "enter", 5)= 5
- open("/home/dougm/test/io.pl", O_RDONLY) = 4
fstat(4, {st_mode=S_ISGID|S_ISVTX|0401, st_size=0, ...}) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
write(3, "leave", 5)= 5
- close(4)= 0
write(3, "done", 4) = 4
Re: passing Apache::File to XS code that expects FILE *?
"DM" == Doug MacEachern [EMAIL PROTECTED] writes: DM On Wed, 17 May 2000, Matt Sergeant wrote: Well, this may be true, but if you load IO::File before startup then it's not too big a deal... DM but it still adds a great deal of bloat to the server. and it's oo DM interface, while very slick, adds quite a bit of runtime overhead, turn DM the sugar sour imo. In an embedded environment like mod_perl, then how do you suggest to deal with the dangling file handles problem? That is, I'm processing a file or two, and some error occurs. In a normal perl program, I'd exit or return out and then when the program terminates, it automagically closes all the files. In mod_perl, the auto-close doesn't happen until much later. With the OO interface, when the handle goes out of scope, such as a function call return, the file is implicitly closed. What other mechanism do you propose to handle this situation other than IO::File? I use it all the time myself.
Re: passing Apache::File to XS code that expects FILE *?
On Thu, 18 May 2000, Vivek Khera wrote: "DM" == Doug MacEachern [EMAIL PROTECTED] writes: DM On Wed, 17 May 2000, Matt Sergeant wrote: Well, this may be true, but if you load IO::File before startup then it's not too big a deal... DM but it still adds a great deal of bloat to the server. and it's oo DM interface, while very slick, adds quite a bit of runtime overhead, turn DM the sugar sour imo. In an embedded environment like mod_perl, then how do you suggest to deal with the dangling file handles problem? That is, I'm processing a file or two, and some error occurs. In a normal perl program, I'd exit or return out and then when the program terminates, it automagically closes all the files. In mod_perl, the auto-close doesn't happen until much later. With the OO interface, when the handle goes out of scope, such as a function call return, the file is implicitly closed. What other mechanism do you propose to handle this situation other than IO::File? I use it all the time myself. use Apache; use Fcntl qw/:DEFAULT :flock/; my $fh = Apache-gensym(); sysopen($fh, "file", O_RDONLY) || die "Can't open: $!"; flock($fh, LOCK_SH) || die "Can't lock: $!"; ... when $fh goes out of scope it's closed and unlocked. Also see the guide section on exception handling. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: passing Apache::File to XS code that expects FILE *?
On Thu, 18 May 2000, Vivek Khera wrote:
"DM" == Doug MacEachern [EMAIL PROTECTED] writes:
DM On Wed, 17 May 2000, Matt Sergeant wrote:
Well, this may be true, but if you load IO::File before startup then it's
not too big a deal...
DM but it still adds a great deal of bloat to the server. and it's oo
DM interface, while very slick, adds quite a bit of runtime overhead, turn
DM the sugar sour imo.
In an embedded environment like mod_perl, then how do you suggest to
deal with the dangling file handles problem? That is, I'm processing
a file or two, and some error occurs. In a normal perl program, I'd
exit or return out and then when the program terminates, it
automagically closes all the files. In mod_perl, the auto-close
doesn't happen until much later. With the OO interface, when the
handle goes out of scope, such as a function call return, the file is
implicitly closed.
What other mechanism do you propose to handle this situation other
than IO::File? I use it all the time myself.
guide... guide... guide... :) (I'll keep you updated with the search
really soon now)
http://perl.apache.org/guide/porting.html#Filehandlers_and_locks_leakages
perl 5.6
use Symbol;
{
my $fh = gensym;
open $fh,
}
perl5.6
{
open my $fh, ...
}
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
passing Apache::File to XS code that expects FILE *?
Is there some trick to passing an Apache::File to a function from an XS module that expects a FILE *? There's too much perl magic going on in the Apache::File implementation for me to see where I can just pull the FILE * out. (Its not strictly necessary that I do this, of course, it would just be nice so I can use Apache::File-tmpfile(). Of course I can do the same basic thing with POSIX::tmpnam().) Jim
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Jim Winstead wrote: Is there some trick to passing an Apache::File to a function from an XS module that expects a FILE *? There's too much perl magic going on in the Apache::File implementation for me to see where I can just pull the FILE * out. (Its not strictly necessary that I do this, of course, it would just be nice so I can use Apache::File-tmpfile(). Of course I can do the same basic thing with POSIX::tmpnam().) Or IO::File-new_tmpfile(); -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: passing Apache::File to XS code that expects FILE *?
On May 17, Matt Sergeant wrote: Or IO::File-new_tmpfile(); I'd rather not go there. http://marc.theaimsgroup.com/?l=apache-modperlm=95454378223412w=2 Jim
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Jim Winstead wrote: On May 17, Matt Sergeant wrote: Or IO::File-new_tmpfile(); I'd rather not go there. http://marc.theaimsgroup.com/?l=apache-modperlm=95454378223412w=2 Well, this may be true, but if you load IO::File before startup then it's not too big a deal... Alternatively use File::Temp on CPAN, Apache-gensym(), and open()/sysopen(). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Jim Winstead wrote: Is there some trick to passing an Apache::File to a function from an XS module that expects a FILE *? so long as the xsub uses a FILE *, the typemap will take care of the magic. for example, Apache::send_fd() is an xsub that uses the FILE * typemap: use Apache::File (); my $r = shift; $r-send_http_header; my $tmp = Apache::File-tmpfile; print $tmp "hi"; seek $tmp, 0, 0; $r-send_fd($tmp);
Re: passing Apache::File to XS code that expects FILE *?
On Wed, 17 May 2000, Matt Sergeant wrote: Well, this may be true, but if you load IO::File before startup then it's not too big a deal... but it still adds a great deal of bloat to the server. and it's oo interface, while very slick, adds quite a bit of runtime overhead, turn the sugar sour imo.
