Jump to content


  • Posts

  • Joined

  • Last visited

shop-et's Achievements


Explorer (4/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges



  1. shop-et


    As I said, this script is known to run flawlessly. It still runs fine on my box and it has been running fine on the server for months on end until the last few days, when it simply stopped working for no apparent reason. No one changed anything and I triple checked to confirm this. This isn't a problem with my code, unless some dependency on the server has changed to invalidate it. But, just in case there is something someone knows about that I don't, here's the code. The file 'db' is a small text database, one entry per line, laid out in the format: <image_filename> || <affiliate_link_for_this_image> This script works in three stages. The first (when run with no input), returns an html snippet referring the browser back to the script for an image source. The second stage scales the image for a consistant height (51 pixels) and feeds the browser the image headers and then the image itself. The third handles the click-thru connection, acting as a make-shift ghosting script for the banners. I'm writing this here because the script is small enough and simple enough that I didn't bother throwing in any comments.
  2. shop-et


    Actually, from my experience, errors can occassionally occur because of a LACK of a blank line or two at the end. Anyway, if that were the problem, then I should have gotten that from the beginning, not a sudden, unprompted change like this. I developed this script on and uploaded it from my Slackware10 box here. No winblows involved. The script is located here: http://garden.shop-etc.com/cgi-bin/rotb/rotb.cgi. Running it with no input (as it is in that link) should produce a snippet of html code. Instead, I get a 500 from Apache.
  3. shop-et


    A few days ago, a banner rotating script that I wrote suddenly stopped working. It's a perl script called by SSI. There are two seperate copies of this script, one on the front page and one in a subdomain. These two are, of course, completely isolated from one another and thus have only three common dependencies: Apache, Perl, and Perl's Image::Magick module. We haven't touched these files in months, but still, I've checked all of the files in both directories against my originals. I've checked to ensure the originals still work. I uploaded the known working copies over what was on the server. I even checked the permissions for the scripts. Everything is now as it was when the scripts were working. None of the SSI calls have changed either. The funny thing is that both of the scripts mysteriously stopped working at the same time. That leads me to believe that something has changed server-side of which I am not aware. And, luckily, all of the admins are greedy with even jailed shells, so all I have to go on is Apache's extremely helpful, catch-all error message: "Premature end of script headers." So, anyway, I was just wondering if anything on the server has been upgraded or changed recently that may impact perl cgi scripts and whether or not anyone else has experienced a similar mysterious failure. Thanks in advance, -Mark
  4. OK Lisa... I'll buy that for the moment... but... ... "Backend Services" has not had a great record for solving problems... ... It seems to be more like the place that questions go to die... ... I didn't mean to be rude... just straight to the point.. ... We need a solution to a problem... We're tired and overworked... ... and we're ready to go to bed... All we want is an answer... ... If you can't help us... Please don't hurt us... ...
  5. Gee thanks Lisa... ... No help, No answers, Shuffed to the back of the bus... ... Didn't mean to upset the powers that be... ... Too straight to the point...? ... Why didn't you leave this question where it was? ... We might have gotten some answers... ... Didn't mean to ask honest questions of you... ... I thought this was an open help forum... Guess Not! ... But... I will say... You're very good at damage control LOL...
  6. Yo! Where are the 24/7 TCH folks.. We're burning the mid-night oil trying to fix this problem.. It's 2:45 AM eastern time here and we're getting tired and frustrated... We would appreciate a little help... Anybody awake out there...?
  7. We are converting our site to 100% merchant data feeds with auto updates if we can get the cron function to work, which we have had problems with so far... Perl script works fine on merchant data feeds up to 22 megs... Anything larger shuts down the script... Is there a limit to the size of a perl output file on the server? Overstock.com has broken their CSV feed (comma separated values) into sections, but the music section alone is 50 meg ... I hate to think what will happen with the Walmart data feed... Is there a way or a work around to let the perl script decode and display data feed information without shuting it down at 22 meg?
  8. As a quick addendum, that eval experiment aided much in narrowing down the suspect functions. I've got it back into working order. Thanks again for the ideas.
  9. Jimuni: Much thanks for the information. I'll keep that in mind for future phantom errors. rayners: I had not thought of that. I'll give eval a shot. Your suggestion is much appreciated. Thanks to you both. -Shop-etc.com Webmaster
  10. I have read back over all of the user agreements, server policies, and boilerplate, but I've not found anything regarding telnet (I could have sworn that I read something about it somewhere on here). I tried to telnet into my domain name and it told me that my account's telnet access is disabled. For some reason, I now can't even get a response from the server, but that's a side point. My problem is that I am troubleshooting a perl script (no scripting assistance necessary or requested) and it works absolutely fine on my side with two seperate versions of ActiveState's perl win32 binaries and a linux native perl 5.8.0. For some reason (although everything is flawless here), Apache unceasingly returns a "Premature End Of Script Headers" error for my perl script. Anyone who knows Apache can tell you how informative that error is. What I need is a bash line on the server (telnet) from which to run perl manually, so I can get some kind of useful error message, in order to know why Apache is freaking out when the coding should be flawless. Even a simple perl error message would be better than flying blind, changing around things that *might* be causing it (and don't think I haven't already tried plenty of that). I'm out of ideas. Without a meaningful error message, I have no clue as to what the problem is. Should I start a help ticket for this, or something along those lines? How should I go about this? Thanks for the time, to anyone who replies. -Shop-etc.com Webmaster
  11. Thumbs Up "Pain heals, chicks dig scars, glory lasts forever" From the movie... "The Replacements"... outstanding movie... The last motivational speech by Shayne Falco... the replacement quarterback, spoken in the last huddle... of the final game.... Great choice for a tag line... ! Makes it hard for me now, to find something better... LOL Bob Song from the end of the movie and all the players dancing.... Dance Dance Dance Dance "I've got all my life to live, I've got all my love to give, I will survive, I will survive... Oh, Oh, Oh, ..."
  12. Bill... It just showed up on my last attempt... Apparently it takes a little longer to show up on some systems than it does on others... As they used to say on Saturday Night Live... "Never Mind" Thanks for your responce... Bob
  13. This is really slowing our business down... So far I haven't been able to do anything on cpanel Unless I ask for activation first... and then wait until someone allows me to do the stuff that I thought I was going to be able to do "on the fly"... I'm trying to creat a sub-domain called "garden" on www.shop-etc.com but the browsers say it doesn't exist... I had the same problem with "permissions" on the file manager a few days ago... Does this mean that I have to ask for permission or activation of each feature every time I want to do something that I haven't done before? I'd really appreciate any help I can get with this... I, and the people that work with me, are accomplished programers and I thought that we'd be able to use cpanel without having to ask for permission function by function... slow and sucky... Is there any way that all permissions can be activated right now so that we can actually use all of the cpanel functions like we thought we would be able to do, without having to ask for "activation" one function at a time... ? Thanks in advance... Bob
  14. That would only cause a complication if you were removing multiple elements in a single loop. That is why the @keywords foreach loop is nested within the other. If you were removing two or more elements, then Perl wouldn't reset the foreach counter and would skip one each time. The way I have things arranged, skipping one doesn't matter. If an element that should be excluded is doubled and one is missed, that would be filtered out later in the script. If it were something that simple, then it shouldn't have worked at all, however it did on my end, just not on the server. This inconsistancy is what is throwing me for a loop. Thank you for the effort and feel free to add any more input if something else occurs to you. Oblecte.
  15. This is the code that's being inconsistant: #----------------- foreach $Exclusions (@Exclusions) { $scnt = -1; foreach $keywords (@keywords) { $scnt += 1; if ($Exclusions eq $keywords) { $Excluded = '<font face=arial size=2 color=blue><i>Excluded Common Words: |</i></font><br>'; $List .= $keywords; $List .= ' '; splice(@keywords,$scnt,1); $Ifex = 1; } } } if ($Ifex == 1) { $Excluded =~ s/\|/$List/; } #----------------- # # Here's the code for the print: # #----------------- <br> <center> <font face=arial size=2><i>$final</i></font><br> @Exclusions<br> $List<br> $Excluded<br> <hr width=30%> <br> #----------------- I apologize because I know this code won't show up well on a post. Also, Perl isn't my native tongue, so my scripting absolutely reeks of c/c++, but it should still be working. Here is the output on my box (with both Perl 5.6.1 and 5.8.0): Here is the output on the server: And I am absolutely sure it is the same file. I have been told that the server is running Perl 5.6.1, which is the same as one of the versions I have tested it with on my machine. I have rewritten it to do the same thing four or five different ways and every time is the same result. I am by no means a newb, but I must admit that this is a stumper. Any ideas? Thanks again.
  • Create New...