-w switch

[Tim Johnson]

Using the following shebang line:

Code Select Expand

#!/usr/bin/newlisp -w /home/tim -c
;; with .init.lsp at /home/tim
(load ".init.lsp")
returns the following error message

problem accessing file in function load : ".init.lsp"

While

Code Select Expand

(load "/home/tim/.init.lsp")
is sucessful.

Sorry, but I don't understand, The documentation says:

"All file requests without a directory path will now be directed to the path specified with the -w option"

Also

Code Select Expand

(println (directory)) shows the files

from the home directory for the script.

Same problem whether I run from the command line or

as CGI script.

[rickyboy]

Your shebang line is probably getting truncated by the system.  Some systems can only handle up to a 24 character-wide shebang line.  What system are you running this script on?

[Lutz]

Lets assume your script is called: timj. When you execute the script, you have to either call timj with full pathname, or put timj in a directory which is in the execution path e.g: /usr/bin/. This works on Mac OS X, which is a BSD like OS X.

[Tim Johnson]

Your shebang line is probably getting truncated by the system.  Some systems can only handle up to a 24 character-wide shebang line.  What system are you running this script on?

Kubuntu 7.10 => Linux 2.6.22-14-generic

[Tim Johnson]

Lets assume your script is called: timj. When you execute the script, you have to either call timj with full pathname, or put timj in a directory which is in the execution path e.g: /usr/bin/. This works on Mac OS X, which is a BSD like OS X.

Sorry Lutz, but I'm not sure that I understand you. This is a CGI script

shebang =

Code Select Expand

#!/usr/bin/newlisp -c -w /home/tim
Have tried it with and without quotes, with and without trailing "/"

And the URL is invoked as such:

http://bart.johnson.com/cgi-bin/newlisp/testcgi.lsp">http://bart.johnson.com/cgi-bin/newlisp/testcgi.lsp

If I run it from the command line, whether I use

Code Select Expand

/home/http/run/newlisp/testcgi.lsp
or (from same directory)

Code Select Expand

./testcgi.lsp
I get the same problem

Thanks

Tim

[Tim Johnson]

And I have more problems .... This one is driving me nuts!

From a CGI script I am 'saving code to a lisp file - I call it a "session file".

The file is in a subdirectory called "sessions".



No problem writing, but I can't load the same file. The file

is saved with chmod 644 and chown www-data.

I can't 'load it, read-file doesn't "read" it, and

(directory "sessions") returns other files with owner "tim",

but does not "see" the session file. Really weird!



I'm having the same problem whether or not I use (real-path) to

compose the path. And whether I set ownership of the "sessions"

subdirectory to 'tim' or to 'www-data'



On the other hand, if I save the session file in the same directory

as the CGI script, I can load it just fine, but that is going to be

just plain messy.

Tim

[Tim Johnson]

Oh! Left something out.

If I start newlisp from the same directory as the

CGI script, I can load the session file.

Example:

Code Select Expand


> (load "sessions/FSvXHs0WF5X7dzZ.cgi.lsp")
MAIN


I'm using the -c switch in the shebang line:

Code Select Expand


#!/usr/bin/newlisp -c

Could this be the problem?

Tim

[rickyboy]

I'm using the -c switch in the shebang line:

Code Select Expand


#!/usr/bin/newlisp -c

Could this be the problem?

Tim

I think so.  I haven't used -c yet; especially not in my newLISP CGI scripts (now that I'm looking at them).

[Tim Johnson]

The problem persists even if I eliminate the -c switch from the shebang line.

tim

[rickyboy]

Tim,



What web server are you running?  Apache?  If so, you may need to enable the 'sessions' subdirectory with the same attributes its parent (in the .htaccess, or similar device).  If that's a security problem, try this instead: save your session file to a file name not ending in '.lsp'.  Maybe Apache treats .lsp files differently, now that you have them wired to a CGI handler.



Just some ideas.  I'm not an expert and I don't have my Apache book handy.

[Tim Johnson]

It's gotten even weirder. I'm using a context member called 'extension.

With extension set to ".cgi.lsp", I can't see any file with a ".cgi.lsp"

extension,

Now here is the weird part:

If I change 'extension to ".cgi.sess", now I can "see"

(using (directory "sessions")), files of extension ".cgi.lsp",

but I _can't_ "see" any filesof extension "cgi.sess".

I am using apache and I'm not familiar with the fine points of apache

configuration.

Furthermore, even 'tho I've been making a living CGI programming

for the last 12 years, I have not been _reading_ files

from subdirectories below the directory of the script, although I have

been _writing_ files to subdirs plenty often.



Time to give my poor little brain a rest.

Thanks!

Tim

[Lutz]

There should be no reason to use the -c in a shebang line. -c suppresses the prompt, but that is suppressed anyway when newLISP is executed via a script, so -c in a shebang line is redundant.



There also should be no reason to use -w in the shebang line. The effect of it seems to be different on different OS, e.g. on Mac OS X, newLISP tries to find the rest of the script file, after the shebang file in the -w directory, which is the reason I recommended to use the full pathname. I have meanwhile tried this on FreeBSD, where this is different and behaves more like Linux.



But I was not aware, this is about CGI processing. To make a long story short:



(1) don't use any -c or -w in the shebang line of your CGI script. Let Apache handle the way it switches working directories. Your script automatically will see the directory of the script as the current directory. Your scripts will behave like any other Perl or Python CGI scripts regarding directories.



(2) You can refer to scripts below the current directory in a relative fashion, etc. (read-file "subdir/mydata.dat") would read the file below the directory, where the cgi scripts is. Use the function (real-path) as a quick way to find out the current directory:

Code Select Expand

#!/usr/bin/newlisp

(print  "Content-type: text/htmlrnrn")
(println (real-path))
(exit)


(3) let all newLISP CGI scripts have the extension .cgi, without something else after the .cgi. If those CGI scripts handle data files, they can of course have any other extension, but the scripts executed by Apache, should only have .cgi or whatever Apache is configured too.



(4) make sure your .cgi script files have the right permissions and the right owner, as usual with any cgi scripting.

[Tim Johnson]

Hi Lutz:

1)Understood about the -c and -w switches.

2)About using .cgi as an extension. :-) I haven't done that in

decades! And that was when I was using compiled c code

on NT 3.51 web servers.

On my workstation, apache is accepting .lsp extensions

even without adding lsp to

AddHandler, but it will be interesting to see if

that is the case with other servers. I configure apache so

seldom that I forget just about everything from one episode

to another.

I'm going to email my domain hoster and see what he says.

I know he's been playing with newlisp himself.

3)Not loading the session file: Turns out another process was

deleting it prior to the load function. I confused the two issues

(the switches and 'load problem)

Thanks

Tim

[Tim Johnson]

Just got a reply from Corey Johnson of Cniweb.net. (no relation)

Regarding using .cgi as an extension.

As long as the script is marked as executable.. and it is in a folder

defined in apache that allows cgi.. that it really all you need to do.  :)

I.E. No need for the .cgi extension.

BTW: cniweb is a recommended hoster. *very* competent. *very* open

to installation of "non-LAMP" systems. He's been hosting rebol scripts

for about 7 years, and would host newlisp, if he isn't already...

P.S. We're talking about apache here.