I think it's not Apache that "opens the file with kwrite", it is that Apache sends the file instead of executing it, and your local desktop environment decides to open a text file with kwrite.

Are you sure that your Perl script is marked as executable? This is mainly an Apache configuration issue, so you will have to post the .htaccess or the (relevant parts of your) Apache configuration.

On your number 1 question:
In my experience, I have used #!/usr/bin/perl even on windows with no problems.
So, I don't think you have to have two different scripts.
Though some function in perl which has their origin in *nix "might" not port well on windows, but even at that there are several "walk" arounds.

Regarding Apache. You can insure that .cgi, .pl scripts fire off (are executed by Perl) on a per-directory basis, by adding the following within the <Directory "/path/some/where"> sections

# Helps insure .cgi and .pl files are loaded
    MultiviewsMatch Handlers Filters
    AddHandler cgi-script cgi
    AddHandler cgi-script pl
[download]

Options Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI
[download]

    # ScriptAlias: This controls which directories contain server scri
+pts.
    # ScriptAliases are essentially the same as Aliases, except that
    # documents in the target directory are treated as applications an
+d
    # run by the server when requested rather than as documents sent t
+o the
    # client.  The same rules about trailing "/" apply to ScriptAlias
    # directives as to Alias.
    #

# DO modify the following line "the second part" to
# reflect the EXACT location of your cgi-bin directory -- I think it's
# /var/www/cgi-bin, or /opt/... on Linux flavors. You'll need to check

    ScriptAlias /cgi-bin/ "/usr/local/www/cgi-bin/"
[download]

LoadModule cgi_module libexec/apache22/mod_cgi.so
[download]

I realize this is a bit "choppy", and does not read like a book. But I've done so intentionally. As each section has a different meaning/affect, and will better help you discover which parts are pertinent to the problem you are having. While I don't use Apache. I did use it in it's very beginnings, when it was simply known as HTTPd. Given it was back then simply a "patched-up" version of NCSA -- NCSA HTTPd. It took on the name "Apache" -- or "A patch". Since then, I've written, and use my own HTTPd server.

Hope this helps, and best wishes.

--Chris

Yes. What say about me, is true.

I am healthily suspicious of the behavior that you are attributing to OpenSuse:   the behavior should be exactly the same.   Focusing your attention now to just this environment ... take a careful step back, look once again at all the config files, be sure you’ve restarted, and then look at the access.log and error.log files once more; checking, also, one environment against the other.

The fundamental reason why you are seeing kwrite is the Apache is not executing the file ... Apache is serving it as text.   This must be an error ... uhh, your error ... in the setup of the apache configuration on Linux.   Windows is now set up correctly; Linux is not.

(So, anything having to do with file-permissions, or “shebangs,” must in fact be a red-herring of some kind.   ’Tis easy in this biz to chase white-rabbits.   We all do, from time to time, especially where Apache is concerned.)

Since you say that you are much less familiar with Linux, perhaps you can tell us a little bit more about how your Apache config is set-up with regard to the specific directory where these files are located:   the environs where, in Linux, you have placed the AddHandler directive ...

1) I assume that on Linux your scripts have unix style line endings, i.e. linefeed as opposed to windows carriage return linefeed. A bang line of "#!/usr/bin/perl^M" would try to run perl^M which wouldn't exist. Below is one way to check. Note the \r after p e r l

od -c delme.perl | head
0000000   #   !   /   u   s   r   /   b   i   n   /   p   e   r   l  \
+r
0000020  \n   ..... etc ...
[download]

Though if the bang line was the problem I'd think you would get a 500 server error, rather than have the file served up to you.

2) chmod 700 will work only if the owner of the script is the same as the effective user that apache runs as. You could try chmod 755 instead.

As others have suggested the problem may lie in your apache configuration. Perhaps your cgi-bin is screwy. I don't think apache on linux needs to know that ".pl" files are associated with /usr/bin/perl, nor does the ".pl" file name extension need to be associated with cgi programs as long as the files are under your cgi-bin directory and not under your docs directory. It's been a while since I worked with apache, so I could be mistaken.

Hi,

On windows you can use the Association stuff to let windows recognize that any file with, say, a .pl extension should be run by Perl.

I leave it to you to sort this out, if you need to.

J.C.

... please don't be too harsh if I missed something basic. ;-)

what documentation are you reading? Try http://perl.apache.org/docs/2.0/user/intro/start_fast.html

There's a couple of ways you can manage this

#!/home/ivan/bin/perl
#!/usr/bin/perl
[download]

#!/usr/bin/env perl
[download]

HTH

--Chris

Yes. What say about me, is true.

Irrelevant to any diff between Win and *nix behavior; wrong, and another instance of taint diving down a rabbit hole while chasing a giraffe.

Quis custodiet ipsos custodes. Juvenal, Satires

Thanks to all who replied. I would have replied earlier, but it has been an insane couple weeks. NB: one or two responders refered to documentation for mod_perl, but as I didn't have mod_perl on the Windows box, I don't use it, and write my basic cgi scripts in perl.

The situation has gotten weirder and weirder.

I had a workstation in which the only drive failed. I replaced the drive, and installed OpenSuse 12.3. I then immediately use the live update to upgrade to OpenSuse 13.1. I then installed all the applications and libraries I normally use, and then tested the install of Apache2. The version of Perl on this machine is 5.18, and Apache is 2.4.6.

Low and behold, everything works: Perl scripts in the cgi-bin directory, php5 scripts anywhere. It was also significantly faster, so, for both reasons, I upgraded the OpenSuse box on which the cgi scripts failed, and this using the same method that I used on the workstation in which I replaced the drive. But, on this machine, the problem persists. It is not executing the cgi scripts. What makes this especially weird is that the configuration files are identical. I do not understand how that can be. Precisely the same apache packages are installed, and the identical set of perl packages are installed, and the configuration files are identical, and yet on the one machine everything works and on the other, the cgi scripts all fail (and yes, the cgi scripts in question are also identical). I think I will have to move this over to the opensuse users group, as I suspect there is something else awry here, unrelated to perl.

Thanks again

Ted