World: r3wp

Changes commited to revision 128:

FEAT: added support for 'access-os native. Now Cheyenne can work 
with /Core on MacOS X.

FIX: READ-CGI mezzanine is missing in /Core 2.7.8 on MacOS X, Cheyenne 
is now supplying it in such case.

onetom: can you test the changes on your Mac? It should now work 
with /Core too.

Script: "Encap virtual filesystem" (21-Sep-2009)
REBOL - Security Check:

Script requests permission to execute a system shell command: netstat 
-f inet -p tcp -na
Yes, allow all, no, or quit? (Y/A/N/Q)

Answer: A

hmm  is it the implementation of the access-os?

cheyenne specific thing?

it starts otherwise

how can i test the read-cgi issue?

It is a Cheyenne thing to check for available TCP ports for listening.

onetome: use the default test site from the source archive.

http://localhost

Then just click on the CGI test.

Max: your task-done callback have to call these two internal functions 
in order for your response to be sent:


process-next-job	      ;-- this one is for being kind with other 
requests in the queue

service/process-queue   ;-- this one for sending your response to 
process other requests in queue

cgi test under linux, viewing w links says:

#[object! [ code: 300 type: script id: no-value arg1: set-env arg2: 
#[none] arg3: #[none]    
   near: [set-env name value] where: context ]]

Strange, testing that on my Linux image...

Does it work ok on Mac?

on mac, the my copy of the repo had a custom httpd.cfg, which i moved 
away, but now it doesn't want to regenerate it

Script: "Encap virtual filesystem" (21-Sep-2009)
make object! [
    code: 500
    type: 'access
    id: 'cannot-open

    arg1: {/Users/onetom/rebol/cheyenne-server-read-only/Cheyenne/httpd.cfg}
    arg2: none
    arg3: none
    near: [conf: load either exists? file]
    where: 'read
]

let me try a clean checkout

Looks like a user permisson issue?

#!c:\dev\sdk\tools\rebol.exe  --cgi
and this is the cgi issue

and no exec flags either

-rw-r--r--  1 onetom  staff  1128 Apr 18 00:41 www/show.cgi

svn can only assign exec flags in a post-hook, right?

I am not enough familiar with svn on UNIX to answer that question.

and i use darcs and occasionally git, but i hate git :)

ok, it works after

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ chmod +x www/show.cgi 

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ head -n1 www/show.cgi 
#!/usr/local/bin/rebol -c

is this hash bang thing under windows also a cheyenne feature?

yes

Ok, let's have a look at your log files proposition...

Doc, thanks... had only the service/process-queue... added the process-next-job() 
function and calls... 

seems like I'm getting an error elsewhere now (later in the reply 
chain), so that's a good sign.  thanks.

it would be nice to have a little options in the cfg file... something 
like

-trace-log %/path/to/folder/

Max: wait...process-next-job is RSP specific (RSP requests queue 
management)

What is the issue with having %trace.log in the same folder?

well, it took me a month to realize where it was.... in my REBOL.exe 
folder.   :-)


the problem with using "current-dir" is that it can be anywhere, 
especially on windows where the concept of a current-dir is pretty 
clueless.

just for example, depending on how you start a rebol application 
(shell, drop icon, link), there can be 3 different current dirs...

You can change that easily if you're running it from a shortcut icon. 
Edit shortcut properties and set the "working folder" where you like 
it to be.

yeah, but I want that kind of thing to live within the configs... 
 since... its a configuration  ;-)

anyhow.. I can hack it in quite easily... its not that big a deal.. 
just a suggestion  :-)

wrt handler... yes.. I just looked in more detai and the error is 
related to the process-next-job().

I won't make a per log file configuration option, that wouldn't make 
much sense. When I'll had such option, it will redirect all log files 
to the same folder. Still need to finish reading onetom proposition 
to see if there's a better solution.

it should also go to a %log/ folder

meanwhile i wrote a little script to fixup the cgi hash-bang lines 
and give exec flag on them

Doc,    wrt handler.. it really was a stupid error on my part... 
I didn't set the   req/out/code   so I guess it stays in limbo in 
its worker handling, since its not valid for request handling, but 
it has no return error code for reply handling either...

CGI scripts run from Cheyenne don't require the executable flag to 
be set.

Cheyenne extracts the shebang line and CALL it, passing the script 
name as argument.

even on unix?

Yes, all CGI scripts are running on my Linux box, with 644 permissions.