CGI dependant libs being in 'search path' of the web server

CGI dependant libs being in 'search path' of the web server

Post by Anthony Mullig » Tue, 10 Jun 1997 04:00:00



I am encountering a problem with a perl script, that makes a call to a
db_access lib that was written in C.

The script calls the db_access, which passes form data off, after adding
SQL code, to an oracle Database over SQLNET.

When I run a test script from the unix command prompt, I get a returned
"SUCCESS" message from oracle, but from the browser, I get the boiler
plate html
I have embedded in the script returned, but the retreived oracle data string
is not printed.

I have several ideas as to why. But I am hoping someone might have had a
similar problem before, and be able to point out a definite solution.

The permissions for the script are set up ok, but the db_access lib I am
passing the args to may not be in the server's search path, If that is the
case, how do you add it to the server's search path.

The test script.

#!/usr/bin/perl

$foo =`DBaccess "addorder" "1" "06-06-97" "apples"`;

print<<EOF;

 content-type: text/html

<PRE>
print $foo;

</PRE>

EOF
-------------------------
when run from the command prompt, returns "success".

It may be just that I need to move the content-type header to the very
first line, but I don't think it's that as the <pre></pre> tags can be
seen as output in the browser source code.
It's $foo which is not printed.

Here are some Ideas that someone suggested, that sound possible, if anyone
cares to add anything to the following, it is appreciated.

 
 
 

1. zsh's 'typeset -U path' wipes out path/PATH

I've found a bug (or at best a very perverse "feature") in zsh; it
can be illustrated by the following three short scripts:

# script_A
PATH=/usr/local/bin:/usr/bin:/bin
echo $#path
typeset -U path
echo $#path
# eof

# script_B
source script_A
# eof

# script_C
c_fxn () { source script_A }
c_fxn
# eof

Note that both the contents of script_B and the body of the function
c_fxn defined in script_C consist of the same one line, namely
"source script_A".  Now,

% source script_B
3
3
% source script_C
3
0

In words, when script_A is sourced within a script that is itself
being sourced, typeset -U path preserves the components of PATH
(or at least their number), but if script_A is sourced within the
body of a *function*, calling the function causes the expression
typeset -U path to *clear* the contents of PATH.

Please-please-please don't tell me this is a feature!  I'd lose
all faith in the designers of zsh if this turns out to be a feature!

More importantly, how does one get around this problem.  I've tried
saving the value of $path before calling 'typeset -U' on it, and
restoring it afterwards, but the results have been disastrous (I've
tried too many variants to describe them all).

kj

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

2. pppattach question

3. convert 'a' lib' into 'so' lib

4. /dev/poll ioctl dvpoll.dp_nfds usage changed?

5. sndconfig 'sndcore.o not found in module search path'

6. tar files which fully specify directory

7. KDE 'search path'?

8. setup adsl

9. What's more secure cgi-lib.pl or CGI.pm?

10. What's 'side effects' of Ksh built-ins?

11. methods to operate on instances of class ``Path'', was: path utility functions

12. Search file from 'bottom to top', varying search ?

13. Can't Alter My Path, Can't Find My Path