Quantcast

mod_perl issues under Windows

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

mod_perl issues under Windows

Nicolae Badiu

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


------------------------------------------------------------------------------


_______________________________________________
Codestriker-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/codestriker-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_perl issues under Windows

David Sitsky
Administrator
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

------------------------------------------------------------------------------

_______________________________________________
Codestriker-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/codestriker-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_perl issues under Windows

Nicolae Badiu
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:[hidden email]]
Sent: Thursday, May 13, 2010 8:18 AM
To: Nicolae Badiu
Cc: [hidden email]
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

------------------------------------------------------------------------------

_______________________________________________
Codestriker-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/codestriker-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_perl issues under Windows

David Sitsky
Administrator
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 <[hidden email]> 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:[hidden email]]
> Sent: Thursday, May 13, 2010 8:18 AM
> To: Nicolae Badiu
> Cc: [hidden email]
> 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
>

------------------------------------------------------------------------------

_______________________________________________
Codestriker-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/codestriker-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_perl issues under Windows

Nicolae Badiu
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:[hidden email]]
Sent: Thursday, May 13, 2010 12:43 PM
To: Nicolae Badiu
Cc: [hidden email]
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 <[hidden email]> 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:[hidden email]]
> Sent: Thursday, May 13, 2010 8:18 AM
> To: Nicolae Badiu
> Cc: [hidden email]
> 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
>

------------------------------------------------------------------------------

_______________________________________________
Codestriker-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/codestriker-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_perl issues under Windows

David Sitsky
Administrator
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 <[hidden email]> 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:[hidden email]]
> Sent: Thursday, May 13, 2010 12:43 PM
> To: Nicolae Badiu
> Cc: [hidden email]
> 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 <[hidden email]> 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:[hidden email]]
>> Sent: Thursday, May 13, 2010 8:18 AM
>> To: Nicolae Badiu
>> Cc: [hidden email]
>> 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
>>
>

------------------------------------------------------------------------------

_______________________________________________
Codestriker-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/codestriker-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_perl issues under Windows

Nicolae Badiu
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:[hidden email]]
Sent: Thursday, May 13, 2010 1:10 PM
To: Nicolae Badiu
Cc: [hidden email]
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 <[hidden email]> 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:[hidden email]]
> Sent: Thursday, May 13, 2010 12:43 PM
> To: Nicolae Badiu
> Cc: [hidden email]
> 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 <[hidden email]> 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:[hidden email]]
>> Sent: Thursday, May 13, 2010 8:18 AM
>> To: Nicolae Badiu
>> Cc: [hidden email]
>> 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
>>
>

------------------------------------------------------------------------------

_______________________________________________
Codestriker-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/codestriker-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mod_perl issues under Windows

David Sitsky
Administrator
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 <[hidden email]> 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:[hidden email]]
> Sent: Thursday, May 13, 2010 1:10 PM
> To: Nicolae Badiu
> Cc: [hidden email]
> 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 <[hidden email]> 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:[hidden email]]
>> Sent: Thursday, May 13, 2010 12:43 PM
>> To: Nicolae Badiu
>> Cc: [hidden email]
>> 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 <[hidden email]> 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:[hidden email]]
>>> Sent: Thursday, May 13, 2010 8:18 AM
>>> To: Nicolae Badiu
>>> Cc: [hidden email]
>>> 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
>>>
>>
>

------------------------------------------------------------------------------

_______________________________________________
Codestriker-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/codestriker-user
Loading...