Re: porting from mod_perl1 to mod_perl2
I think I got your problem solved, you need to: - print $q-header(); + print $q-header(text/html; charset=utf-8); __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: porting from mod_perl1 to mod_perl2
Stas and all of the others,
Stas said:
I think I got your problem solved, you need to:
- print $q-header();
+ print $q-header(text/html; charset=utf-8);
Well actually you did not.
Probably you looked a bit too fast.
(forgivable in view of the numbers of mails you reply to:-)
The utf8-test.pl code is reading what comes out of the form (which has a
charset=utf-8 meta tag, so that is OK, see my previous mail)
The utf8-test.pl then replaces the characters higher the 7F with char. ref
entities but with the string '+entity: ' in front of the value(see below
lines 11 and 12 of utf8-test.pl).
And to double verify the information read back from the form is also
unpacked from unicode values into their hex counterparts.
And then both strings are printed out as normal low ascii characters (7f),
so no need to set the utf-8 flag here.
From further testing I have seen that only unicode characters that actually
have a representation in the win1252 characters set come back under their
corresponding win1252 characterset position.
So the form would for example contain an ndash character (unicode position
dec 8211 or U+2013) .
But that is read back as character dec 150 or hex 96.
And if the form contains a right single quotation (unicode position dec 8217
or U+2019), it comes back under its win1252 position of dec 146 or hex 92.
I would have expected if I send something in under its unicode position, it
would come back to me under its unicode position.
But then again I may be wrong.
And the utf8 flag in the header only means that is will be utf8 encoded and
should not be confused with the characterset used.
I am under the impression I confusing myself more and more here.
So if somebody has been on this path before and knows the truth, let him
speak up!
(Oh did I mention already that I have tested only against IE6, because the
browser could be the cause as well of this odd(?) behaviour.)
Thanks all for your patience.
I would really like to get to the bottom of this.
Bart
Here is utf8-test.pl, again this time with line numbers
1:#!/perl/bin/perl.exe
2:use strict;
3:use CGI;
4:use CGI::Carp qw(fatalsToBrowser);
5:
6:my $q = CGI-new;
7:my $content = $q-param(utf8-test);
8:$content .= verify with \x{2014};
9:my @content = unpack('U*', $content);
10:$content =~ s/([\x{0800}-\x{}])/sprintf('+entity:%d+',ord($1))/ge;
11:$content =~ s/([\x{0080}-\x{07FF}])/sprintf('+entity: %d+',ord($1))/ge;
12:print $q-header();
13:print $q-p($content);
14:print $q-p('hex');
15:foreach (@content) {printf %x , $_}
and here is the htlm form that triggers the utf8-test.pl:
html xmlns=http://www.w3.org/1999/xhtml; lang=en
head
meta http-equiv=content-type content=text/html; charset=utf-8 /
/head
body
form method=post action=/mod_perl/utf8-test.pl
enctype=multipart/form-data
textarea name ='utf8-test' cols='60'test: #235; #8212;/textarea
nbsp;nbsp;input type=submit value=publish new content//h4
/form
/body/html
and here is the result this all produces:
test: +entity: 235+ +entity: 151+verify with +entity:8212+
hex
74 65 73 74 3a 20 eb 20 97 76 65 72 69 66 79 20 77 69 74 68 20 2014
Re: porting from mod_perl1 to mod_perl2
Bart Terryn wrote: Stas and all of the others, Stas said: I think I got your problem solved, you need to: - print $q-header(); + print $q-header(text/html; charset=utf-8); Well actually you did not. Probably you looked a bit too fast. (forgivable in view of the numbers of mails you reply to:-) Actually I haven't looked, I have tested with your code. Before setting the header I wasn't getting the unicode chars you put in the form back in the dump. After setting the header it did print out exacly the same unicode character. I didn't have a chance to mess with the hex representations yet. [...] (Oh did I mention already that I have tested only against IE6, because the browser could be the cause as well of this odd(?) behaviour.) I think this is where the weak point is. You need to compare characters on the server side, not trying to rely on the browser, which as you have seen will render them improperly if you didn't set the right header. You have two things happening: read input, send output. The problem can be in any of the two and worse, it can be in both and the error can fix itself when doubled. You need to verify first that the input is read properly, then the same for the output. I have started writing the test for mp2 to verify utf8 input, hopefully I'll finish it soon. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: porting from mod_perl1 to mod_perl2
Stas,
Sorry to insist.
But here I am again...
Stas wrote:
Actually I haven't looked, I have tested with your code.
Thanks a lot for going through the effort...
Before setting the
header I wasn't getting the unicode chars you put in the form back in the
dump. After setting the header it did print out exacly the same unicode
character.
Well that is strange. I just changed my code and still am getting the endash
back as code 150 and not as the 8212 code (the way it went in).
Are you sure that you have the 2 lines in the test program that change the
multibyte utf-8 encoded characters into their values?
(the famous lines 11 and 12)
Because if not, then I can understand that you have to put the changed
header in as you would be sending utf-8 encoded data to the client.
And it would also explain why you would 'see' the same character after
putting the utf-8 header in.
I didn't have a chance to mess with the hex representations yet.
That makes me wonder even more about the thing above.
[...]
I think this is where the weak point is. You need to compare characters on
the
server side, not trying to rely on the browser, which as you have seen will
render them improperly if you didn't set the right header.
Again that is the purpose of the dreaded lines 11 and 12 of my test program.
I don't want to render the character, I just want to display the actual
(utf-8 encoded) code that I read back from the form.
You have two things happening: read input, send output. The problem can be
in
any of the two and worse, it can be in both and the error can fix itself
when
doubled. You need to verify first that the input is read properly, then the
same for the output.
Believe me.
I also ran tests that write out the data to disk and then used a hex dump of
that file to actually verify what is in there. I got the same results. But
that go a bit tedious hence my little test program that does more or less
the same thing.
For your convenience here is the test program again
You will note that I change the $q-header print statement, but as said
before the outcome is still wrong.
Could you confirm that you indeed used this script unmodified and still are
recieving correct output?
As said the important part is in line 11 and 12.
You will need perl 5.8 in order to make those 2 lines work properly
(5.6 does not understand unicode correctly)
#!/perl/bin/perl.exe
use strict;
use CGI;
use CGI::Carp qw(fatalsToBrowser);
use CGI::Cookie;
my $q = CGI-new;
my $content = $q-param(utf8-test);
$content .= verify with \x{2014};
my @content = unpack('U*', $content);
$content =~ s/([\x{0800}-\x{}])/sprintf('+entity:%d+',ord($1))/ge;
$content =~ s/([\x{0080}-\x{07FF}])/sprintf('+entity: %d+',ord($1))/ge;
print $q-header(text/html; charset=utf-8);
print $q-p($content);
print $q-p('hex');
foreach (@content) {printf %x , $_}
I have started writing the test for mp2 to verify utf8 input, hopefully
I'll
finish it soon.
Thanks a lot for your support...
Bart
RE: porting from mod_perl1 to mod_perl2
On Tue, 9 Sep 2003, Bart Terryn wrote: Stas, Sorry to insist. But here I am again... Stas wrote: Actually I haven't looked, I have tested with your code. Thanks a lot for going through the effort... Before setting the header I wasn't getting the unicode chars you put in the form back in the dump. After setting the header it did print out exacly the same unicode character. Well that is strange. I just changed my code and still am getting the endash back as code 150 and not as the 8212 code (the way it went in). If you're using ppm to install mod_perl, could you try the latest version at http://theoryx5.uwinnipeg.ca/ppms/? There were some changes made recently that may affect the above problem. Note that the version in the mod_perl.ppd hasn't changed, so you may have to uninstall mod_perl and then install it to force ppm to upgrade. -- best regards, randy kobes
Re: porting from mod_perl1 to mod_perl2
If you check out the changes to CGI.pm on Licoln Stiens web site, utf8 was added via a path by someone else 2.99 - 3.00 likely this is the cause. Stas Bekman wrote: Perrin Harkins wrote: I am fairly sure it is not perl5.8. I'm fairly sure it is. What is your locale set to? Are you on Red Hat? See previous discussions of locale issues on Red Hat 8 and 9 in the list archives. Bart is on win32, AS Perl 5.8. I doubt it's a locale issue, since it's the client who decides what encoding the data is in, it's either CGI.pm (guessing that what he was using to parse the forms) or more low level (io) issues. Bart, can you test whether you have the same problem when a run the same code under mod_cgi in Apache2 (with perl5.8 ofcourse)? If not, that will point the blaming finger towards mod_perl 2.0. Someone volunteers to add a new test? See t/modperl/print_utf8.t t/response/TestModperl/print_utf8.pm for an example of testing the responding with utf8 data. You can probably adopt one of these couples for testing the posting of utf8 data: t/apache/cgihandler.t t/response/TestApache/cgihandler.pm t/modules/cgi.t t/response/TestModules/cgi.pm t/modules/cgiupload.t t/response/TestModules/cgiupload.pm of course you will want to create a new couple of files for this test. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: porting from mod_perl1 to mod_perl2
Philip M. Gollucci wrote: If you check out the changes to CGI.pm on Licoln Stiens web site, utf8 was added via a path by someone else 2.99 - 3.00 likely this is the cause. Bart, can you try then with an earlier version? e.g. 2.93 was good for me. You can get it from here: http://www.cpan.org/authors/id/L/LD/LDS/ __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
Stas wrote:
Bart, can you test whether you have the same problem when a run the same
code
under mod_cgi in Apache2 (with perl5.8 ofcourse)? If not, that will point
the
blaming finger towards mod_perl 2.0.
Well I did that and guess what? mod_cgi fails as well.
So it is not a mod_perl problem
But for me it is still uncertain who to blame. (cgi.pm? apache2? perl5.8?)
I made a small test for this.
Just in case somebody wants to give it a try
Here is my sample page:
-
html xmlns=http://www.w3.org/1999/xhtml; lang=en
head
meta http-equiv=content-type content=text/html; charset=utf-8 /
/head
body
form method=post action=/mod_perl/utf8-test.pl
enctype=multipart/form-data
textarea name ='utf8-test' cols='60'test: #235; #8212;/textarea
nbsp;nbsp;input type=submit value=publish new content//h4
/form
/body/html
--
Here is the utf8-test.pl:
---
#!/perl/bin/perl.exe
use strict;
use CGI;
use CGI::Carp qw(fatalsToBrowser);
my $q = CGI-new;
my $content = $q-param(utf8-test);
$content .= verify with \x{2014};
my @content = unpack('U*', $content);
$content =~ s/([\x{0800}-\x{}])/sprintf('+entity:%d+',ord($1))/ge;
$content =~ s/([\x{0080}-\x{07FF}])/sprintf('+entity: %d+',ord($1))/ge;
print $q-header();
print $q-p($content);
print $q-p('hex');
foreach (@content) {printf %x , $_}
---
and here is the output I get:
test: +entity: 235+ +entity: 151+verify with +entity:8212+
hex
74 65 73 74 3a 20 eb 20 97 76 65 72 69 66 79 20 77 69 74 68 20 2014
--
From which I understand that the original character #8212; is returned as
hex 97 or dec 151.
And would be correct if the characterset would be window-1252 but that is
not what I expected.
Wanted utf-8 to be returned.
If mod_perl is not the correct forum for this (which I agree it isn't) can
somebody point me in the direction of a correct forum? But as said before
the difficulty is that I don't know who to blame
Kind Regards,
Bart
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
I had version CGI 3.00 installed. Downgraded it to CGI 2.93, put I still have the same result. The problem as I see it that I have a form with character #8212; in it. But it is returned as character #151 from the Widows-1252 characterset. Does everybody agree that it should be returned as #8212; (the utf-8 representation I mean)? See my previous mail for the test I used. Bart -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Saturday, September 06, 2003 8:35 AM To: Philip M. Gollucci Cc: Perrin Harkins; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: porting from mod_perl1 to mod_perl2 Philip M. Gollucci wrote: If you check out the changes to CGI.pm on Licoln Stiens web site, utf8 was added via a path by someone else 2.99 - 3.00 likely this is the cause. Bart, can you try then with an earlier version? e.g. 2.93 was good for me. You can get it from here: http://www.cpan.org/authors/id/L/LD/LDS/ __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
Hi, I have an application running under apache 1.37(win32)/mod_perl1.27_01-dev/perl5.6 build 633 I am trying to move this application to apache 2.0.47(win32)/mod_perl1.99_10-dev/perl 5.8 However I run into a problem with character encoding. Somewhere in this app I put up a form that contains text. The encoding of the html page that contains this form is set to 'utf-8' by the following: meta http-equiv=content-type content=text/html; charset=UTF-8 / That form displays OK in both mod_perl1.0 and mod_perl2.0 When I read the form back under the apache1, everything is OK. When I do the same using the apache 2 combination I run into trouble with the char ref entities entities which are high in the unicode set like: #8212; or #8211;. These characters are returned as unicode characters hex 97 and hex 96. Other character ref entities like the one for e (e umlaut = #235;) are returned correctly. So I assume that only characters above 07FFF are returned wrong. Anybody any idea? Thanks in advance Bart PS: some might say that this has nothing to do with mod_perl. And maybe you are right, but I have no clue which part might be causing this. I am fairly sure it is not perl5.8. Although in order to make the apache2/mod_perl2 combination to work I had to upgrade the CGI.pm to version 3.0 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
Hi there, On Sat, 6 Sep 2003, Bart Terryn wrote: Hi, I have an application running under apache 1.37(win32)/mod_perl1.27_01-dev/perl5.6 build 633 I am trying to move this application to apache 2.0.47(win32)/mod_perl1.99_10-dev/perl 5.8 However I run into a problem with character encoding. Have you checked perldoc perllocale ? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
On Fri, 2003-09-05 at 19:14, Bart Terryn wrote: PS: some might say that this has nothing to do with mod_perl I would say that, but it's okay, you didn't know. I am fairly sure it is not perl5.8. I'm fairly sure it is. What is your locale set to? Are you on Red Hat? See previous discussions of locale issues on Red Hat 8 and 9 in the list archives. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: porting from mod_perl1 to mod_perl2
Perrin Harkins wrote: I am fairly sure it is not perl5.8. I'm fairly sure it is. What is your locale set to? Are you on Red Hat? See previous discussions of locale issues on Red Hat 8 and 9 in the list archives. Bart is on win32, AS Perl 5.8. I doubt it's a locale issue, since it's the client who decides what encoding the data is in, it's either CGI.pm (guessing that what he was using to parse the forms) or more low level (io) issues. Bart, can you test whether you have the same problem when a run the same code under mod_cgi in Apache2 (with perl5.8 ofcourse)? If not, that will point the blaming finger towards mod_perl 2.0. Someone volunteers to add a new test? See t/modperl/print_utf8.t t/response/TestModperl/print_utf8.pm for an example of testing the responding with utf8 data. You can probably adopt one of these couples for testing the posting of utf8 data: t/apache/cgihandler.t t/response/TestApache/cgihandler.pm t/modules/cgi.t t/response/TestModules/cgi.pm t/modules/cgiupload.t t/response/TestModules/cgiupload.pm of course you will want to create a new couple of files for this test. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: porting from mod_perl1 to mod_perl2
On Fri, 2003-09-05 at 21:36, Stas Bekman wrote: Bart is on win32, AS Perl 5.8. Oops, sorry Bart, I missed that. Even so, I'm suspicious that 5.8 and all of its unicode changes are involved somehow. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Porting Orphans : (was: apache::sandwich)
[EMAIL PROTECTED] wrote: This brings up a good point, is there a list of 'ModPerl Orphans' anywhere? For the most part I would imagine that a modules author/maintainer will manage the transition to mp2 but there must be a ton of modules that are Orphans with little hope of making it over unless some kind developer makes it happen. It would be pretty great if there was a list and people could start taking responsibility for the tasks to avoid duplicate work as well as to guide folks who have time to contribute and are not sure where to start. Lame suggestion most likely. I was just thinking 'I would like to try to port something but where to start' If there is interest in this I can put up a page for this sort of thing and send email out to all of the existing authors, hunting for orphans to post. It's a good idea to compile a list of modules that need to get ported, discarding those that aren't needed in mp2 (e.g. Apache::Filter and FilterChain are definitely to stay in the mp1 world I believe). However there is a problem with porting modules that include XS code, since the replacement for Apache::src hasn't been completed yet. Pure perl modules porting should be fine. FWIW, I've ported Apache::Peek and Apache::Scoreboard to 2.0, but I can't release them yet as they need a support from mod_perl-2.0 (because of Apache::src/xs stuff), which wasn't committed yet. We are hoping to deliver a much better Makefile.PL support (including things like installing into Apache2/ and automatic configuration of the MM attributes for compilation) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Porting to mod_perl and cookies are breaking. Why?
At 05:43 10.06.2002, Mark Korey wrote:
ENV{HTTP_COOKIE} does not contain a newly set cookie, often it
still contains an old value when I try to change it (ie switch to a
different user).
Everything else appears to be working fine.
If you're saying that $ENV{HTTP_COOKIE} is empty, you should set
PerlSetupEnv On in your Location section. See
http://perl.apache.org/release/docs/1.0/guide/config.html#PerlSetupEnv
Could we see your code (an excerpt showing the problem)? You might be doing
something wrong when trying to set cookies. Furthermore, you should really
be using CGI.pm, CGI::Cookie or Apache::Cookie for your cookie needs.
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: Porting to mod_perl and cookies are breaking. Why?
We found the problem ... this was an odd one (aren't most!?!).
Turns out that the path (i.e. $cgi-cookie(-path ='/', ...); )
was NOT being set. Guess we assumed that CGI.pm would default it to '/'.
Setting that seemed to do the trick.
We are using CGI.pm and did not need to PerlSetupEnv On.
I'm still not sure why this works differently under mod_perl.
Semi-related to this, isn't $cgi-cookie just an API which
uses $ENV{HTTP_COOKIE}?
What's the big advantage of Apache::Cookie?
I'd like to keep my code as flexible compatible as possible
so it will run under both standard CGI mod_perl, at least
while we work the kinks out of our mod_perl configuration.
Thanks.
- Mark
www.fantasycup.com
On Mon, 10 Jun 2002, Per Einar Ellefsen wrote:
At 05:43 10.06.2002, Mark Korey wrote:
ENV{HTTP_COOKIE} does not contain a newly set cookie, often it
still contains an old value when I try to change it (ie switch to a
different user).
Everything else appears to be working fine.
If you're saying that $ENV{HTTP_COOKIE} is empty, you should set
PerlSetupEnv On in your Location section. See
http://perl.apache.org/release/docs/1.0/guide/config.html#PerlSetupEnv
Could we see your code (an excerpt showing the problem)? You might be doing
something wrong when trying to set cookies. Furthermore, you should really
be using CGI.pm, CGI::Cookie or Apache::Cookie for your cookie needs.
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: Porting to mod_perl and cookies are breaking. Why?
At 23:55 10.06.2002, Mark Korey wrote:
We found the problem ... this was an odd one (aren't most!?!).
Turns out that the path (i.e. $cgi-cookie(-path ='/', ...); )
was NOT being set. Guess we assumed that CGI.pm would default it to '/'.
Setting that seemed to do the trick.
We are using CGI.pm and did not need to PerlSetupEnv On.
It's the default to have it On, that's why it got me wondering.
I'm still not sure why this works differently under mod_perl.
Probably not mod_perl's fault at all, you might have been using a different
path before (or maybe a different vresion of CGI.pm?)
Semi-related to this, isn't $cgi-cookie just an API which
uses $ENV{HTTP_COOKIE}?
CGI.pm has mod_perl-related code under the hood. I'm not sure if the same
applies to CGI::Cookie (which is used for $cgi-cookie).
What's the big advantage of Apache::Cookie?
It's C, so it's faster. It uses the Apache API. You won't have to do things
like print $cgi-header(-cookie = ...), you just do $cookie-bake; But
basically, you don't need it yet.
I'd like to keep my code as flexible compatible as possible
so it will run under both standard CGI mod_perl, at least
while we work the kinks out of our mod_perl configuration.
In that case, just keep your current code. You'll only have the use for the
likes of Apache::Cookie when you start moving to the Apache Perl API anyway.
On Mon, 10 Jun 2002, Per Einar Ellefsen wrote:
At 05:43 10.06.2002, Mark Korey wrote:
ENV{HTTP_COOKIE} does not contain a newly set cookie, often it
still contains an old value when I try to change it (ie switch to a
different user).
Everything else appears to be working fine.
If you're saying that $ENV{HTTP_COOKIE} is empty, you should set
PerlSetupEnv On in your Location section. See
http://perl.apache.org/release/docs/1.0/guide/config.html#PerlSetupEnv
Could we see your code (an excerpt showing the problem)? You might be doing
something wrong when trying to set cookies. Furthermore, you should really
be using CGI.pm, CGI::Cookie or Apache::Cookie for your cookie needs.
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: Porting to OS X
On 6/4/02 10:43 AM, Noam Solomon [EMAIL PROTECTED] claimed: Can anyone give me a rough idea how much time it would take to move a server serving mod_perl websites from UNIX to OS X? It uses Apache::Session, DBI::Mysql, HTML::Mason, CGI, and Apache::OpenIndex, among others, and uses both AuthHandlers and AuthzHandlers. It depends on how good a Sysadmin you are, but I would say a couple of days. I document how to install most of this stuff on my site: http://david.wheeler.net/osx.html I don't cover MySQL, but there's a link to an Apple article on how to install it in the section where I cover installing PostgreSQL. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: Porting to OS X
Wheeler's site provides a lot of great information. When I get to my other computer, I can send you some other useful URLs for setting up UNIX apps on the OS X if you want. I found it took about an evening to install all the software. Another evening to get mod_perl apps up and running, but I had to install XML-related software, too. . .mysql is a snap, too. And I am NOT a sysadmin...not even close. I think it is relatively an easy move, IMHO. Just beaware that the Mac OS filesystem is NOT case-sensitive. Which can cause problems with certain applications. . .and we hope (Apple, you listening?) that they will fix this gross over-sight. Cheers, Ward -Original Message-From: Noam Solomon [mailto:[EMAIL PROTECTED]]Sent: Tuesday, June 04, 2002 10:43 AMTo: [EMAIL PROTECTED]Subject: Porting to OS X Can anyone give me a rough idea how much time it would take to move a server serving mod_perl websites from UNIX to OS X?It usesApache::Session, DBI::Mysql, HTML::Mason,CGI, andApache::OpenIndex, among others, and uses both AuthHandlers and AuthzHandlers. Iknow it's difficult to estimate without knowing how big the websites are, what kind of functions they call, etc., but if you could give me an idea of what kind of problems I can expect to encounter and how difficult they are to work around, I can give a quote to my client. Thanks, Noam Solomon
RE: Porting to OS X
This is going OT, but the case insensitivity problem is only for the Mac filesystems. I've that all you need to do is switch the filesystem to ufs (the bsd version) and the problem is solved. Of course, if you can't switch fs types I don't know of a workaround. :-) Drew At 10:54 AM 6/4/02 -0700, Vuillemot, Ward W wrote: I think it is relatively an easy move, IMHO. Just beaware that the Mac OS filesystem is NOT case-sensitive. Which can cause problems with certain applications. . .and we hope (Apple, you listening?) that they will fix this gross over-sight. == Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
Re: Porting to OS X
On 6/4/02 10:54 AM, Vuillemot, Ward W [EMAIL PROTECTED] claimed: I think it is relatively an easy move, IMHO. Just beaware that the Mac OS filesystem is NOT case-sensitive. Which can cause problems with certain applications. . .and we hope (Apple, you listening?) that they will fix this gross over-sight. I don't think that Apple is likely to change this. However, you can install OS X on a case-sensitive partition (UFS?) if you really want to. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Porting to OS X [OT] OS X
I think it is relatively an easy move, IMHO. Just beaware that the Mac OS filesystem is NOT case-sensitive. Which can cause problems with certain applications. . .and we hope (Apple, you listening?) that they will fix this gross over-sight. I agree it's a problem, and it's caused me some heartache, but Apple, and many of my Apple zealot friends definitely consider it a feature, not a bug. Another annoying thing that may happen while migrating directory structures is: if you have two directorie with /dir_this/dir_that/[lotsof.pl] /dir_dir/dir_this/dir_the_other/[lotsmore.pl] and you're in / cp|mv dir_this dir_dir will cp|mv dir_that to /dir_dir/dir_this/dir_that BUT dir_the_other will be gone. Another feature Dvaid
RE: Porting to OS X
From: Noam Solomon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Porting to OS X Date sent:Tue, 4 Jun 2002 13:43:11 -0400 [ Double-click this line for list subscription options ] Can anyone give me a rough idea how much time it would take to move a server serving mod_perl websites from UNIX to OS X? It uses Apache::Session, DBI::Mysql, HTML::Mason, CGI, and Apache::OpenIndex, among others, and uses both AuthHandlers and AuthzHandlers. I know it's difficult to estimate without knowing how big the websites are, what kind of functions they call, etc., but if you could give me an idea of what kind of problems I can expect to encounter and how difficult they are to work around, I can give a quote to my client. Thanks, Noam Solomon I'd be very interested in how this progresses. I recently helped a collegue to get a cgi program running under apache using standard perl on OSX -- I found that the perl distribution that comes with OSX is the original 5.6 rather than more up to date versions AND that the application, which runs on an aging 486 with 64 megs in our shop and uses about 4 megs including mod_perl enhanced apache, took 40 megs on OSX and was very slow. This was on a G4 with 500 megs of memory. Michael
RE: Porting to OS X
At 11:27 AM 6/4/02 -0700, Michael Robinton wrote: I'd be very interested in how this progresses. I recently helped a collegue to get a cgi program running under apache using standard perl on OSX -- I found that the perl distribution that comes with OSX is the original 5.6 rather than more up to date versions IIRC, the latest OS update upgrades perl to 5.6.1. == Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
Re: Porting to OS X
David == David Wheeler [EMAIL PROTECTED] writes: I think it is relatively an easy move, IMHO. Just beaware that the Mac OS filesystem is NOT case-sensitive. Which can cause problems with certain applications. . .and we hope (Apple, you listening?) that they will fix this gross over-sight. David I don't think that Apple is likely to change this. However, you David can install OS X on a case-sensitive partition (UFS?) if you David really want to. My / has been UFS since day 1 of using OSX for me. I have a separate HFS+ partition for Classic Apps. The downside is that some of the files are not accessible to Classic apps, but as more and more stuff gets at least Carbonized, I'm not really that worried. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
eating memory ... // RE: Porting to OS X
Hi, -- Michael Robinton [EMAIL PROTECTED] wrote: application, which runs on an aging 486 with 64 megs in our shop and uses about 4 megs including mod_perl enhanced apache, took 40 megs on OSX and was very slow. This was on a G4 with 500 megs of memory. probably it's the same as on FreeBSD: if you use a DSO mod_perl, for each restart (apachectl graceful or apachectl restart) it eats all the memory your mod_perl modules use. Try to build it statically; at least on FreeBSD it helps, and OSX is FreeBSD ... :-) But my newest test was with Apache 1.3.23 and mod_perl 1.26; perhaps it's fixed in 1.27?!? But nevertheless 4 MB is very small; my frontend Apache 1.3.23 without mod_perl takes 3 MB; my frontend Apache 2.0.36 on developing system 4 MB without mod_perl ... Ciao Alvar -- // Unterschreiben! http://www.odem.org/informationsfreiheit/ // Internet am Telefon: http://www.teletrust.info/ // Das freieste Medium? http://www.odem.org/insert_coin/ // Blaster: http://www.assoziations-blaster.de/
Re: eating memory ... // RE: Porting to OS X
On Wed, 5 Jun 2002, Alvar Freude wrote: probably it's the same as on FreeBSD: if you use a DSO mod_perl, for each restart (apachectl graceful or apachectl restart) it eats all the memory your mod_perl modules use. Try to build it statically; at least on FreeBSD it helps, and OSX is FreeBSD ... :-) But my newest test was with Apache 1.3.23 and mod_perl 1.26; perhaps it's fixed in 1.27?!? dso should be fine with 1.26 or 1.27, provided you are using Perl 5.6.1 or higher. 5.005_03 still has leakage.
Re: Porting
We have an application written in Java using MVC which we would like to port to mySQL/Perl platform. We have used Struts,to create tags. Any inputs in this regards will be appreaciated. You will probably find that Struts tags can be ported nicely to Template Toolkit (http://template-toolkit.org). You might even be able to write a converter for your JSP pages. If you're interested in getting some object/relational mapping features and a basic MVC structure thrown in as well, you can check out OpenInteract (http://openinteract.org/). - Perrin
RE: Porting
We have an application written in Java using MVC which we would like to port to mySQL/Perl platform. We have used Struts,to create tags. Any inputs in this regards will be appreaciated. You will probably find that Struts tags can be ported nicely to Template Toolkit (http://template-toolkit.org). You might even be able to write a converter for your JSP pages. If you're interested in getting some object/relational mapping features and a basic MVC structure thrown in as well, you can check out OpenInteract (http://openinteract.org/). - Perrin Or what about Apache::ASP and XML Subs? John --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.281 / Virus Database: 149 - Release Date: 18/09/2001
Re: Porting
Any clues as to your motivation for porting to mod_perl? I've been trying to sell a mod_perl solution to some Java nuts for some time and any help would be much appreciated. What really makes mod_perl better than Java? Are there any performance benchmarks out there that anyone knows about? Scaleability? JDBC vs. DBI? Child/Servlet memory footprint size? If someone says to you, why didn't you do it in Java? What do you say? (Besides mentioning Sun's lame license.) Didn't the eToys guys do some benchmarking? (Perrin?) Manoj Anjaria wrote: Hello all, We have an application written in Java using MVC which we would like to port to mySQL/Perl platform. We have used Struts,to create tags. Any inputs in this regards will be appreaciated. Thanks Manoj _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp -- Mark Maunder Senior Architect SwiftCamel Software http://www.swiftcamel.com mailto:[EMAIL PROTECTED]
Re: Porting
What really makes mod_perl better than Java? This is a common thread, which you should look up in the archives. It's best to avoid starting up a discussion with this vague a question, since it will lead to a flood of advocacy e-mails. Didn't the eToys guys do some benchmarking? (Perrin?) We did. We knew we were going to use Linux, so we took the fastest Java stuff (Resin + IBM's JVM) and wrote a quick test servlet to select some stuff from Oracle and display it. When we ran the same thing under mod_perl, Perl was a little bit faster. Note that Caucho has some benchmarks they published which are not very good since they have poorly optimized Perl code (it's a Registry script, not a handler). When we saw that Perl was just as fast, we had no reason to switch from a productive platform that we all liked to one that only some of our team had skills on. - Perrin
Re: Porting
Mark Maunder wrote on Mon, Sep 24 2001 (15:44:25 +0100): Any clues as to your motivation for porting to mod_perl? I've been trying to sell a mod_perl solution to some Java nuts for some time and any help would be much appreciated. What really makes mod_perl better than Java? Are there any performance benchmarks out there that anyone knows about? Scaleability? JDBC vs. DBI? Child/Servlet memory footprint size? performance is not the crucial point here, IMHO. it's like young boys arguing about car brands, my daddy's car is faster than your daddy's car! it depends on the people who will write/maintain the code and their skills with the particular technology, be it mod_perl, servlets, ruby, python, whatever. basically, someone with comparable proficiency in each of the mentioned technologies will be able to produce a working solution with comparable performance. all of the above technologies have been deployed in large-scale projects, and they can be tuned, so that performance questions should not be emphasized more than necessary. if your data model is clean and your algorithms are smart, then the implementation language is just a question of convenience, IMHO. you should concentrate on this fact rather than bragging about product features. If someone says to you, why didn't you do it in Java? What do you say? (Besides mentioning Sun's lame license.) because i think that mod_perl gives me all the flexibility i need, and it's supported by legions of competent developers. i saw lots of companies offering premium commercial support for their products, but almost none of them can maintain the level of support offered by the perl community. in my opinion, there are lots of (mediocre) Java programmers out there, far more than competent mod_perl programmers. it's easier for companies to recruit Java people, and Java has better marketing, impressing suits who pay for your projects. cu, -- Toni Andjelkovic [EMAIL PROTECTED]
Re: Porting
John Reid wrote: We have an application written in Java using MVC which we would like to port to mySQL/Perl platform. We have used Struts,to create tags. Any inputs in this regards will be appreaciated. You will probably find that Struts tags can be ported nicely to Template Toolkit (http://template-toolkit.org). You might even be able to write a converter for your JSP pages. If you're interested in getting some object/relational mapping features and a basic MVC structure thrown in as well, you can check out OpenInteract (http://openinteract.org/). - Perrin Or what about Apache::ASP and XML Subs? If you do look at Apache::ASP see that it falls short for you, please let me know what issues there are as there are likely features I can add that might make your transition a better experience. Apache::ASP is being actively developed, and a major release 2.23 will soon go to CPAN. Also note that for general questions about Apache::ASP, please send them to [EMAIL PROTECTED] or subscribe with [EMAIL PROTECTED] --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
RE: Porting CGI scripts help needed
You might try adding use lib '/path/to/global.pm'; to you startup.pl. (Without the s of course) Good luck. --Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Bryan Coon [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 26, 2001 6:01 PM To: '[EMAIL PROTECTED]' Subject: Porting CGI scripts help needed Hi, I have (happily) compiled and configured Apache with mod_perl, mod_ssl, mod_php and DSO. Whee! Now I am working on porting my scripts over... I have always used strict and perl -w, so for the most part, I think I can just pop my cgis in the /perl directory as Ive defined it in httpd.conf. However, I had to implement some trickery for my scripts a while ago via require/use and am having problems getting my scripts to work. Heres what I did: I had many scripts in one dir that shared many things; subroutines, global variables and modules. I wanted to clean things up, so I created a module called global.pm structured like this: --- use strict; ## Local parameters our $cgibin = http://path/cgi-bin;; our $htmldir = /apache/htdocs our $a = /some/path; our $b = /some/other/path; ## Common modules use CGI qw(:standard); use DBI; use Data::Table; ## Custom stuff require /path/to/custom/script1.pl; require /path/to/custom/script2.pl; 1; --- The custom stuff scripts all end in 1;, and are loaded with my custom subroutines. For example, I have one called cgi.pl, that contains all subs for cgi related tasks, i.e. checkUser(), which verifies a users cookie. Each cgi simply calls 'use global;' and then off we go. However, after moving all this stuff into /perl, none of the subs in the custom .pl files are found, I get a complaint: Undefined Subroutine Apache::ROOT::compar_2ecgi::checkUser called at . compare.cgi calls 'use global;' and then 'checkUser()'. What am I doing wrong with this? Any ideas? Thanks! Bryan
RE: Porting CGI scripts help needed
Heres what I did: I had many scripts in one dir that shared many things; subroutines, global variables and modules. I wanted to clean things up, so I created a module called global.pm structured like this: snip The custom stuff scripts all end in 1;, and are loaded with my custom subroutines. For example, I have one called cgi.pl, that contains all subs for cgi related tasks, i.e. checkUser(), which verifies a users cookie. Each cgi simply calls 'use global;' and then off we go. However, after moving all this stuff into /perl, none of the subs in the custom .pl files are found, I get a complaint: Undefined Subroutine Apache::ROOT::compar_2ecgi::checkUser called at . compare.cgi calls 'use global;' and then 'checkUser()'. global.pm isn't exporting the symbol names it's defining. if you were to refer to global::checkUser() in one of your scripts, and it worked, then mebbe an EXPORT() list for global.pm is in order so that the function names get defined in the package (Apache::ROOT::compar_2ecgi, made up by apache on the spot) that is accessing them. HTH! L8r, Rob
Re: porting mod_perl content handler to CGI
On Fri, Nov 17, 2000 at 11:53:05AM -0800, Bill Moseley wrote: Now, I'd like to use a few of my modules under CGI -- for an administration part of the application that's bigger and not used enough to use up space in the mod_perl server. But it would be nice to have a common code base. One possibility is to require My::Memory::Hog ; once you know it needs to be used, then to suicide your process when done with the request. That's not always a good idea, if your childinit takes a long time, for instance, but it may simplify your life to not have to worry about the two different environments. Before I spend much time, has this already been done? I do exactly this for a largish chunk of code, I have a Safari::Request object that I fill in from a comand-line or CGI script. You might also look at Apache::FakeRequest. I can send you mine (I posted it to this list or another list recently). There is definitely a recurring interest in runnng mod_perl scripts from command line and via CGI. That's not feasible for all scripts, but for the more "plain vanilla" ones, it should be. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: porting mod_perl content handler to CGI
Bill Moseley wrote: Howdy, I have an application that's pure mod_perl -- its modules use the request object to do a few bits of work like reading parameters, query string, specialized logging, dealing with NOT_MODIFIED, and so on. Normal stuff provided by the methods of Apache, Apache::Util, Apache::URI and Apache::Connection. Now, I'd like to use a few of my modules under CGI -- for an administration part of the application that's bigger and not used enough to use up space in the mod_perl server. But it would be nice to have a common code base. I have the stub of one I developed for Apache::ASP called Apache::ASP::CGI. I got it to the point that I could run ASP scripts from the command line, but not much farther. I was able to get scripts to run under CGI, but as I recall, I never implemented POST reading very well. If you would like to roll this into a CGI::Apache or Apache::CGI, that would be great. You can find this package in the body of the ASP.pm module. --Joshua - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: porting DBI to Apache::DBI
"James Array" [EMAIL PROTECTED] wrote:
Haloo
I'm confusing of how to port DBI CGI to Apache::DBI mod_perl with
Apache::Registry
for the most efficient:
if my normal DBI CGI is:
use strict;
use DBI;
my $dbh=DBI-connect("database","login","password","mysql");
..
$dbh-disconnect;
=
when port to Apache::DBI should I modify it as
1:
use strict;
use DBI;
use vars qw($dbh);
$dbh=DBI-connect("database","login","password","mysql");
$dbh-disconnect;
This would be a good try. If Apache::DBI is loaded first, it will cache
connections and create a new one only if there isn't an existing connection
for the particular combination of connection arguments. More details should
available in the Apache::DBI perldoc.
You definitely want to go with a `use vars' for $dbh if it can't be localized
to a subroutine. But then, I haven't done Apache::Registry scripts for so
long, I can't remember for sure (most of my code now is modules). You might
want to check out the mod_perl Guide on that one.
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
Re: Porting to Apache::Registry
At 08:54 AM 10/20/99 +0200, Stas Bekman wrote: Besides all the information at perl.apache.org, can you recommend any good resources (book, web pages) that stand out in your memory as being very helpful when you were starting out? I'm not sure why have you discarded the docs at perl.apache.org so fast, did you read them at all? Did you take a look at the guide? perl.apache.org/guide I said "besides", not that I discarded the docs you mention. I did read the Guide. It's helpful and a wonderful bit of work. But I still have questions and I haven't been at this long enough to grok it all in. For example, you say: "Perl's exit() built-in function cannot be used in mod_perl scripts." I started to edit my scripts per the examples in the Guide, but then decided to try it first, and, it turns out, exit() works without explicitly overriding in my script. Reading perldoc Apache::Registry again, I see that exit is overridden automatically. Confusing to a newcomer, no? My CGI scripts were, in a BEGIN block, opening STDERR to a file (and using that file as a lock file). But now I see that STDERR is reset next time my script is called. Where can I read about that and other similar behavior that I should be aware of? How do I find out why die() is causing a diagnostics message being sent to the client? I'm not using Carp or any __WARN__ or __DIE__ handlers in my script or in the startup.pl file. Bill Moseley mailto:[EMAIL PROTECTED]
Re: Porting to Apache::Registry
At 08:54 AM 10/20/99 +0200, Stas Bekman wrote: Besides all the information at perl.apache.org, can you recommend any good resources (book, web pages) that stand out in your memory as being very helpful when you were starting out? I'm not sure why have you discarded the docs at perl.apache.org so fast, did you read them at all? Did you take a look at the guide? perl.apache.org/guide I said "besides", not that I discarded the docs you mention. 99% of the info you can find about mod_perl located at perl.apache.org, there are a few articles written here and there, but if you don't find the info *about modperl* at modperl site, I'm not sure you will find it elsewhere... See below for the info about the book... I did read the Guide. It's helpful and a wonderful bit of work. But I still have questions and I haven't been at this long enough to grok it all in. For example, you say: "Perl's exit() built-in function cannot be used in mod_perl scripts." I started to edit my scripts per the examples in the Guide, but then decided to try it first, and, it turns out, exit() works without explicitly overriding in my script. Reading perldoc Apache::Registry again, I see that exit is overridden automatically. I beg your pardon, did you read the whole section or only the first sentence? I'm not hiding it, in third para of: http://perl.apache.org/guide/porting.html#Using_exit_ clearly written the following: QUOTE Note that if you run the script under Apache::Registry, The Apache function exit() overrides the Perl core built-in function. While you see the exit() listed in @EXPORT_OK of Apache package, Apache::Registry makes something you don't see and imports this function for you. This means that if your script is running under Apache::Registry handler (Apache::PerlRun as well), you don't have to worry about exit(). /QUOTE Confusing to a newcomer, no? If you read the whole thing, definitely not confusing. Sorry if I sound harsh, But it's a known excuse some folks use to get a free ride: "I read the docs, and didn't find the answer. Can you please tell me...". Again, I'm not trying to offend you, Bill. Just a request to truly RTFM before asking questions. I think it's pretty fair to the folks who spend their time to answer questions. My CGI scripts were, in a BEGIN block, opening STDERR to a file (and using that file as a lock file). But now I see that STDERR is reset next time my script is called. Where can I read about that and other similar behavior that I should be aware of? In the wonderful book Doug and Lincoln wrote, see www.modperl.com STDERR is being tied by apache to error_log file. I'll add this note to the guide. BEGIN blocks are being run only once per process life: http://perl.apache.org/guide/porting.html#BEGIN_blocks How do I find out why die() is causing a diagnostics message being sent to the client? I'm not using Carp or any __WARN__ or __DIE__ handlers in my script or in the startup.pl file. I beleive, it's because of your previous statement -- you break the tied STDERR and all the output goes to STDOUT. Don't mungle with STDERR unless you know what are you doing. Though it can be because of another reason... Hope this helps... ___ Stas Bekman mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: Porting to Apache::Registry
I'm just starting in on porting some scripts over to either Apache::Registry or Apache::PerlRun, and trying to absorb as much as I can. It's seems a bit overwhelming at first. My scripts are reasonably clean, running under -w and use strict, yet I'm sure I have lots of porting issues to deal with. I understand that it's hard to answer without knowing details about my setup, but in general are the speed gains with Apahce::Registry over Apache::PerlRun worth the extra porting work? Besides all the information at perl.apache.org, can you recommend any good resources (book, web pages) that stand out in your memory as being very helpful when you were starting out? I'm not sure why have you discarded the docs at perl.apache.org so fast, did you read them at all? Did you take a look at the guide? perl.apache.org/guide I have a bunch of questions, of course, such as: Under Apache::Registry do I have to be aware of other Apache::Registry scripts that may be running under the same server process as my program? For example, I often open STDERR to a log file in my CGI scripts. Will all scripts running on that process then write to my log file? And I often have a public CGI script, and an 'Admin' script where the public script opens a log file (using STDERR) with a share lock, but the 'Admin' script opens with an exclusive lock on the same file when updating config files. It would seem to make sense to not have to open and close the log file for each execution, but rather leave the file open and just grab and release the lock during execution.But I'm really unclear how to set this up under Apache::Registry and if there are race conditions to worry about. Anyway, I'm really seeking pointers on good references for just starting out that will help me answer these type of questions and keep me quite for a while. Thanks very much, Bill Moseley mailto:[EMAIL PROTECTED] ___ Stas Bekman mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
