Re: active perl on IIS
Has your set-up defined Perl extension types within IIS? I haven't done this manually on 2K but in IIS 3 you can update it through the system registry under HKEY_LOCAL_SYSTEM \system\CurrentControlSet\Services\W3SVC\Parameters\Script Map. On IIS 4 you can use the 'Internet service manager'. This is a 'Microsoft Management console' application that comes with the 'Windows NT 4.0 Option Pack'. The default extensions are .pl for standard Perl script (map this to the perl.exe file) and .plx this should be mapped to the PerlIS.dll file. This file type will be interpreted by the ISAPI (Internet Server Application Programming Interface) for use by the IIS web server. A .pl file will attempt to run under the operating system not the browser. I believe what you can see working is Perl script (held within the html page) what you want is to run a Perl program from a html page. Check your .plx directories have sufficient execute rights and are attached to the IIS properly. This should be enough to make theme run. I don't know if I've explained this very well but it's relatively straightforward, honest! -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: active perl on IIS
Hi Lynn, Your FORM ACTION=c:\inetpub\scripts\sl3.pl doesn't look right; if 'scripts' is a root level (or virtual root) directory then then path would be =\scripts\s13.pl. make that change andd see what happens. regards Joel -Original Message- From: Lynn Glessner [mailto:[EMAIL PROTECTED]] Sent: 03 September 2001 06:15 To: Gunther Birznieks; yahoo; Begginers CGI Subject: Re: active perl on IIS I spoke too soon. I thought this was just a minor tweak, which it probably is ;), but the tweak is not what I thought it was going to be ... When I click the button to submit the form, instead of running the perl script I get the File Download dialog. If I choose the run the file from this location radio button - what I thought was going to be the solution - all my STDOUT is in a DOS window, and my CGI param calls don't get anything that I filled in on the form. At the end of my script I have some CGI to display in the browser that it is done, but instead those lines show up as in the DOS window. Like I had double-clicked the pl file. If I type in the path to the sl3.pl file in my browser, it executes correctly and displays those I'm done lines in my browser. I stared at the activeperl directions for configuring IIS and don't see what I'm doing wrong. .pl is associated at the top level down with the full path including perl.exe followed by %s %s. And it works if I go straight there. These html and pl files work fine with IE browser on NT and linux apache web server at work, and I'm still using IE browser, so I know the problem is my IIS configuration. Yes, in my free time I will look into running apache instead of IIS. Why do I get a file download dialog box? My html file is like this: FORM ACTION=c:\inetpub\scripts\sl3.pl METHOD=POST ENCTYPE=multipart/form-data [snipped] INPUT TYPE=SUBMIT NAME=Button VALUE=SendP /FORM _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: active perl on IIS
Sorry Lynn, should have specified a bit more why your form action 'didn't look right' to me. Basically you put an absolute file path to the perl file - specifying the drive letter etc. web servers deal in urls http:// or / or myfolder/file etc. c:\inetpub\wwwroot is the default document root for IIS so \ refers to directory c:\inetpub\wwwroot and \testfolder refers to c:\inetpub\wwwroot\testfolder - see? if you code a form action (or anchor link etc) as file absolute c:\inetpub etc the page will 'work' when you browse the website using a browser on the same machine as the webserver - because the file paths are still valid. Many webdesigners hit this issue when they upload a site only to see lots of broken images - the URLs are no longer valid. Trying out a similar example on my win2k laptop I found that submitting to a valid, tested form handling perl cgi script using a file absolute path resulted in the cgi script being returned to the browser. Now YOU clicked on run but, of course, this is too late - you are now running it OUTSIDE of the context of the IIS webserver - your client application (IE) knows nothing about CGI, the form submission you attempted etc. The CGI program NEEDED to be run within the context of the webserver where form variables etc were available to it and it could alter the response back to the client (internet explorer). To remedy this situation change your form action to /scripts/sl3.pl. hope this helps regards Joel -Original Message- From: yahoo [mailto:[EMAIL PROTECTED]] Sent: 03 September 2001 09:20 To: Begginers CGI Subject: RE: active perl on IIS Hi Lynn, Your FORM ACTION=c:\inetpub\scripts\sl3.pl doesn't look right; if 'scripts' is a root level (or virtual root) directory then then path would be =\scripts\s13.pl. make that change andd see what happens. regards Joel -Original Message- From: Lynn Glessner [mailto:[EMAIL PROTECTED]] Sent: 03 September 2001 06:15 To: Gunther Birznieks; yahoo; Begginers CGI Subject: Re: active perl on IIS I spoke too soon. I thought this was just a minor tweak, which it probably is ;), but the tweak is not what I thought it was going to be ... When I click the button to submit the form, instead of running the perl script I get the File Download dialog. If I choose the run the file from this location radio button - what I thought was going to be the solution - all my STDOUT is in a DOS window, and my CGI param calls don't get anything that I filled in on the form. At the end of my script I have some CGI to display in the browser that it is done, but instead those lines show up as in the DOS window. Like I had double-clicked the pl file. If I type in the path to the sl3.pl file in my browser, it executes correctly and displays those I'm done lines in my browser. I stared at the activeperl directions for configuring IIS and don't see what I'm doing wrong. .pl is associated at the top level down with the full path including perl.exe followed by %s %s. And it works if I go straight there. These html and pl files work fine with IE browser on NT and linux apache web server at work, and I'm still using IE browser, so I know the problem is my IIS configuration. Yes, in my free time I will look into running apache instead of IIS. Why do I get a file download dialog box? My html file is like this: FORM ACTION=c:\inetpub\scripts\sl3.pl METHOD=POST ENCTYPE=multipart/form-data [snipped] INPUT TYPE=SUBMIT NAME=Button VALUE=SendP /FORM _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: active perl on IIS
Let me also add, unlike *nix, you may run scripts from virtualy any folder you see fit on Win (within wwwroot for the web of course). Everything is really governed by the permissions and etc... you set on the folder itself. In some cases it makes sense to name the cgi folder something less obvious like, wordfiles, oldapps or the like. Be creative. This way should the casual hacker break in you stand a chance of he/ she skipping the directory. At the very least, someone is sniffing your tranfers might not suspect your moving them into an executable dir. Just a thought. MB' -Original Message- From: Lynn Glessner[EMAIL PROTECTED] To: yahoo[EMAIL PROTECTED], Begginers CGI[EMAIL PROTECTED] Date: Sun Sep 02 14:59:37 PDT 2001 Subject: Re: active perl on IIS I haven't had a chance to work on it recently, but I think it will turn out to be the .cgi extension (I'll have to go back and see who suggested that). I have my scripts in a directory which was created automatically called scripts a subdirecctory of c:\inetpub - IIS has it configured for executables. However, all my perl scripts in this directory have the extension .cgi. Double-clicking one of the example files installed by ActivePerl (those files have a .pl extension) executes fine, but my .cgi files have a generic icon - can't believe I didn't think to check that. I have the O'Reilly CGI book, with the rat/mouse on the cover, it is very helpful for CGI and Perl. I have the working version at work, it's just the implementation at home on IIS that I'm struggling with after doing my development at work. :( Thanks very much for the suggestions, I hope to be able to tackle this tonight (after my 2 year old goes to bed - she doesn't have much patience for programming yet!). From: yahoo [EMAIL PROTECTED] Date: Sun, 2 Sep 2001 18:28:47 +0100 To: [EMAIL PROTECTED] Subject: RE: active perl on IIS Hi Gunther, I think Lynn said she was looking for a book which covered IIS PerlScript - the OReilly win32 book is good for that (going hand-in-hand with ActiveStates latest documentation of course!). I don't think IIS normally pre-creates a cgi-bin for you - none of my installations have one (here is an excerpt from the IIS 5 documentation) extract To install and configure CGI applications: Set up a directory for your CGI programs. For extra security, you should separate your CGI programs from your content files. You do not need to name the directory Cgi-bin, although you can do so if you want. See Creating Virtual Directories. /extract As I said in my original email, you need to mark the directory as allowing scripting for executables inorder to get the .pl file to run. I agree with what you say about the file extension; I did mention the .pl extension in my original response. Lynn, any updates on this problem? regards Joel -Original Message- From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] Sent: 02 September 2001 04:00 To: yahoo; [EMAIL PROTECTED] Subject: RE: active perl on IIS Joel, I could be wrong but based on the way Lynn describes the problem, it does not sound like she has a problem with Perl being installed as the PerlScript examples do work as she stated. Also, she should not have to create a cgi-bin. IIS has a pre-created cgi-bin typically. While I am a fan of OReilly, I am also not sure that Win32 Perl book from OReilly will help Lynn so much because it's about Perl first and foremost, CGI secondarily (not that much coverage), and I don't think it goes into server configs but I could be wrong. Anyway, I think what Lynn is describing sounds more like a file extension problem. ActiveState Perl does set up Perl for IIS if I remember correctly but it does it based on FILE EXTENSION. So an important factor here is that Lynn should figure out if her file extensions would run if she clicked on the script in Explorer. I would be interested to know what file extension she is using for her scripts. If her colleagues are on UNIX and writing web apps, it's highly likely that they might use .cgi as an extension? But ActiveState never sets up .cgi. It will set up .pl for Perl for example. I have a more detailed article on this topic located here: http://webcompare.internet.com/isapiperl/index.html With a page specific to providing hints for installing ActiveState Perl for IIS here. http://webcompare.internet.com/isapiperl/isapiperl_3.html Good Luck, Gunther At 08:23 PM 8/29/2001 +0100, yahoo wrote: Lynn, I've installed ActiveStates Perl a couple of times on Win 2K NT and each time, as part of the install, it allowed/prompted for the configuration of the ISAPI part which basically meant you can run perl as an active x scripting engine. SCRIPT LANGUAGE=perlscript runs fine then. I seem to remember that CGI still works fine and they had some sort of speedy up extra module to make it go faster - kinda like a mod_perl for IIS I suppose - anyway
Re: active perl on IIS
That did it - thanks :) I am slowly but surely getting this changed over. I changed FORM ACTION=c:\inetpub\scripts\sl3.pl to FORM ACTION=http://198.162.0.1/scripts/sl3.pl; (Obviously if I decided to make this public I would need a different IP or hopefully a DNS name.) I can't believe this is taking me so long, when the script WORKS on a different OS and web server, but hopefully once I have gone through this once I'll be able to do this again in the future (or just develop on the same platform, that would be nice!) -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: active perl on IIS
At 09:07 AM 9/3/2001 -0700, Lynn Glessner wrote: That did it - thanks :) I am slowly but surely getting this changed over. I changed FORM ACTION=c:\inetpub\scripts\sl3.pl to FORM ACTION=http://198.162.0.1/scripts/sl3.pl; (Obviously if I decided to make this public I would need a different IP or hopefully a DNS name.) I can't believe this is taking me so long, when the script WORKS on a different OS and web server, but hopefully once I have gone through this once I'll be able to do this again in the future (or just develop on the same platform, that would be nice!) As an aside, you should consider that your action does not even have to be an absolute URL. Even if the form is in the HTML tree instead of the CGI tree, you can at least get away with just ACTION=/scripts/myscript.cgi isntead of the whole HTTP://etc.. If the form was generated by another scripts in the scripts directory, then you can get away with ACTION=myscript.cgi. And finally, if the script that generated the form is the same that is being posted to, you can leave off ACTION= entirely because the default action is to submit the data to the same exact script. Later, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: active perl on IIS
At 08:36 AM 9/3/2001 -0700, Mark Bergeron wrote: Let me also add, unlike *nix, you may run scripts from virtualy any folder you see fit on Win (within wwwroot for the web of course). Everything is really governed by the permissions and etc... you set on the folder itself. In some cases it makes sense to name the cgi folder something less obvious like, wordfiles, oldapps or the like. Be creative. This way should the casual hacker break in you stand a chance of he/ she skipping the directory. At the very least, someone is sniffing your tranfers might not suspect your moving them into an executable dir. Just a thought. MB' I don't fully understand this advice. If the casual hacker has broken in, then it seems that they already have more or equal power than they would be able to gain through hacking a scripts directory. As for sniffing file transfers. I suppose that is a valid issue, although it seems to me that someone sniffing an FTP session would sooner be able to get your plaintext password and be able to search around themselves. Even if the directory in this case was renamed, the script itself is not. So something like formmail.pl would still be formmail.pl even if it is in an oddly named directory. I am not saying there is no case for it at all. But it doesn't seem that strong for the annoyance of dealing with an obfuscation in your own setup. I think a human reading the directories would be able to figure out where things are. However, I also think that script kiddies are certainly something to watch out for if you are afraid you might miss a Microsoft security patch one day. One thing to consider then is that renaming the scripts directory may prevent an automated hacking script from putting something in the defeault c:\inetpub\scripts directory. So perhaps if this directory were renamed to something that is not obfuscated to make it hard to manage, but still different (eg maybe call it scriptstuff) then the automated scriptkiddle script will be thwarted. This is similar in concept to the idea of renaming root (which seemed to be advocated at SANS even several years back, don't know if it still is) just to prevent some scripted attacks from being able to log on as root. But they didn't precisely advocate renaming root to something that is obfuscated -- just renamed enough to fool the scripts of that day. Anyway, I'd like to hear more evidence of how strong renaming the scripts directory really is against attacks as I could be wrong in my assumptions. Thanks, Gunther -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: active perl on IIS
Hi Gunther, I think Lynn said she was looking for a book which covered IIS PerlScript - the OReilly win32 book is good for that (going hand-in-hand with ActiveStates latest documentation of course!). I don't think IIS normally pre-creates a cgi-bin for you - none of my installations have one (here is an excerpt from the IIS 5 documentation) extract To install and configure CGI applications: Set up a directory for your CGI programs. For extra security, you should separate your CGI programs from your content files. You do not need to name the directory Cgi-bin, although you can do so if you want. See Creating Virtual Directories. /extract As I said in my original email, you need to mark the directory as allowing scripting for executables inorder to get the .pl file to run. I agree with what you say about the file extension; I did mention the .pl extension in my original response. Lynn, any updates on this problem? regards Joel -Original Message- From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] Sent: 02 September 2001 04:00 To: yahoo; [EMAIL PROTECTED] Subject: RE: active perl on IIS Joel, I could be wrong but based on the way Lynn describes the problem, it does not sound like she has a problem with Perl being installed as the PerlScript examples do work as she stated. Also, she should not have to create a cgi-bin. IIS has a pre-created cgi-bin typically. While I am a fan of OReilly, I am also not sure that Win32 Perl book from OReilly will help Lynn so much because it's about Perl first and foremost, CGI secondarily (not that much coverage), and I don't think it goes into server configs but I could be wrong. Anyway, I think what Lynn is describing sounds more like a file extension problem. ActiveState Perl does set up Perl for IIS if I remember correctly but it does it based on FILE EXTENSION. So an important factor here is that Lynn should figure out if her file extensions would run if she clicked on the script in Explorer. I would be interested to know what file extension she is using for her scripts. If her colleagues are on UNIX and writing web apps, it's highly likely that they might use .cgi as an extension? But ActiveState never sets up .cgi. It will set up .pl for Perl for example. I have a more detailed article on this topic located here: http://webcompare.internet.com/isapiperl/index.html With a page specific to providing hints for installing ActiveState Perl for IIS here. http://webcompare.internet.com/isapiperl/isapiperl_3.html Good Luck, Gunther At 08:23 PM 8/29/2001 +0100, yahoo wrote: Lynn, I've installed ActiveStates Perl a couple of times on Win 2K NT and each time, as part of the install, it allowed/prompted for the configuration of the ISAPI part which basically meant you can run perl as an active x scripting engine. SCRIPT LANGUAGE=perlscript runs fine then. I seem to remember that CGI still works fine and they had some sort of speedy up extra module to make it go faster - kinda like a mod_perl for IIS I suppose - anyway, that is an aside. Ok, back to the point. Oreilly do a WIN32 Perl book - I've found it very good. http://www.amazon.com/exec/obidos/ASIN/1565923243/qid=999111590/sr=8-1/ref= a ps_sr_b_1_1/102-3850428-7506526 Have you got any test perl scripts running on your IIS box? I THINK you need to: 1) create a folder to house the cgi-bin 2) mark that folder as executable 3) put your perl (.pl) program in that. Don't think you need the shebang in win32. Can you try a simple hello world cgi program? You can always convert to an ASP PerlScript? You know, the form submits to itself and the serverside code does whatever and the send HTML back Can you post your perl code, html, where you put them in respect to eachother on the webserver, execute permissions of the folders etc. regards joel -Original Message- From: Lynn Glessner [mailto:[EMAIL PROTECTED]] Sent: 29 August 2001 19:38 To: [EMAIL PROTECTED] Subject: active perl on IIS Can anyone point me to a site or book with detailed information about configuring my W2K server IIS for perl and cgi? I have a form which I designed at work on Linux and Apache, and it works fine in that environment. I want to run it on my home W2K machine, but am baffled. My coworkers are no help because they all work on *nix machines. I installed activeperl and followed the configuration directions at the activeperl site but after clicking submit on my form I get the page cannot be displayed. The active perl example pages work correctly, but they have the perl script imbedded in the html page, unlike what I want to run which is a separate html file and perl script. I'm not expecting anyone in this group to walk me through it, unless you want to :), but can you point me to a helpful source? I did change the path in the form action tag, but there is probably something else simple I am forgetting in this port from unix to windows. On apache, I check error_log, is there an equivalent log
Re: active perl on IIS
I haven't had a chance to work on it recently, but I think it will turn out to be the .cgi extension (I'll have to go back and see who suggested that). I have my scripts in a directory which was created automatically called scripts a subdirecctory of c:\inetpub - IIS has it configured for executables. However, all my perl scripts in this directory have the extension .cgi. Double-clicking one of the example files installed by ActivePerl (those files have a .pl extension) executes fine, but my .cgi files have a generic icon - can't believe I didn't think to check that. I have the O'Reilly CGI book, with the rat/mouse on the cover, it is very helpful for CGI and Perl. I have the working version at work, it's just the implementation at home on IIS that I'm struggling with after doing my development at work. :( Thanks very much for the suggestions, I hope to be able to tackle this tonight (after my 2 year old goes to bed - she doesn't have much patience for programming yet!). From: yahoo [EMAIL PROTECTED] Date: Sun, 2 Sep 2001 18:28:47 +0100 To: [EMAIL PROTECTED] Subject: RE: active perl on IIS Hi Gunther, I think Lynn said she was looking for a book which covered IIS PerlScript - the OReilly win32 book is good for that (going hand-in-hand with ActiveStates latest documentation of course!). I don't think IIS normally pre-creates a cgi-bin for you - none of my installations have one (here is an excerpt from the IIS 5 documentation) extract To install and configure CGI applications: Set up a directory for your CGI programs. For extra security, you should separate your CGI programs from your content files. You do not need to name the directory Cgi-bin, although you can do so if you want. See Creating Virtual Directories. /extract As I said in my original email, you need to mark the directory as allowing scripting for executables inorder to get the .pl file to run. I agree with what you say about the file extension; I did mention the .pl extension in my original response. Lynn, any updates on this problem? regards Joel -Original Message- From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] Sent: 02 September 2001 04:00 To: yahoo; [EMAIL PROTECTED] Subject: RE: active perl on IIS Joel, I could be wrong but based on the way Lynn describes the problem, it does not sound like she has a problem with Perl being installed as the PerlScript examples do work as she stated. Also, she should not have to create a cgi-bin. IIS has a pre-created cgi-bin typically. While I am a fan of OReilly, I am also not sure that Win32 Perl book from OReilly will help Lynn so much because it's about Perl first and foremost, CGI secondarily (not that much coverage), and I don't think it goes into server configs but I could be wrong. Anyway, I think what Lynn is describing sounds more like a file extension problem. ActiveState Perl does set up Perl for IIS if I remember correctly but it does it based on FILE EXTENSION. So an important factor here is that Lynn should figure out if her file extensions would run if she clicked on the script in Explorer. I would be interested to know what file extension she is using for her scripts. If her colleagues are on UNIX and writing web apps, it's highly likely that they might use .cgi as an extension? But ActiveState never sets up .cgi. It will set up .pl for Perl for example. I have a more detailed article on this topic located here: http://webcompare.internet.com/isapiperl/index.html With a page specific to providing hints for installing ActiveState Perl for IIS here. http://webcompare.internet.com/isapiperl/isapiperl_3.html Good Luck, Gunther At 08:23 PM 8/29/2001 +0100, yahoo wrote: Lynn, I've installed ActiveStates Perl a couple of times on Win 2K NT and each time, as part of the install, it allowed/prompted for the configuration of the ISAPI part which basically meant you can run perl as an active x scripting engine. SCRIPT LANGUAGE=perlscript runs fine then. I seem to remember that CGI still works fine and they had some sort of speedy up extra module to make it go faster - kinda like a mod_perl for IIS I suppose - anyway, that is an aside. Ok, back to the point. Oreilly do a WIN32 Perl book - I've found it very good. http://www.amazon.com/exec/obidos/ASIN/1565923243/qid=999111590/sr=8-1/ref= a ps_sr_b_1_1/102-3850428-7506526 Have you got any test perl scripts running on your IIS box? I THINK you need to: 1) create a folder to house the cgi-bin 2) mark that folder as executable 3) put your perl (.pl) program in that. Don't think you need the shebang in win32. Can you try a simple hello world cgi program? You can always convert to an ASP PerlScript? You know, the form submits to itself and the serverside code does whatever and the send HTML back Can you post your perl code, html, where you put them in respect to eachother on the webserver, execute
Re: active perl on IIS
At 02:59 PM 9/2/2001 -0700, Lynn Glessner wrote: I haven't had a chance to work on it recently, but I think it will turn out to be the .cgi extension (I'll have to go back and see who suggested that). I have my scripts in a directory which was created automatically called scripts a subdirecctory of c:\inetpub - IIS has it configured for executables. However, all my perl scripts in this directory have the Yeah, Joel was correct in his previous mail. There is no cgi-bin directory created in IIS. My poor memory was really referring to this directory, which should have worked. extension .cgi. Double-clicking one of the example files installed by ActivePerl (those files have a .pl extension) executes fine, but my .cgi files have a generic icon - can't believe I didn't think to check that. Yes, this would have been a clue, but don't feel bad. This is deceptive because IIS actually pays little attention to the file manager associations. So .cgi could have been associated in IIS but the Windows Explorer still gives no icon if they were set up differently. I am not sure about Microsoft's motivation of separating Explorer from IIS file ending associations. It possible this was done for security reasons so that not all files become executables in IIS unless configured for IIS. I have the O'Reilly CGI book, with the rat/mouse on the cover, it is very helpful for CGI and Perl. I have the working version at work, it's just the implementation at home on IIS that I'm struggling with after doing my development at work. :( Well if this is just a home machine, I think someone else had also suggested using Win32/Apache. This might also be easier unless you are familiar with using IIS for everything else you are experimenting with. If you do get the simple .cgi works in the scripts directory, then also note that if you dump your .cgi inside of c:\inetpub\scripts (if thats your directory) then the program will work when you use relative paths. But your relative paths won't work if you put it in a subdirectory of c:\inetpub\scripts because IIS always does the equivalent of chdir back to the root of the c:\inetpub\scripts directory itself. So you need to make all paths relative to c:\inetpub\scripts rather than, say, c:\inetpub\scripts\myScriptArea if you put myscript.cgi in there. Although you haven't run into this problem yet, I mention it in advance because it's the next most common complaint I see next to the file association one with regards to how to make an application work. Thanks very much for the suggestions, I hope to be able to tackle this tonight (after my 2 year old goes to bed - she doesn't have much patience for programming yet!). :) -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: active perl on IIS
Wo-hoo! My script is now working. Here is what I had to do: 1. The same thing that I have spent several days of my life on when you add up all the times I have done this to myself - the mysterious way that text files on not quite the same on a different OS. (Last time was the other way around - I wrote in on a mac at home and transferred it to work.) My trusty Ultra-Edit to the rescue! After I had installed it on this home computer, it immediately suggested that I convert the file I had just opened. 2. I changed my file extensions from .cgi to .pl 3. I had to change a few places in my code that I used a '/' in a file path instead of a '\' since I am uploading a file to the web server, and of course I was sure that I was going to remember that I would need to use postie instead of mailx but didn't ;) Thanks everyone for your help. This is just a simple program for creating ebay auction descriptions after FTPing the selected files to an ISP, but if it can help anyone out then let me know and I would be happy to share. Lynn -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: active perl on IIS
I spoke too soon. I thought this was just a minor tweak, which it probably is ;), but the tweak is not what I thought it was going to be ... When I click the button to submit the form, instead of running the perl script I get the File Download dialog. If I choose the run the file from this location radio button - what I thought was going to be the solution - all my STDOUT is in a DOS window, and my CGI param calls don't get anything that I filled in on the form. At the end of my script I have some CGI to display in the browser that it is done, but instead those lines show up as in the DOS window. Like I had double-clicked the pl file. If I type in the path to the sl3.pl file in my browser, it executes correctly and displays those I'm done lines in my browser. I stared at the activeperl directions for configuring IIS and don't see what I'm doing wrong. .pl is associated at the top level down with the full path including perl.exe followed by %s %s. And it works if I go straight there. These html and pl files work fine with IE browser on NT and linux apache web server at work, and I'm still using IE browser, so I know the problem is my IIS configuration. Yes, in my free time I will look into running apache instead of IIS. Why do I get a file download dialog box? My html file is like this: FORM ACTION=c:\inetpub\scripts\sl3.pl METHOD=POST ENCTYPE=multipart/form-data [snipped] INPUT TYPE=SUBMIT NAME=Button VALUE=SendP /FORM -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: active perl on IIS
Lynn, I've installed ActiveStates Perl a couple of times on Win 2K NT and each time, as part of the install, it allowed/prompted for the configuration of the ISAPI part which basically meant you can run perl as an active x scripting engine. SCRIPT LANGUAGE=perlscript runs fine then. I seem to remember that CGI still works fine and they had some sort of speedy up extra module to make it go faster - kinda like a mod_perl for IIS I suppose - anyway, that is an aside. Ok, back to the point. Oreilly do a WIN32 Perl book - I've found it very good. http://www.amazon.com/exec/obidos/ASIN/1565923243/qid=999111590/sr=8-1/ref=a ps_sr_b_1_1/102-3850428-7506526 Have you got any test perl scripts running on your IIS box? I THINK you need to: 1) create a folder to house the cgi-bin 2) mark that folder as executable 3) put your perl (.pl) program in that. Don't think you need the shebang in win32. Can you try a simple hello world cgi program? You can always convert to an ASP PerlScript? You know, the form submits to itself and the serverside code does whatever and the send HTML back Can you post your perl code, html, where you put them in respect to eachother on the webserver, execute permissions of the folders etc. regards joel -Original Message- From: Lynn Glessner [mailto:[EMAIL PROTECTED]] Sent: 29 August 2001 19:38 To: [EMAIL PROTECTED] Subject: active perl on IIS Can anyone point me to a site or book with detailed information about configuring my W2K server IIS for perl and cgi? I have a form which I designed at work on Linux and Apache, and it works fine in that environment. I want to run it on my home W2K machine, but am baffled. My coworkers are no help because they all work on *nix machines. I installed activeperl and followed the configuration directions at the activeperl site but after clicking submit on my form I get the page cannot be displayed. The active perl example pages work correctly, but they have the perl script imbedded in the html page, unlike what I want to run which is a separate html file and perl script. I'm not expecting anyone in this group to walk me through it, unless you want to :), but can you point me to a helpful source? I did change the path in the form action tag, but there is probably something else simple I am forgetting in this port from unix to windows. On apache, I check error_log, is there an equivalent log file for W2K IIS? Thanks, Lynn -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: active perl on IIS
This may help: http://www.wiley.com/legacy/compbooks/stein/source.html of course there are so many more. Mark Bergeron' -Original Message- From: Lynn Glessner[EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed Aug 29 11:37:49 PDT 2001 Subject: active perl on IIS Can anyone point me to a site or book with detailed information about configuring my W2K server IIS for perl and cgi? I have a form which I designed at work on Linux and Apache, and it works fine in that environment. I want to run it on my home W2K machine, but am baffled. My coworkers are no help because they all work on *nix machines. I installed activeperl and followed the configuration directions at the activeperl site but after clicking submit on my form I get the page cannot be displayed. The active perl example pages work correctly, but they have the perl script imbedded in the html page, unlike what I want to run which is a separate html file and perl script. I'm not expecting anyone in this group to walk me through it, unless you want to :), but can you point me to a helpful source? I did change the path in the form action tag, but there is probably something else simple I am forgetting in this port from unix to windows. On apache, I check error_log, is there an equivalent log file for W2K IIS? Thanks, Lynn -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] /~_. _ | _ _ _ _ \_/|(_||| | |(_)| | _| ___ GO.com Mail Get Your Free, Private E-mail at http://mail.go.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
