can anyone help whith this?
Links2.0 installing on Linux
error:
Undefined subroutine &main::cgierr called at admin.cgi line 42

I know where it is (er.. line 42) but do not know enough about perl to work out what's going on.

nellus

That's an odd error. The sub cgierr is contained in the db_utils.pl script which is required at the top of admin.cgi.

Try using the full path to links.cfg (the path should be from your root directory) in the following line of admin.cgi:


I hope this helps.

Unfortunately, still the same error.

I have double checked all the required files paths and permissions - all is fine.

In your links.cfg, are you using full paths or relative paths? In other words, do your paths start from your root directory or are you specifying something like "/cgi-bin/links/admin"?

If the latter, change them to full paths starting from your root directory. If they are full paths, then something else must be wrong but what it would be, I am not sure.

Finally a chance to get back to the problem...

I have set full paths to absolutely everything. Still no luck.

Still returns:
Undefined subroutine &main::cgierr called at ./admin.cgi line 42

BTW I'm running this from the command line to try to sort out the 500 server error I get from running from the browser.

I don't think you can run admin.cgi from the command line. It has to be run from the web.

But I'm getting a 500 server error from the web.

I am simply running a command line instruction in an attmept to see what's happening and get some clue as to the error.

A working script should at least offer some fedback such as headers and info - I wouldnt expect much more.

Mind you, I'm no expert, this is just the normal way I have been able to debug scripts in the past.

Oh well.

The 500 error message can be caused by many things. Links is setup to (hopefully) trap the majority of them (syntax errors, typos, etc) but it cannot catch everything.

The error you are getting from the command line cannot be solved because admin.cgi will not run from the command line even if you did solve it. Instead, you would just get a new error message that says:


So the obvious solution to this problem is to resolve the 500 error message. Since Links did not catch the error, it must be something external to the script causing the problem. Things to check are:

1. Path to perl on the top line of the script. It must point to a valid version of perl. Admin.cgi requires at least v5.001 but other Links scripts require higher versions.

2. Permissions on the script. All .cgi scripts must be chmod 755.

3. Was the script uploaded as ASCII.

5. Are the paths at the top of links.cfg using full absolute paths from your root directory instead of relative paths (from your /cgi-bin directory, for example).

If you check all that and still have the problem, see if you can get access to the error logs to see what they have to say. Sometimes, they might help although, most of the time, they just say "premature end of script headers".

If all else fails, see if your ISP can shed any light on it. Maybe it is a cgiwrap problem (if that is installed).

I hope this helps.

[This message has been edited by Bobsie (edited July 03, 1999).]

I get the exact same error;

Undefined subroutine &main::cgierr called at admin.cgi line 42.

The thing won't run from the web; and you can run any cgi script locally to get an idea of trouble spots; so this line is a problem in the script. I have spent three straight nights trying to get this thing running; I have NEVER hasd thisa much trouble with a CGI script.

Running it (Or "attempting" I should say) from a UNIX machine; I know I sound a bit edgy; but after quite a few hours of this, I'm at my wits end. Could someone please help me with this? TIA.

Invincer

Not much support in these forums I guess. Hrumph, why is this thing rated so high? There's multiple people having this problem and noone seems to want to aknowlege it.

Invincer,

Support on this forum is good, provided you provide as much information about the problem as possible. All you have provided is the error message. Nothing about your configuration, paths, etc.

Links is rated high because, right out of the box with only the changing of 5 paths or URLs in links.cfg, it will run if properly installed.

I agree with Nellus.

I have installed numerous scripts without difficulty; the configurations are correct; it's that damn "Undefined subroutine &main::cgierr called at admin.cgi line 42Z" that is the problem. And if you say that has nothing to do with it, that the thing just won't run locally; that's just plain stupid. You can always run a script locally to find errors. If you can''t, then that is something wrong with the script right there.

Well after a good few hours of struggling I still did not get things up and running.

Yes, EVERYTHING was checked, double and triple! In the end I opted for Indexfnger (got to put up with support with an attitude tho) and got it running within an hour. I may have stuck with links, but time had just run out.

My biggest gripe with setting up links is the complexity of the required directory structure of all the elements. It's difficult to follow what's going on and sort problems.

It's standard practise to run commands from the telnet command line to give some indication of what's happening in a perl script - something which has sorted out almost all the problem installations I've come across. Not being able to run links and get some header/output info is just a pain.

Oh well.

The admin.cgi script will not run locally because it dynamically creates html pages containing frames for the admin interface. You cannot use such a script from the shell since there is no way to display html from the shell, especially frames. The only way to do it would be to use Lynx if your ISP has it installed but even that text-based browser will not display frames correctly. It will provide a menu of sorts, though, that will permit the script to be run.

There is a specific reason for the error you are getting but, without knowing how you are configured, there is no way to help.

Have you at least checked the syntax using the shell command:

perl -c admin.cgi

to see if it returns any errors?

[This message has been edited by Bobsie (edited August 23, 1999).]

As stated above I gave up and used another application to do the job.

But, if the script builds html pages/frames I would at the very least expect the first couple of lines of output to look something like html headers.

Never been an issue with any other script I have installed, always been able to get at least some debugging info from the telnet command line.

Compared to Indexfinger, it's a LOT more complex to install, IMHO.

Actually, Links is easier to install, IMHO. If it is extracted from the archive in a manner that preserves the directory structure and that is how it is uploaded to the server (all in ASCII except for background.gif), then to get it to run you only need to set the permissions, point to the correct location of perl at the top of all .cgi files, and change links.cfg (the first 5 paths/urls). It should run after that. From then on out, it is just tweaking to get the look and feel of your site.

I have done the basic Links install in under 15 minutes on various sites and have never experienced the problem you were having. I am willing to bet I would have the same success on your or invincer's site as well.

[This message has been edited by Bobsie (edited August 24, 1999).]