-
Posts
22 -
Joined
-
Last visited
Everything posted by 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.
-
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.
-
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
-
Big Problem With Perl Script Limit!
shop-et replied to shop-et's topic in CPanel and Site Maintenance
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... ... -
Big Problem With Perl Script Limit!
shop-et replied to shop-et's topic in CPanel and Site Maintenance
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... -
Big Problem With Perl Script Limit!
shop-et replied to shop-et's topic in CPanel and Site Maintenance
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...? -
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?
-
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.
-
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
-
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
-
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, ..."
-
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
-
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
-
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.
-
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.
-
That is the thing that confuses me. It doesn't give an error. It simply skips a part of the script for some reason. According to both Activestate Perl 5.6.1 (build 635) and Perl 5.8.0 (build 806) on my machine, the script should be running perfectly. However, the interpreter on the server, which I'm told is Activestate 5.6.1, insists something is amiss. For some reason, the server simply skips over a piece of the script. Both myself and another system admin have concluded that, by all reasonable lengths of logic, the accursed thing should already be working and both Perl interpreters on my machine concur. I honestly have no idea why this god forsaken thing refuses to work. As for what I am trying to do, the function that is being ignored for some reason (already tried variable renaming in case of reserved words) simply scans through two arrays and splices out the matches from one of them. The coding is so simple it's almost painful. If you have ever heard of this happening before or have any ideas, please, do tell. Thanks again.
-
I have been trying for two days now to get a particular script to run on the server. According to myself, a system admin of six years, another befriended system administrator, and Activestate Perl 5.8.0 (build 806), the script is flawless and should be working. However, the server doesn't seem to think so. I think an upgrade of the server's perl binaries is in order. I understand only very few people would be capable of this, so I would like someone of authority to take this into consideration. If anyone else has had an problems with this, I would like to hear about those too. I have already submitted a help ticket for this and am hoping for the best. Thank you, one and all.
-
Thanks Rick... permission working for now... BUT... I can't start a help ticket because the system says I'm using an invalid username... if I can't get in... I can't submit a ticket... We're going to be using a lot of sub-domains as shops and I really need a fully functional c-panel.... Head Bash
-
need help quick on this permission setting problem... TIA
-
Headguru... domain name is www.shop-etc.com what's up the cgi-bin permission setting problem... any clues?
-
Head Bash Trying to start a help ticket but access is denied to the client area.... says I'm using an invalid user name However... I'm using the exact user name and password from the original email Here's the problem... As posted in the c-panel forum... but no answer... we're trying to install a program in the cgi-bin area but change permission is not functioning... We set the permissions to 755 but it does not change...
-
We're trying to install a program in cgi-bin but access is denied... c-panel appears to allow change of access but it does not... we keep setting it to 755... but it does not change... help Head Bash
