A v B = ?

A different question (using the previous "well split" code, but notregarding split() ).

Given the following routines A and B, why does A work and B does not?

The only difference between the two routines is where the "ROW" blockis placed. In example A the ROW variables appear within the "readdata loop", but in example B they are only printed within the "readdata loop" -- why does that make a difference?

RobinmcfRobin: 'plogies I forgot you're doing GGI on Linux, in which case- add #!/usr/local/bin/perl -w use strict; use diagnostics-verbose; use CGI::Carp qw(fatalsToBrowser); to the top of your script,most internal perl generated errors will be sent to your browser but in the event you just get a generic '500 internal server error' change to your shell account and type [shell prompt]$ tail /path/to/server/error_logs which will print out the last X lines of the error log, letting you see what caused

I'm not sure if I understand things. You see, I can do that, butnothing will happen -- other than a server error. I don't run thiscode on my Mac -- I only write it on my Mac and run it on the server-- am I making sense?

to the top of your script,most internal perl generated errors will besent to your browser but in the event you just get a generic '500 internalserver error' change to your shell account and type

[shell prompt]$ tail /path/to/server/error_logs

which will print out the last X lines of the error log, letting you seewhat caused the error. The alternative is to take the troubled section andrun it in MacPerl, which is what I prefer doing when I'm testing somethingwhich isn't system dependant.Either way you should get into the habit of putting these headers, theywill tell you what's going wrong immediately.

Robinmcfwhich means there's something fundamentally wrong with the code - it won't compile This is telling you the same thing - there's something fundamentally wrong with the script so it can't compile Not having access to the error logs is unusual: if you can FTP into your account try using a telnet client to log on with the same connection data you use for FTP. If you _really_ can't access the server logs, you can re-direct STDERROR to STDOUT <&STDOUT"); I recommend to use this only for debugging,

open (STDERR, ">&STDOUT");I recommend to use this only for debugging, don't leave this in your publicscript. Not only are other people likely to get confused when beingconfronted with Perl's error messages or warnings but also you won't beable to track down those errors in the server's errorlog - that can reallybe fatal, imagine your perfectly fine script breaks one day due to achanged environment or changed permissions of some files and you don'tnotice it until weeks later after finally some visitor complained.end>>

Robinmcfon my mac under MacPerl As to issue of the script running on your mac, but not on the server as a CGI : this may not be due to the '-w' switch a such, but if you insist on not using it you'll find people will be reluctant to help you, (see below) A generic 500 error check list is: * is the path to perl correct (in the she-bang line) * does the script have the correct permissions to run * if you transferred it from another machine using a different OS, are you sure the line endings are correct?

tedd@sperling.com wrote:So, where is it that you're running the code and receiving those errors?

on my mac under MacPerl

As to issue of the script running on your mac, but not on the server as a CGI :this may not be due to the '-w' switch a such, but if you insist on notusing it you'll find people will be reluctant to help you, (see below)

A generic 500 error check list is:

* is the path to perl correct (in the she-bang line)* does the script have the correct permissions to run* if you transferred it from another machine using a different OS, are yousure the line endings are correct?

If these three steps don't solve your problem you need the error logs

Then the next thing to do is to check out the DOCs which come with all Perldistros, because in all of the Perl NG and mailing lists, CGI relatedpostings are notorious for being trivial and easily solved (by using '-w','use strict;' and checking the 3 things above). In keeping with this, thisis the same reason why MacPerl has a separate CGI list, (it didn't always).In the perl community in general the minute you post anything in which it'sapparent that you haven't read the docs and you haven't followed any of thebasic guidelines set out in the FAQs because you haven't read them, peopleeither don't reply to your posting or get downright nasty/abusive, becausethey've seen the same kinds of posting over, and over again, and considerthem only marginally better than spam (but only beause the posters aren'ttrying to squeeze money out of them) :~)

(from POD FAQ 9: )My CGI script runs from the command line but not the browser. (500 ServerError)

If you can demonstrate that you've read the following FAQs and that yourproblem isn't something simple that can be easily answered, you'll probablyreceive a courteous and useful reply to your question if you post it oncomp.infosystems.www.authoring.cgi (if it's something to do with HTTP,HTML, orthe CGI protocols). Questions that appear to be Perl questions but arereally CGI ones that are posted to comp.lang.perl.misc may not be so wellreceived.

TeddRobin: I'm not refusing to use the -w option nor have I said that I refuse to do so. Apparently, I have not been clear as to the problems I experienced and my inquiries regarding as to its use -- for that I apologize. As for reading FAQ's -- I read everything I can and all referenced me. The reference you provided is one that I was not aware, but shall use. I do find that there is a vast amount of information on Perl and as such, I am simply overwhelmed by its shear volume. I am probably like

?tedd@sperling.com wrote:So, where is it that you're running the code and receiving those errors?

on my mac under MacPerl

As to issue of the script running on your mac, but not on the serveras a CGI :this may not be due to the '-w' switch a such, but if you insist on notusing it you'll find people will be reluctant to help you, (see below)

Robin:

I'm not refusing to use the -w option nor have I said that I refuseto do so. Apparently, I have not been clear as to the problems Iexperienced and my inquiries regarding as to its use -- for that Iapologize.

As for reading FAQ's -- I read everything I can and all referencedme. The reference you provided is one that I was not aware, but shalluse. I do find that there is a vast amount of information on Perl andas such, I am simply overwhelmed by its shear volume. I am probablylike many others in that not everything I read is immediatelycomprehended - sometimes the elusive nature of the syntax evades myimmediate acknowledgement. Furthermore, I have found errors in somereference material which has lead me astray and it takes a while tosort things out.

Granted, I have purpose and have probably leaped past some of theintroductory aspects of the language in an attempt to fulfill mygoal. But from my perspective, it's hard to sort out what is actuallyintroductory and what is not -- considering the shear volume of thereference material. So, I am sure there remains a significant amountof introductory material for me to consider -- that in itself is aproblem. But, I have not intentionally taken advantage of other'stime beyond what I would consider to be unreasonable. I am simplytrying to understand and thought that this list was a forum to assistme. To me, the questions I post are not trivial -- but apparently, Iam alone in that view. It's almost humorous in that some things areso obvious to some, but not others.

In any event, I consider myself forewarned. You have been veryhelpful, gracious and polite in pointing out my failing to read therelevant references. In the future I shall make very effort toresearch all sources of information available to me before postinganother question to this list.