Thread: [Codestriker-user] mod_perl issues under Windows
Brought to you by:
sits
Menu
▾
▴
codestriker-user
|
From: Nicolae B. <nic...@te...> - 2010-05-12 12:10:53
|
Hi all, After spending a few hours trying to debug the back-end Perl code, I realized that the following setup has fundamental drawbacks: 1) Windows (XP 64bit - probably does not matter) 2) Apache 1.3 3) mod_perl So the issues are: 1) Cannot execute the highlighted (no errors though) 2) Cannot execute svn.exe 3) UTF-8 (Hebrew/Arabic) topic titles are incorrectly displayed in the active topic list page (hit the "List Open Topics", do not just go to codestriker/codestriker.pl) 4) UTF-8 (Hebrew/Arabic) topic titles are incorrectly displayed in the main topic page. Apparently the "system(<command-to-execute>)" call always returns "No such file or directory" no matter what is passed to it - could be that this message refers to a missing library - cannot tell. At any rate, I have to disable mod_perl entirely now, and go back to the much slower cgi-bin implementation, which does not have any of these issues. If anyone knows how I can use mod_perl with Apache (ideally Apache 2.2) without these issues, please let me know. Thanks, Nick |
|
From: David S. <dav...@gm...> - 2010-05-13 05:18:00
|
Hi Nicolae, I have always found from experience Windows + mod_perl simply don't mix well. Maybe apache2 is better (and is worth trying), but I always had problems with it. I usually use Linux as my back-end box. Mod_perl is a bit of black-magic, so I am not surprised it doesn't work well under Windows. Cheers, David |
|
From: Nicolae B. <nic...@te...> - 2010-05-13 05:41:25
|
Thanks David, Maybe it is worth calling these issues out in the documentation. Could save someone else's time. Thanks, Nick -----Original Message----- From: David Sitsky [mailto:dav...@gm...] Sent: Thursday, May 13, 2010 8:18 AM To: Nicolae Badiu Cc: cod...@li... Subject: Re: [Codestriker-user] mod_perl issues under Windows Hi Nicolae, I have always found from experience Windows + mod_perl simply don't mix well. Maybe apache2 is better (and is worth trying), but I always had problems with it. I usually use Linux as my back-end box. Mod_perl is a bit of black-magic, so I am not surprised it doesn't work well under Windows. Cheers, David |
|
From: David S. <dav...@gm...> - 2010-05-13 09:43:15
|
You are probably right. I don't like ruling it out completely, as I have had windows + mod_perl work in the past, but it seems very temperamental, and its hard to know what combination causes it. Which version of perl and distro are you using? So no useful error messages in apache's error log files? >From memory, a lot of it had to do with how they changed the rules with executing processes (like svn and the highlight program) in a mod_perl environment. That said - it all works fine on Unix boxes. On Thu, May 13, 2010 at 3:41 PM, Nicolae Badiu <nic...@te...> wrote: > Thanks David, > > Maybe it is worth calling these issues out in the documentation. Could save someone else's time. > > Thanks, > Nick > > -----Original Message----- > From: David Sitsky [mailto:dav...@gm...] > Sent: Thursday, May 13, 2010 8:18 AM > To: Nicolae Badiu > Cc: cod...@li... > Subject: Re: [Codestriker-user] mod_perl issues under Windows > > Hi Nicolae, > > I have always found from experience Windows + mod_perl simply don't > mix well. Maybe apache2 is better (and is worth trying), but I always > had problems with it. > > I usually use Linux as my back-end box. Mod_perl is a bit of > black-magic, so I am not surprised it doesn't work well under Windows. > > Cheers, > David > |
|
From: Nicolae B. <nic...@te...> - 2010-05-13 09:52:35
|
Hi David,
I am using ActivePerl 5.8.9 build 827 and Apache 1.3.33.
There were two errors I noticed. In the Codestriker.pm execute_command subroutine (see relevant excerpt below):
1) any assignment to the $command_tmpdir variable within the eval block would result in an error (was not able to tell which though)
2) after commenting out the assignments, the system(...) subroutine returned $! as "No such file or directory". I played around with the parameters and tried it against simple commands such as "dir" or "C:\svn.exe" (which existed). The permissions were there a.s.o. I assume the error message actually refers to some missing library, some .so file.
Thanks,
Nick
my $command_tmpdir;
eval {
if (exists $ENV{'MOD_PERL'} ||
(defined($ENV{'SERVER_SOFTWARE'}) && $ENV{'SERVER_SOFTWARE'} =~ /IIS/)) {
# The open3() call doesn't work under mod_perl/apache2,
# so create a command which stores the stdout and stderr
# into temporary files. It also seems flacky under IIS.
if (defined $Codestriker::tmpdir && $Codestriker::tmpdir ne "") {
$command_tmpdir = tempdir(DIR => $Codestriker::tmpdir);
} else {
$command_tmpdir = tempdir();
}
# Build up the command string with naive quoting.
my $command_line = "\"$command\"";
foreach my $arg (@args) {
$command_line .= " \"$arg\"";
}
my $stdout_filename = "$command_tmpdir/stdout.txt";
my $stderr_filename = "$command_tmpdir/stderr.txt";
# Thankfully this works under Windows.
my $system_line =
"$command_line > \"$stdout_filename\" 2> \"$stderr_filename\"";
system($system_line) == 0 ||
croak "Failed to execute $system_line: $!\n";
-----Original Message-----
From: David Sitsky [mailto:dav...@gm...]
Sent: Thursday, May 13, 2010 12:43 PM
To: Nicolae Badiu
Cc: cod...@li...
Subject: Re: [Codestriker-user] mod_perl issues under Windows
You are probably right. I don't like ruling it out completely, as I
have had windows + mod_perl work in the past, but it seems very
temperamental, and its hard to know what combination causes it. Which
version of perl and distro are you using?
So no useful error messages in apache's error log files?
>From memory, a lot of it had to do with how they changed the rules
with executing processes (like svn and the highlight program) in a
mod_perl environment.
That said - it all works fine on Unix boxes.
On Thu, May 13, 2010 at 3:41 PM, Nicolae Badiu <nic...@te...> wrote:
> Thanks David,
>
> Maybe it is worth calling these issues out in the documentation. Could save someone else's time.
>
> Thanks,
> Nick
>
> -----Original Message-----
> From: David Sitsky [mailto:dav...@gm...]
> Sent: Thursday, May 13, 2010 8:18 AM
> To: Nicolae Badiu
> Cc: cod...@li...
> Subject: Re: [Codestriker-user] mod_perl issues under Windows
>
> Hi Nicolae,
>
> I have always found from experience Windows + mod_perl simply don't
> mix well. Maybe apache2 is better (and is worth trying), but I always
> had problems with it.
>
> I usually use Linux as my back-end box. Mod_perl is a bit of
> black-magic, so I am not surprised it doesn't work well under Windows.
>
> Cheers,
> David
>
|
|
From: David S. <dav...@gm...> - 2010-05-13 10:09:56
|
Strange. Being windows, and mod_perl, you might have to explicitly
set the PATH in your apache config to get around this, so that certain
executables can run?
On Thu, May 13, 2010 at 7:52 PM, Nicolae Badiu <nic...@te...> wrote:
> Hi David,
>
> I am using ActivePerl 5.8.9 build 827 and Apache 1.3.33.
>
> There were two errors I noticed. In the Codestriker.pm execute_command subroutine (see relevant excerpt below):
> 1) any assignment to the $command_tmpdir variable within the eval block would result in an error (was not able to tell which though)
> 2) after commenting out the assignments, the system(...) subroutine returned $! as "No such file or directory". I played around with the parameters and tried it against simple commands such as "dir" or "C:\svn.exe" (which existed). The permissions were there a.s.o. I assume the error message actually refers to some missing library, some .so file.
>
> Thanks,
> Nick
>
> my $command_tmpdir;
> eval {
> if (exists $ENV{'MOD_PERL'} ||
> (defined($ENV{'SERVER_SOFTWARE'}) && $ENV{'SERVER_SOFTWARE'} =~ /IIS/)) {
> # The open3() call doesn't work under mod_perl/apache2,
> # so create a command which stores the stdout and stderr
> # into temporary files. It also seems flacky under IIS.
> if (defined $Codestriker::tmpdir && $Codestriker::tmpdir ne "") {
> $command_tmpdir = tempdir(DIR => $Codestriker::tmpdir);
> } else {
> $command_tmpdir = tempdir();
> }
>
> # Build up the command string with naive quoting.
> my $command_line = "\"$command\"";
> foreach my $arg (@args) {
> $command_line .= " \"$arg\"";
> }
>
> my $stdout_filename = "$command_tmpdir/stdout.txt";
> my $stderr_filename = "$command_tmpdir/stderr.txt";
>
> # Thankfully this works under Windows.
> my $system_line =
> "$command_line > \"$stdout_filename\" 2> \"$stderr_filename\"";
> system($system_line) == 0 ||
> croak "Failed to execute $system_line: $!\n";
>
>
>
>
> -----Original Message-----
> From: David Sitsky [mailto:dav...@gm...]
> Sent: Thursday, May 13, 2010 12:43 PM
> To: Nicolae Badiu
> Cc: cod...@li...
> Subject: Re: [Codestriker-user] mod_perl issues under Windows
>
> You are probably right. I don't like ruling it out completely, as I
> have had windows + mod_perl work in the past, but it seems very
> temperamental, and its hard to know what combination causes it. Which
> version of perl and distro are you using?
>
> So no useful error messages in apache's error log files?
>
> From memory, a lot of it had to do with how they changed the rules
> with executing processes (like svn and the highlight program) in a
> mod_perl environment.
>
> That said - it all works fine on Unix boxes.
>
> On Thu, May 13, 2010 at 3:41 PM, Nicolae Badiu <nic...@te...> wrote:
>> Thanks David,
>>
>> Maybe it is worth calling these issues out in the documentation. Could save someone else's time.
>>
>> Thanks,
>> Nick
>>
>> -----Original Message-----
>> From: David Sitsky [mailto:dav...@gm...]
>> Sent: Thursday, May 13, 2010 8:18 AM
>> To: Nicolae Badiu
>> Cc: cod...@li...
>> Subject: Re: [Codestriker-user] mod_perl issues under Windows
>>
>> Hi Nicolae,
>>
>> I have always found from experience Windows + mod_perl simply don't
>> mix well. Maybe apache2 is better (and is worth trying), but I always
>> had problems with it.
>>
>> I usually use Linux as my back-end box. Mod_perl is a bit of
>> black-magic, so I am not surprised it doesn't work well under Windows.
>>
>> Cheers,
>> David
>>
>
|
|
From: Nicolae B. <nic...@te...> - 2010-05-13 10:14:22
|
I could try that, but still, what about the first error? As I said, it does not even get to the point of running system(...). It stops here:
$command_tmpdir = tempdir(DIR => $Codestriker::tmpdir);
The tempdir(...) invocation seems to work ok. Any assignment to this variable fails.
-----Original Message-----
From: David Sitsky [mailto:dav...@gm...]
Sent: Thursday, May 13, 2010 1:10 PM
To: Nicolae Badiu
Cc: cod...@li...
Subject: Re: [Codestriker-user] mod_perl issues under Windows
Strange. Being windows, and mod_perl, you might have to explicitly
set the PATH in your apache config to get around this, so that certain
executables can run?
On Thu, May 13, 2010 at 7:52 PM, Nicolae Badiu <nic...@te...> wrote:
> Hi David,
>
> I am using ActivePerl 5.8.9 build 827 and Apache 1.3.33.
>
> There were two errors I noticed. In the Codestriker.pm execute_command subroutine (see relevant excerpt below):
> 1) any assignment to the $command_tmpdir variable within the eval block would result in an error (was not able to tell which though)
> 2) after commenting out the assignments, the system(...) subroutine returned $! as "No such file or directory". I played around with the parameters and tried it against simple commands such as "dir" or "C:\svn.exe" (which existed). The permissions were there a.s.o. I assume the error message actually refers to some missing library, some .so file.
>
> Thanks,
> Nick
>
> my $command_tmpdir;
> eval {
> if (exists $ENV{'MOD_PERL'} ||
> (defined($ENV{'SERVER_SOFTWARE'}) && $ENV{'SERVER_SOFTWARE'} =~ /IIS/)) {
> # The open3() call doesn't work under mod_perl/apache2,
> # so create a command which stores the stdout and stderr
> # into temporary files. It also seems flacky under IIS.
> if (defined $Codestriker::tmpdir && $Codestriker::tmpdir ne "") {
> $command_tmpdir = tempdir(DIR => $Codestriker::tmpdir);
> } else {
> $command_tmpdir = tempdir();
> }
>
> # Build up the command string with naive quoting.
> my $command_line = "\"$command\"";
> foreach my $arg (@args) {
> $command_line .= " \"$arg\"";
> }
>
> my $stdout_filename = "$command_tmpdir/stdout.txt";
> my $stderr_filename = "$command_tmpdir/stderr.txt";
>
> # Thankfully this works under Windows.
> my $system_line =
> "$command_line > \"$stdout_filename\" 2> \"$stderr_filename\"";
> system($system_line) == 0 ||
> croak "Failed to execute $system_line: $!\n";
>
>
>
>
> -----Original Message-----
> From: David Sitsky [mailto:dav...@gm...]
> Sent: Thursday, May 13, 2010 12:43 PM
> To: Nicolae Badiu
> Cc: cod...@li...
> Subject: Re: [Codestriker-user] mod_perl issues under Windows
>
> You are probably right. I don't like ruling it out completely, as I
> have had windows + mod_perl work in the past, but it seems very
> temperamental, and its hard to know what combination causes it. Which
> version of perl and distro are you using?
>
> So no useful error messages in apache's error log files?
>
> From memory, a lot of it had to do with how they changed the rules
> with executing processes (like svn and the highlight program) in a
> mod_perl environment.
>
> That said - it all works fine on Unix boxes.
>
> On Thu, May 13, 2010 at 3:41 PM, Nicolae Badiu <nic...@te...> wrote:
>> Thanks David,
>>
>> Maybe it is worth calling these issues out in the documentation. Could save someone else's time.
>>
>> Thanks,
>> Nick
>>
>> -----Original Message-----
>> From: David Sitsky [mailto:dav...@gm...]
>> Sent: Thursday, May 13, 2010 8:18 AM
>> To: Nicolae Badiu
>> Cc: cod...@li...
>> Subject: Re: [Codestriker-user] mod_perl issues under Windows
>>
>> Hi Nicolae,
>>
>> I have always found from experience Windows + mod_perl simply don't
>> mix well. Maybe apache2 is better (and is worth trying), but I always
>> had problems with it.
>>
>> I usually use Linux as my back-end box. Mod_perl is a bit of
>> black-magic, so I am not surprised it doesn't work well under Windows.
>>
>> Cheers,
>> David
>>
>
|
|
From: David S. <dav...@gm...> - 2010-05-13 11:06:28
|
What if you use specify $Codestriker::tmpdir as ''. Does it make any
difference?
Also - what if you move the tempdir call outside the eval block. Do
you see a more sensible error message?
On Thu, May 13, 2010 at 8:11 PM, Nicolae Badiu <nic...@te...> wrote:
> I could try that, but still, what about the first error? As I said, it does not even get to the point of running system(...). It stops here:
>
> $command_tmpdir = tempdir(DIR => $Codestriker::tmpdir);
>
> The tempdir(...) invocation seems to work ok. Any assignment to this variable fails.
>
> -----Original Message-----
> From: David Sitsky [mailto:dav...@gm...]
> Sent: Thursday, May 13, 2010 1:10 PM
> To: Nicolae Badiu
> Cc: cod...@li...
> Subject: Re: [Codestriker-user] mod_perl issues under Windows
>
> Strange. Being windows, and mod_perl, you might have to explicitly
> set the PATH in your apache config to get around this, so that certain
> executables can run?
>
> On Thu, May 13, 2010 at 7:52 PM, Nicolae Badiu <nic...@te...> wrote:
>> Hi David,
>>
>> I am using ActivePerl 5.8.9 build 827 and Apache 1.3.33.
>>
>> There were two errors I noticed. In the Codestriker.pm execute_command subroutine (see relevant excerpt below):
>> 1) any assignment to the $command_tmpdir variable within the eval block would result in an error (was not able to tell which though)
>> 2) after commenting out the assignments, the system(...) subroutine returned $! as "No such file or directory". I played around with the parameters and tried it against simple commands such as "dir" or "C:\svn.exe" (which existed). The permissions were there a.s.o. I assume the error message actually refers to some missing library, some .so file.
>>
>> Thanks,
>> Nick
>>
>> my $command_tmpdir;
>> eval {
>> if (exists $ENV{'MOD_PERL'} ||
>> (defined($ENV{'SERVER_SOFTWARE'}) && $ENV{'SERVER_SOFTWARE'} =~ /IIS/)) {
>> # The open3() call doesn't work under mod_perl/apache2,
>> # so create a command which stores the stdout and stderr
>> # into temporary files. It also seems flacky under IIS.
>> if (defined $Codestriker::tmpdir && $Codestriker::tmpdir ne "") {
>> $command_tmpdir = tempdir(DIR => $Codestriker::tmpdir);
>> } else {
>> $command_tmpdir = tempdir();
>> }
>>
>> # Build up the command string with naive quoting.
>> my $command_line = "\"$command\"";
>> foreach my $arg (@args) {
>> $command_line .= " \"$arg\"";
>> }
>>
>> my $stdout_filename = "$command_tmpdir/stdout.txt";
>> my $stderr_filename = "$command_tmpdir/stderr.txt";
>>
>> # Thankfully this works under Windows.
>> my $system_line =
>> "$command_line > \"$stdout_filename\" 2> \"$stderr_filename\"";
>> system($system_line) == 0 ||
>> croak "Failed to execute $system_line: $!\n";
>>
>>
>>
>>
>> -----Original Message-----
>> From: David Sitsky [mailto:dav...@gm...]
>> Sent: Thursday, May 13, 2010 12:43 PM
>> To: Nicolae Badiu
>> Cc: cod...@li...
>> Subject: Re: [Codestriker-user] mod_perl issues under Windows
>>
>> You are probably right. I don't like ruling it out completely, as I
>> have had windows + mod_perl work in the past, but it seems very
>> temperamental, and its hard to know what combination causes it. Which
>> version of perl and distro are you using?
>>
>> So no useful error messages in apache's error log files?
>>
>> From memory, a lot of it had to do with how they changed the rules
>> with executing processes (like svn and the highlight program) in a
>> mod_perl environment.
>>
>> That said - it all works fine on Unix boxes.
>>
>> On Thu, May 13, 2010 at 3:41 PM, Nicolae Badiu <nic...@te...> wrote:
>>> Thanks David,
>>>
>>> Maybe it is worth calling these issues out in the documentation. Could save someone else's time.
>>>
>>> Thanks,
>>> Nick
>>>
>>> -----Original Message-----
>>> From: David Sitsky [mailto:dav...@gm...]
>>> Sent: Thursday, May 13, 2010 8:18 AM
>>> To: Nicolae Badiu
>>> Cc: cod...@li...
>>> Subject: Re: [Codestriker-user] mod_perl issues under Windows
>>>
>>> Hi Nicolae,
>>>
>>> I have always found from experience Windows + mod_perl simply don't
>>> mix well. Maybe apache2 is better (and is worth trying), but I always
>>> had problems with it.
>>>
>>> I usually use Linux as my back-end box. Mod_perl is a bit of
>>> black-magic, so I am not surprised it doesn't work well under Windows.
>>>
>>> Cheers,
>>> David
>>>
>>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X