Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3

by ted.byers (Monk)
on Dec 20, 2013 at 06:08 UTC ( #1067919=perlquestion: print w/replies, xml ) Need Help??
ted.byers has asked for the wisdom of the Perl Monks concerning the following question:

I have two differences that are proving to be intransigent.

1) On Windows, I can set $!perl on the first line, and since perl is in the path, Windows finds it and executes the script. On linux, I have found the hard way that I have to use #!/usr/bin/perl. Otherwise, Linux refuses to execute the script. Obviously, this means I can not use a single set of files that will run on both Windows and Linux. Rather, I have to maintain two sets of files in which the ONLY difference is the #! line. Is there a way to work around this, so that identical code will run properly on both platforms; and that without taking a performance hit?

2) In my apache2 configuration, in my cgi-bin configuration, I have an AddHandler statement that associates perl-script with all files in cgi-bin with the .pl extension (and I did remember to restart apache after adding that AddHandler statement). On Windows, this was sufficent. Without it, on OpenSuse Linux, apache tells me that the file doesn't exist. But, with it, apache offers to open the file with kwrite, instead of executing it. I DID use chmod 700 to make the file executable (though I am not sure this is correct), following a couple pages I found using Google. NB: at this time, I am not using mod_perl (though that may change soon). This is on OpenSuse 12.3. What have I missed that results in the offer to open or download the script rather than having it executed?

NB: I am in the process of learning Linux after decades of working intensely on Windows, so please don't be too harsh if I missed something basic. ;-)



  • Comment on CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3

Replies are listed 'Best First'.
Re: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
by Corion (Pope) on Dec 20, 2013 at 07:19 UTC

    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.

Re: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
by 2teez (Vicar) on Dec 20, 2013 at 06:47 UTC

    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.

    If you tell me, I'll forget.
    If you show me, I'll remember.
    if you involve me, I'll understand.
    --- Author unknown to me
Re: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
by Laurent_R (Canon) on Dec 20, 2013 at 08:11 UTC
    The so-called shebang line (#usr/bin/perl) does not have much to do with Perl, but is the traditional *nix shell way of saying which program to use to run a file. But the shebang line can be kept on Windows, which will just ignore it. Thus, this shis does not prevent you from using the same programs on bowth Windows and *nix/Linux.
Re: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
by taint (Chaplain) on Dec 20, 2013 at 14:50 UTC

    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
    But the following bits Options stanza, must also be enabled
    Options Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI
    Probably most importantly, the ExecCGI bit.
    Probably of most concern to you, is your /cgi-bin Directory stanza, in Apache. Following is a complete block for it, that should provide for your needs
    # 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/"
    Make sure that you modify, or UNcomment the line in your httpd.conf. Do not simply add the one I've provided here. :)
    Also note the Options ExecCGI must be enabled within the Directory section the line above lives in.
    Last, but not least; The following line
    LoadModule cgi_module libexec/apache22/
    must exist within your "Dynamic Shared Object (DSO) Support" section. Yours may (probably) looks a little different, but it must exist, and must not be commented -- have a hash # at the beginning of it.

    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.


    EDIT: almost forgot to note; in all cases, look for a file named .htaccess in any of your web folders. If it exists, you can make the changes, or comment # out any conflicting lines. It is probably always best to use the httpd.conf file, and not .htaccess. If for no other reason, because the server will run faster, and ultimately, causes less load on it.

    Yes. What say about me, is true.
Re: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
by sundialsvc4 (Abbot) on Dec 20, 2013 at 14:38 UTC

    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 ...

Re: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
by Anonymous Monk on Dec 20, 2013 at 07:04 UTC


    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.


Re: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
by wazat (Scribe) on Dec 20, 2013 at 17:49 UTC

    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 ...

    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.

Re: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
by Anonymous Monk on Dec 20, 2013 at 08:14 UTC
Re: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
by taint (Chaplain) on Dec 20, 2013 at 06:38 UTC
    Greetings, ted.byers.

    There's a couple of ways you can manage this

    #!/home/ivan/bin/perl #!/usr/bin/perl
    Another might be
    #!/usr/bin/env perl
    As you can see in the first example. There are 2 shebangs. In your case, it's simply a matter of providing the paths to Perl on both your boxes/environments. In the second example. It uses the (ENV)vironment's search path to discover Perl's location.



    UPDATE: It was late (for me) when I wrote this. So I didn't take the time to look up information that I knew was available since ~5.005. For completeness I'll add it here (from REAME.win32)

    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

        Off base, ww. Applies directly to 1). in the OP.
        Yes. What say about me, is true.
Re: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
by ted.byers (Monk) on Jan 02, 2014 at 02:41 UTC

    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


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1067919]
Approved by boftx
[Corion]: Meh. Once again I find that SQLite doesn't support window functions and I want to use those nowadays :-)
[erix]: Look what I found! :P
[Corion]: Hmm - actually, I don't need them, even though they'd be nice. I just want the (say) 10 latest images, and that's easily done with a limit 10 offset 0 clause, as I don't need all top 10 images for all users.
[Corion]: erix: Sure, but this is for a really-lightweight application and I'm replacing a CSV file / JSON file for user configuration with SQLite (and optionally, Pg) :)
[erix]: isn't a texty format handier for configs?
[Corion]: So far, I've avoided having even a user database by storing the user information in a (signed) cookie that the browser keeps for me, but as I want to be able to lock users, I need a second storage option :)

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (12)
As of 2018-03-20 14:02 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (253 votes). Check out past polls.