[23500] in Perl-Users-Digest
Perl-Users Digest, Issue: 5710 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Oct 25 06:10:35 2003
Date: Sat, 25 Oct 2003 03:10:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 25 Oct 2003 Volume: 10 Number: 5710
Today's topics:
Re: Perl and IIS - script runs but 'The page cannot be (stew dean)
Re: Perl and IIS - script runs but 'The page cannot be (stew dean)
Re: Perl and IIS - script runs but 'The page cannot be (stew dean)
Re: Perl and IIS - script runs but 'The page cannot be (Jay Tilton)
Re: Perl and IIS - script runs but 'The page cannot be (stew dean)
Re: Perl and IIS - script runs but 'The page cannot be (Tad McClellan)
Re: Perl and IIS - script runs but 'The page cannot be <jurgenex@hotmail.com>
Re: Perl and IIS - script runs but 'The page cannot be <kkeller-usenet@wombat.san-francisco.ca.us>
Re: Perl and IIS - script runs but 'The page cannot be (stew dean)
Re: Perl and IIS - script runs but 'The page cannot be (stew dean)
Re: Perl and IIS - script runs but 'The page cannot be <tassilo.parseval@rwth-aachen.de>
Re: Perl and IIS - script runs but 'The page cannot be (stew dean)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 24 Oct 2003 16:30:06 -0700
From: stewart@webslave.dircon.co.uk (stew dean)
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <2b68957a.0310241530.187e92be@posting.google.com>
Helgi Briem <HelgiBriem_1@hotmail.com> wrote in message news:<fk4ipv433atv5obpfanj1alnlb6b7rmtd5@4ax.com>...
> On 23 Oct 2003 02:22:26 -0700, stewart@webslave.dircon.co.uk (stew
> dean) wrote:
>
> >> > I've never run a perl script at the command line.
> >>
> >> Why not?
> >
> >Because I've never had to. Why would I want to?
>
> I've been hovering over whether to killfile you for
> cluelessness or not. You have removed all doubt.
Oi idiot - why didnt you answer the question?
You don't need to use the command line to write perl scripts. If all
the errors I needed appeared in the browser I would never ever have to
go near the command line to write perl.
There are some real arrogant arseholes around here.
Stew Dean
------------------------------
Date: 24 Oct 2003 17:14:42 -0700
From: stewart@webslave.dircon.co.uk (stew dean)
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <2b68957a.0310241614.336307f8@posting.google.com>
Helgi Briem <HelgiBriem_1@hotmail.com> wrote in message news:<rc4ipvcfiq321n59bn804h6merb8ha62qh@4ax.com>...
> On Thu, 23 Oct 2003 16:24:19 GMT, "Jürgen Exner"
> <jurgenex@hotmail.com> wrote:
>
> >Well, once you've installed ActivePerl you may want to check
> >"perldoc -q 500". It might be an eye opener.
>
> Finally somebody put the poor sod out of his misery
> and threw him a titbit that will actually help.
It wasnt useful. It took me to a document that was for unix users.
You ever read 'The Hitchhikers Guide' - well this is the you version
of the plans for the new bypass. perldoc -q 500 is the equivalent of
'beware of the leopard'.
> I think this "off-topic newbie baiting" sometimes
> gets a little out of hand.
>
> At least start with "perldoc -q 500" when one of these
> clueless people arrives here each week. I mean, he
> shouldn't have to read 30 posts before he gets told
> to RTFM.
The manual ain't no good. Why do you think I'm asking!!
Stew Dean
------------------------------
Date: 24 Oct 2003 17:51:33 -0700
From: stewart@webslave.dircon.co.uk (stew dean)
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <2b68957a.0310241651.60f60889@posting.google.com>
James Willmore <jwillmore@remove.adelphia.net> wrote in message news:<20031023113558.193628d9.jwillmore@remove.adelphia.net>...
> On 23 Oct 2003 02:22:26 -0700
> stewart@webslave.dircon.co.uk (stew dean) wrote:
> <snip - getting long>
> > > > > > > On 21 Oct 2003 03:53:24 -0700
> > > > > > > stewart@webslave.dircon.co.uk (stew dean) wrote:
> > > > > <snip>
> > > > >
> > > > > What happened when you ran the script at the command line?
> > > >
> > > > I've never run a perl script at the command line.
> > >
> > > Why not?
> >
> > Because I've never had to. Why would I want to?
>
> [Sigh]
>
> Because it _may_ give you a clue as to why you're not getting what you
> want from the script. It's not a perfect solution, but it is a
> healthy place to start. After all, the CGI can be considered a
> server's STDIN, right?
And lo - it did!
But to do this I had to turn all my reletive paths to absolute and
hard code in the variables passed to the script. All very messy but it
turns out you are right - it gives out error messages as if it's
writing to an error log. As someone pointed out there is not error log
otherwise.
The errors pointed out problems with the perls script. The perl script
was to blame. It was over 20 pages long and wouldnt have made any
sense without the XML file - the reason I didnt post any code.
>
> <snip>
>
> > > Maybe there _is_
> > > something wrong with the script? A typo, maybe? Running the
> > > script_at the command line_ will produce messages that _may_ not
> > > be seen as errors, but as warnings that the web server is just
> > > dismissing.
> >
> > All errors that are generated by the script are displayed in the
> > output. It uses strict so all errors are picked up including
> > variables not declared. If it finds more than one it stops running
> > and tells me.
> >
> > Now there may be errors produced of a different kind but then this
> > would be new to me and I'm trying to find out what kind of errors
> > they may be. The code it's self is fine with no syntax errors.
> >
> > If I run it from the command line it can't find the input file as
> > the file is relative to the web server. This is all about reading
> > and writing files afterall.
>
> Yes, I understand. Using the '-debug' switch for the CGI module will
> allow you to run the script, from the command line, and allow you to
> see what the script's output (the good, bad, and ugly) is.
You'll have to explain this. What is the CGI module? I've seen
reference to use CGI.pm but havnt had a reason to use it so far.
> Using this
> switch will allow you to send parameters to the script as if the
> script is getting them through the CGI (aka the web server's STDIN).
Okay but what I really want to do is not have to use the command line
and instead get all the errors in the browser.
> So, if you are passing a file name as a param to the script, you can
> type that in while running the script on the command line. I know all
> this because I've done it :-)
Cool - but I first had to create a new version with absolute paths
before it run. Is there a way to avoid having to do this?
>
> >
> > <snip>
> >
> > > > > For the time being - and to give a hint - try using CGI::Carp
> > > > > (just not in a production environment).
> > > >
> > > > Well that's enigmatic. I suspect that it's also not the answer I
> > > > seek but I will check it out.
> > >
> > > Like I mentioned before, maybe the code _is_ broke somewhere.
> > > CGI::Carp can report the errors to the browser (since you seem to
> > > not want to run the script at the command line). If something is
> > > broke, the error will appear.
> >
> > If something is broke it gives me the error by passing me the
> > headers. Will Carp give me any errors that I don't already receive
> > (given that I'm not adding debug messages into the script)?
> >
>
> Yes. Read the documentation for CGI::Carp for other settings for the
> module. It's rather robust and very useful for debugging CGI scripts.
Again - very cool. We're getting somewhere. Looks like I'm hunting
down where STDERR goes.
But I'm still confused. One of the errors I was getting was because of
UT8F characters - it was complainin about wide characters. How do
errors like this get displayed in the browser? The carp FAQ doesnt
appear to cover this.
> The one caveat is _don't_ use it in a production environment. The
> messages that can be created and used in development can be considered
> a security risk in a production environment.
Sorry - what do you mean by 'production environment' - you mean live
rather than hidden for developement right?
> I've tried to make the effort to lend a hand to you in this task. I
> know it may not seem like it. Consider the message, not the way the
> message is being delivered and it, I hope, will appear that I have
> made the effort.
I truely appreciate your effort. I can take a bit if chest beating if
get some useful answers. Some folks here think they are giving the
correct answers but have gotten it as wrong as I have.
> However, unless you can offer new information about
> what's going on, I suggest you post to a CGI authoring group. There,
> the group can offer assistance in configuration of IIS and all the
> issues associated with IIS. I have 'zero' experience with IIS, but
> lots with Perl and using it through the CGI. If this issue is IIS
> related,
> I can't offer anything more.
Well it turns out it's not IIS related but related to how I use perl
on windows. Some like to use command lines, for the reasons I've
stated it's easier to try and get the errors into the browser (or CGI
if you prefer).
As someone who only does perl when they need to and is used to using
usenet to find answers for other things I do find it unsettling that
you have to know a lot before you can post here - but that knowledge
has nothing to do with perl but where to find documents that don't
answer my question.
Like I said elsewhere - there's no point telling people to RTFM if
they don't know which manual or when they do read it its of zero help.
If you could help me avoid having to have two scripts and get the none
syntax related errors (like wide character warnings and the such)
displaying whe I call up the script via CGI this would be a great
help.
Cheers
stew dean
------------------------------
Date: Sat, 25 Oct 2003 01:04:37 GMT
From: tiltonj@erols.com (Jay Tilton)
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <3f99c0b7.50221376@news.erols.com>
stewart@webslave.dircon.co.uk (stew dean) wrote:
: Helgi Briem <HelgiBriem_1@hotmail.com> wrote in message news:<fk4ipv433atv5obpfanj1alnlb6b7rmtd5@4ax.com>...
: > On 23 Oct 2003 02:22:26 -0700, stewart@webslave.dircon.co.uk (stew
: > dean) wrote:
: >
: > >> > I've never run a perl script at the command line.
: > >>
: > >> Why not?
: > >
: > >Because I've never had to. Why would I want to?
: >
: > I've been hovering over whether to killfile you for
: > cluelessness or not. You have removed all doubt.
:
: Oi idiot - why didnt you answer the question?
Probably because you've demonstrated remarkable obstinacy in taking
advice. Talking to a wall gets old fast.
: You don't need to use the command line to write perl scripts. If all
: the errors I needed appeared in the browser I would never ever have to
: go near the command line to write perl.
Isn't the root of the problem that nothing at all is being displayed in
the browser?
: There are some real arrogant arseholes around here.
Problem diagnosis is a process, and so far you have refused to
participate in the process. You seem to want somebody to magically know
what's wrong and say "this is the problem, here is how to fix it."
The arseholes have been sharing solid advice on how to find where the
difficulty lies, often repeating what others have already said.
Here's a recap of those advices:
1. Look at the server's error log.
2. Post a short sample script that demonstrates the
problem.
3. Ask for help in a CGI-related or IIS-related
newsgroup.
4. Run the script from a command prompt so you can see
errors and warnings as they happen.
5. use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
6. see "perldoc -q 500"
There's no evidence you've tried any of those things. Your only
response to each arsehole has been "the script works."
Until you get past the assumption that there's nothing wrong with the
program and start trying some of the things people have suggested, there
is nothing left to do.
------------------------------
Date: 24 Oct 2003 18:07:25 -0700
From: stewart@webslave.dircon.co.uk (stew dean)
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <2b68957a.0310241707.3ad7fc65@posting.google.com>
ko <kuujinbo@hotmail.com> wrote in message news:<bn8nea$am6$1@pin3.tky.plala.or.jp>...
> stew dean wrote:
> >> jwillmore@myrealbox.com (James Willmore) wrote:
> >>What happened when you ran the script at the command line?
> >>
> >I've never run a perl script at the command line.
> >
> >>Why not?
> >
> > Because I've never had to. Why would I want to?
>
> [snip]
>
> > If I run it from the command line it can't find the input file as the
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> this is probably important and shouldn't be ignored, see below...
>
> > file is relative to the web server. This is all about reading and
> > writing files afterall.
>
> Wow, you have managed to ignore James Willmore's advice and (I think)
> answer your own question in one stroke :) When you read/write files you
> need to be specific(physical vs. relative path) - the fact that its a
> CGI script is irrelevant. And since this the problem *seems* to be
> related to reading and writing files, try the following:
>
> use strict;
I use this.
> use warnings;
This I'm looking into as it might answer my question....
> use CGI;
Don't use this as I write all my HTML by hand instead - just a person
choice thing. If it does anything more than write HTML please correct
me.
<rest of excellent examples snipped>
First thanks for replying in great depth. You post indirectly lead to
me solving my problem.
To get my script to work in the command line I created a new version -
one with the variables passed to the script hard coded (although there
are ways of doing it via the command line I've been informed) and also
with absolute paths rather the relative ones the server doesnt mind.
It gave me a whole new set of errors before spitting out my HTML (all
present and correct). These errors that I didnt see via the browser
once fixed resulted in the end HTML being displayed when run via the
browser.
The mistakes in the perl where not syntax but warnings of wide
characters and errors where an array memeber was called up that wasnt
defined (like, in one example the eighth day in the week).
So thanks for taking the time as your post, although not dead on
target, did lead to me solving the problem. Now I'm looking for a way
to avoid using the command line again (except to install modules etc)
so I only need one script.
Juding from some responces I've got (some have been downright nasty)
this may be better in the cgi group but cheers anyway.
Stew Dean
------------------------------
Date: Fri, 24 Oct 2003 21:13:50 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <slrnbpjn2u.9nf.tadmc@magna.augustmail.com>
stew dean <stewart@webslave.dircon.co.uk> wrote:
> There are some real arrogant arseholes around here.
If you leave then there will be one less.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sat, 25 Oct 2003 06:18:24 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <QAomb.1419$%e3.256@nwrddc03.gnilink.net>
stew dean wrote:
> Now I'm looking for a way
> to avoid using the command line again (except to install modules etc)
> so I only need one script.
Oh well, of course you have any right to write your programs blindfolded
with one hand tied to your back.
But then at least neither cry for help if you can't see the bugs because of
your blindfold nor offend those people who are telling you how to untie your
hands.
jue
------------------------------
Date: Fri, 24 Oct 2003 23:12:45 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <t84dnb.jgm.ln@goaway.wombat.san-francisco.ca.us>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
On 2003-10-25, Tad McClellan <tadmc@augustmail.com> wrote:
> stew dean <stewart@webslave.dircon.co.uk> wrote:
>
>> There are some real arrogant arseholes around here.
>
> If you leave then there will be one less.
One fewer?
- --$arseholes;
Anyway, stew asked about CGI: the long answer is to perldoc CGI. The
short answer is that CGI helps immeasurably in parsing query strings and
POST parameters, and if you're not using it you're almost surely missing
something that'll bite you in the behind sooner or later.
stew also complained that people complained that he didn't post any Perl
code. The typical troubleshooting strategy in this situation is to
write minimal code that replicates the problem and post that. I don't
see where you ever thought about trying that, but it would likely help
in solving both your technical and social problems. :)
Finally, it seems like a lot of the original problem can be traced back
to crappy IIS docs. I'd suggest switching to a less crappy web server,
like apache.
- --keith
- --
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAj+aFFoACgkQhVcNCxZ5ID9oUgCdGfZmieVOEwBIeWaNO2yqeIJp
F2EAoJCVLJ24ws8W4rMClzOOy6LmkTQA
=i1qi
-----END PGP SIGNATURE-----
------------------------------
Date: 25 Oct 2003 00:45:01 -0700
From: stewart@webslave.dircon.co.uk (stew dean)
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <2b68957a.0310242345.d5f0ef8@posting.google.com>
tadmc@augustmail.com (Tad McClellan) wrote in message news:<slrnbpjn2u.9nf.tadmc@magna.augustmail.com>...
> stew dean <stewart@webslave.dircon.co.uk> wrote:
>
> > There are some real arrogant arseholes around here.
>
>
> If you leave then there will be one less.
Thanks for proving my point arsehole.
Stew Dean
------------------------------
Date: 25 Oct 2003 01:05:51 -0700
From: stewart@webslave.dircon.co.uk (stew dean)
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <2b68957a.0310250005.165a82e8@posting.google.com>
tiltonj@erols.com (Jay Tilton) wrote in message news:<3f99c0b7.50221376@news.erols.com>...
> stewart@webslave.dircon.co.uk (stew dean) wrote:
>
> : Helgi Briem <HelgiBriem_1@hotmail.com> wrote in message news:<fk4ipv433atv5obpfanj1alnlb6b7rmtd5@4ax.com>...
> : > On 23 Oct 2003 02:22:26 -0700, stewart@webslave.dircon.co.uk (stew
> : > dean) wrote:
> : >
> : > >> > I've never run a perl script at the command line.
> : > >>
> : > >> Why not?
> : > >
> : > >Because I've never had to. Why would I want to?
> : >
> : > I've been hovering over whether to killfile you for
> : > cluelessness or not. You have removed all doubt.
> :
> : Oi idiot - why didnt you answer the question?
>
> Probably because you've demonstrated remarkable obstinacy in taking
> advice. Talking to a wall gets old fast.
>
> : You don't need to use the command line to write perl scripts. If all
> : the errors I needed appeared in the browser I would never ever have to
> : go near the command line to write perl.
>
> Isn't the root of the problem that nothing at all is being displayed in
> the browser?
>
> : There are some real arrogant arseholes around here.
>
> Problem diagnosis is a process, and so far you have refused to
> participate in the process. You seem to want somebody to magically know
> what's wrong and say "this is the problem, here is how to fix it."
>
> The arseholes have been sharing solid advice on how to find where the
> difficulty lies, often repeating what others have already said.
> Here's a recap of those advices:
>
> 1. Look at the server's error log.
Not applicable.
> 2. Post a short sample script that demonstrates the
> problem.
Not applicable - no errors - no sample script.
> 3. Ask for help in a CGI-related or IIS-related
> newsgroup.
Only well into the debate. I'm suprised someone didnt pipe up 'read
the FAQ' then plonked me when I asked which FAQ.
> 4. Run the script from a command prompt so you can see
> errors and warnings as they happen.
This is the bit of advice I followed and it worked, only after I got
shit for asking why I should use the command line.
> 5. use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
No difference in output to normal.
> 6. see "perldoc -q 500"
This came up late in the discussion. It's essential RTFM. In this case
the manual is of no use. It did tell me I would have been better off
in a CGI newsgroup and you lot get a bit shirty around here - guess I
know that now. Some of you guys really need to chill out.
Think of it this way - if I never used the command line before (except
to install modules) then why would I know what perldoc means? I would
have used perl.org and like I did in this case and not have found the
answer as I get burried in unrelevent material.
> There's no evidence you've tried any of those things. Your only
> response to each arsehole has been "the script works."
Because the script outputs no errors in the browser. Using the command
line - as I've stated before, it gave me the errors. This allowed me
to fix the script. Now I want the errors that showed up in the command
line to display in the browser as at the moment I have to maintain two
scripts - one with relative links and one absolute. There is a
problem.
> Until you get past the assumption that there's nothing wrong with the
> program and start trying some of the things people have suggested, there
> is nothing left to do.
Because most of the things suggested have not helped. Yes the headers
are correct, no there are no syntax errors, yes the files are inputing
and outputting correctly.
The problem WAS with the script but if I'd posted code up you wouldnt
have seen it without me supplying the XML file. I don't think anyone
here wanted a 40 page message.
I was after finding out how to get to my errors. After someone had
told me I'll get a list of errors by using the command line this is
what I did. And it worked. Until someone mentioned that I couldnt
follow the advice.
Some have their own ways of working and often it is suggested to use x
or y solution because that is how they do it - not because it will
give me any more answers. Now I know that the command line gives me
errors not seen in the browser - and I want these errors to show up in
the browser.
Stew Dean
------------------------------
Date: 25 Oct 2003 09:54:25 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <bndh8h$ch6$1@nets3.rz.RWTH-Aachen.DE>
Also sprach stew dean:
> tiltonj@erols.com (Jay Tilton) wrote in message news:<3f99c0b7.50221376@news.erols.com>...
>> 6. see "perldoc -q 500"
>
> This came up late in the discussion. It's essential RTFM. In this case
> the manual is of no use. It did tell me I would have been better off
> in a CGI newsgroup and you lot get a bit shirty around here - guess I
> know that now. Some of you guys really need to chill out.
>
> Think of it this way - if I never used the command line before (except
> to install modules) then why would I know what perldoc means? I would
> have used perl.org and like I did in this case and not have found the
> answer as I get burried in unrelevent material.
The command line is not the only way to get to the documentation.
http://www.perldoc.com/ comes to mind, for instance. What you write
implies that you haven't yet read the posting guidelines of this group
(posted regularly by Tad whom you titled an 'arsehole').
Had you lurked a while here (or at least read a couple of posts to this
group of the past weeks), you would have figured all that out yourself.
It's in general not a good idea to enter a new surrounding without
checking the local conventions.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 25 Oct 2003 03:04:47 -0700
From: stewart@webslave.dircon.co.uk (stew dean)
Subject: Re: Perl and IIS - script runs but 'The page cannot be displayed'
Message-Id: <2b68957a.0310250204.a9eee5f@posting.google.com>
Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote in message news:<t84dnb.jgm.ln@goaway.wombat.san-francisco.ca.us>...
> -----BEGIN xxx SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2003-10-25, Tad McClellan <tadmc@augustmail.com> wrote:
> > stew dean <stewart@webslave.dircon.co.uk> wrote:
> >
> >> There are some real arrogant arseholes around here.
> >
> > If you leave then there will be one less.
>
> One fewer?
>
> - --$arseholes;
>
> Anyway, stew asked about CGI: the long answer is to perldoc CGI. The
> short answer is that CGI helps immeasurably in parsing query strings and
> POST parameters, and if you're not using it you're almost surely missing
> something that'll bite you in the behind sooner or later.
Looked this up. There's some useful stuff here although it might make
my work more complicated if I used all it's features. The form related
handling is about the only bit I might use. Thanks for the suggestion.
> stew also complained that people complained that he didn't post any Perl
> code. The typical troubleshooting strategy in this situation is to
> write minimal code that replicates the problem and post that. I don't
> see where you ever thought about trying that, but it would likely help
> in solving both your technical and social problems. :)
The code woudl have clouded the issue I feel - although it might have
helped to post my headers I use which, with the carp added, are...
#!/usr/bin/perl
use XML::Simple;
use strict;
use warnings;
use Time::Local;
use CGI::Carp qw(fatalsToBrowser);
I then have all the 'my' statements and a lot of code that does stuff
like...
open(SOURCEXML, "< $thexml") or die "can't open $thexml: $!";
open(TEMPORYXML, "> $tempxml") or die "can't open $tempxml:
$!";
# fix xml simple error with pound
while (<SOURCEXML>) {
s/\£\;/UKP/g;
(print TEMPORYXML $_) or die "can't write to $thexml: $!";
}
close(SOURCEXML) or die "can't close $thexml: $!";
close(TEMPORYXML) or die "can't close $tempxml: $!";
> Finally, it seems like a lot of the original problem can be traced back
> to crappy IIS docs. I'd suggest switching to a less crappy web server,
> like apache.
Both the IIS and perl docs where crappy. This is what happens if you
have a weird set up I inherited. My problem is I'm using stuff I used
to use when I was working on unix boxes on a windows box - it's a
clash of cultures but I'm stuck with it. The previous 'tech' was
absolutely clueless (took him a year to set up a basic database
application that didnt really work).
I would love to have linux and apache etc but I'm stuck with a windows
box and I'm not in a position where I can have the down time to switch
from IIS to apache. This is a 24/7 live site and I can't reconfigure
it without some very very good reason. I also can't afford the
learning time to work out how to get everything I've set up for IIS to
work with apache. But I understand why you make the suggestion.
Stew Dean
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 5710
***************************************
