Ignorance Isnt Always Bliss

Baffled has asked for the wisdom of the Perl Monks concerning the following question:

You can end this string, the problem has been determined a missing / at the end of a url in the lib pointing to the dir that the array was trying to read. Following advice gathered from this forum I added use CGI::Carp qw(fatalsToBrowser); to my main script page, and lo and behold, this is what I found....

Modification of non-creatable array value attempted, subscript -1 at /var/www/vhosts/mysite.com/cgi-bin/gallery.cgi line 40, <THEFILE> line 48.

Now pardon my ignorance but Im just happy I now have someway to try to resolve this problem. But Im a bit confused. This similar message comes up in various parts of my site, each time a different cgi file is named, ive pulled down 5 or so and opened them. This messages states line 00, <THEFILE> line 00 which im unsure what it means. 00 has different numbers like some said 150 or 48 and so on. I go line number 150 in the code or what ever line it says, but why two lines. Why can one be on line 150 and then the <THEFILE> then it says line 40? Does this relate to the line of code at all? or is there some reference numbers to known problems? or something else? Can someone explain this error message in more detail? Oh yeah, and PS- What is the subscript -1 mean?

Comment on Ignorance Isnt Always Bliss Select or Download Code

Replies are listed 'Best First'.
Re: Ignorance Isnt Always Bliss by GrandFather (Saint) on Feb 12, 2008 at 02:27 UTC
Perl, by default (never change the default) indexes arrays starting at 0. However Perl has a really nice trick where you can use -1 as the index for the last element in the array, -2 for the penultimate element, and so on. The trap that bit you is that if the array is empty then there is no element at the end of the array so trying to access it using [-1] leads to an unhappy life. Note that you can use $#array to get the index of the last element in @array. $#array will return -1 if the array is empty. @array in scalar context returns the number of elements in the array and returns 0 for an empty array. Perl is environmentally friendly - it saves trees	[reply]
Re^2: Ignorance Isnt Always Bliss by Baffled (Acolyte) on Feb 12, 2008 at 03:48 UTC
You can end this string, the problem has been determined a missing / at the end of a url in the lib pointing to the dir that the array was trying to read.	[reply]
Re^3: Ignorance Isnt Always Bliss by GrandFather (Saint) on Feb 12, 2008 at 04:33 UTC
After applying PerlTidy the following looks interesting: open THEFILE, "$config{'basepath'}$key/$file"; my ( $title, $reserve, $inc, $desc, $image1, $image2, $image3, $image4, $thumb1, $thumb2, $thumb3, $thumb4, $dutch, $qty, $bold, $highlight, $feat, $catfeat, $grabber, $relist, $buyit, $gallery, $counter, $ship1, $ship2, $ship3, $ship4, $ship5, $shipcost, $location, $pay1, $pay2, $pay3, $pay4, $pay5, $pay6, $pay7, $pay8, $pay9, $paypal, $idata1, $idata2, $idata3, $idata4, $idata5, $idata6, $idata7, $idata8, $idata9, @bids ) = <THEFILE>; my ( $alias, $email, $bid, $time, $add1, $add2, $add3, $oqty, $qtysold ) = &read_bid ($bids[$#bids]); [download] Notice that @bids is set by reading a file (`my (..., @bids) = <THEFILE>`) and that then, without any checking at all, the presumed to exist last element is accessed. If there are too few lines in the input file then the 'last element access' will fail. Looks to me like there is far too much string and bubble gum involved in holding this system together! Perl is environmentally friendly - it saves trees	[reply] [d/l] [select]
Re^2: Ignorance Isnt Always Bliss by Anonymous Monk on Feb 12, 2008 at 07:13 UTC
As an example of Grandfather's comments about `$#array` and its value for an empty array, and as a duplication of the specific error message you are getting: `perl -wMstrict -e "my @bids = (); chomp($bids[$#bids])" Modification of non-creatable array value attempted, subscript -1 at -e line 1.` [download]	[reply] [d/l] [select]
Re: Ignorance Isnt Always Bliss by betterworld (Curate) on Feb 12, 2008 at 02:05 UTC
The first number is the line of code; the second number means how many lines you have read from the handle THEFILE by the time the error occurs. This can be nice to know if some specific input record is the cause of the error. Actually you will find this kind of message quite often. Compare this: `$ echo foo \| perl -e '<>; warn' Warning: something's wrong at -e line 1, <> line 1.` [download]	[reply] [d/l]
Re: Ignorance Isnt Always Bliss by jrtayloriv (Pilgrim) on Feb 12, 2008 at 02:58 UTC
One thing I often find useful for figuring out what error messages mean is perldoc perldiag, which contains somewhat helpful, albeit very brief, explanations for each error message. Or you can just add "use diagnostics" at the top of your source. Although they won't usually have enough information to tell you exactly what happened, in this case, the description in perldiag might have pointed you in the right direction. It reads: You tried to make an array value spring into existence, and the subscript was probably negative, even counting from end of the array backwards. Which might have pointed you to the fact that your problem involved doing something to an array that had not been created, or a negative subscript.	[reply]
Re: Ignorance Isnt Always Bliss by hipowls (Curate) on Feb 12, 2008 at 02:12 UTC
This snippet shows what is causing your error `my @a = (); $a[-1] = 1;` [download] you are assigning to an array using a negative index that is larger than the size of the array.	[reply] [d/l]
Re: Ignorance Isnt Always Bliss by DrHyde (Prior) on Feb 12, 2008 at 11:30 UTC
Be careful with fatalsToBrowser - you don't want it to leak information about bugs to people wanting to do nasty things to your server. And you should be able to find all that information in the web server's error log as well. Of course, it's easier to ignore in a log file :-)	[reply]