Pipeline Frequently Asked Questions

This FAQ hopes to address some frequently asked questions about Pipeline version 2.0. Well, okay, some of these have never actually been asked, but I anticipate them being asked.

What is Pipeline?

Pipeline is an implementation of the CGI Filter/Pipe Interface (CGI FPI) for Unix using Perl version 5. Instead of a single CGI script that needs to do everything when a form is submitted, Pipeline executes a number of cooperating modules instead.

Who wrote Pipeline?

Jim Hoagland did and released it in January 1996 as an improvement over a previous effort Getcomments. Version 2.0 was released in January 1997.

How much does Pipeline cost?

Pipeline is free of charge to everyone. If you like Pipeline or use it alot, I ask that you send me a postcard telling me so.

Where can I get Pipeline?

You can get Pipeline from the Pipeline home page and in the HTML Form Processing Modules (HFPM) distribution.

What modules are available for Pipeline?

At present, the only modules publicly released are the HTML Form Processing Modules (HFPM).

Pipeline.pl does not seem to be getting executed. What's going wrong?

Make sure that the first line of pipeline.pl contains the path to Perl version 5 on your system and that the permissions of the file are set to allow the user that the server runs as to execute it.

How do I make pipeline.pl get executed as a CGI script?

This is particular to your local site, so you may need to ask your server administrator. Typically, you put it in the "cgi-bin" directory or change its name to end in ".cgi".

Why isn't this file being appended to?

Keep in mind that when Pipeline is being run, it may be running as a user other than you. Making sure the file is writable by that user may solve your problem.

I think there are some errors, but I'm not seeing any messages. Why is this?

Do you have the _errorsto field in the form set? Do you have the default errorsto value set? Make sure that the errorsto value(s) being used are valid e-mail addresses or files.

What are these things at the end of error messages from Pipeline?

It is the context in which the error was generated. To aid in solving the problem, all the environmental variables and form fields and their values are appended to error messages.

What does xxx Pipeline error message mean?

"could not open /x/y/z to get a list of valid modules"

/x/y/z is the file that the $MODULE_LIST_FILE variable indicates that the list of valid modules should be located in, but that file does not exist or could not be read from.

"/x/y/z is not a valid module since it is not on the list"

/x/y/z was found as a module to execute, but it wasn't since it was not on list of valid modules.

"no valid modules were specified"

No modules names were located where Pipeline expected to find them. This is part of the fixed module name feature. Either the file specified in $MODULE_LIST_FILE was empty or the @VALID_MODULES list was empty.

"xxx is not a valid module name;..."

To reduce the chance of trickery and to serve as a sanity check, module names may only contain only letters, numbers, "_", "-", ".", and "/", but xxx contained some other character

"could not locate xxx ..."

xxx was listed on the pipeline, but could not be located. Either give the full path to xxx, add the path to _path, and/or add it to the list of valid modules.

"could not open xxx for read"

xxx was a module file, but it could not be read from.

"could not run /x/y/z"

The module /x/y/z was found, but an attempt to run it failed for some reason. This could be the result of an error in /x/y/z.

"found empty module reference on pipeline; ignoring"

Something like a "| |" appeared on the pipeline and was treated as a single "|".

"could not open /x/y/z to get a list of valid paths"

/x/y/z is the file that the $PATH_LIST_FILE variable indicates that the list of valid paths should be located in, but that file does not exist or could not be read from.

"/x/y/z is not a valid _path component, because it is not on the list"

/x/y/z was listed on the _path field as a place to look for modules, but it is not on the list of valid path values.

"/x/y/z is not a valid path component; ..."

To reduce the chance of trickery and to serve as a sanity check, path components may only contain only letters, numbers, "_", "-", ".", and "/", but /x/y/z contained some other character

"could not open /x/y/z to get a list of valid _errorsto values"

/x/y/z is the file that the $ERRORSTO_LIST_FILE variable indicates that the list of valid _errorsto values should be located in, but that file does not exist or could not be read from.

"xxx is not a valid place to send errors to since it is not on the list"

xxx was listed on the _errorsto field as a place to send errors, but it is not on the list of valid _errorsto values.

"could not open /x/y/z for appending the message: abc"

/x/y/z was listed in the _errorsto field as a file to append error messages to, but it does not exist or the write permission wasn't granted over the file. abc is what would have been written to the file.

"Illegal character found in e-mail address: xxx"

Some mail was going to be sent to xxx, but it contained an potentially dangerous character.

"Could not run xxx. Hint: make sure $SENDMAIL (now set to yyy) is set to the location of your sendmail executable at the top of pipeline.pl"

The default and standard location of sendmail is /usr/lib/sendmail. If yours is somewhere else, change pipeline.pl to reflect that fact.

"you should not run Pipeline as root, but if you must, ..."

It is ill advised and potentially dangerous to run Pipeline as the root user. Pipeline will allow it only if you use the fixed modules and the fixed errorsto features.

Why am I getting Pipeline error messages that (according to the X-URL mail header and the REFERER_URL environmental variable) indicate are from a form that I don't know about?

Well, either someone put your e-mail address (or file) down as an error recipient for that form, or someone is using your pipeline.pl without telling you and you got the message as the default place to report errors. In the later case, it may be that the other person is trying to attack your site through Pipeline.

Why do the global parameters need to be set in pipeline.pl?

These can't be set in the form since you don't always want to trust the form and there is no other standard place for CGI customization information.

If you have any questions that aren't answered by the FAQ or other online documentation, feel free to e-mail webmaster@hoagland.org for more information or with questions. Be aware though that Jim is busy and it might take a while to respond to your message.

17 January 1997