World: r3wp

I think I have found an issue with /Core 2.7.8 on OS X, the READ-CGI 
mezz is missing! That's making Cheyenne (rev 127) crash on any CGI 
script request.

I need to patch Cheyenne to workaround that.

This CGI issue on OS X crashes Cheyenne in source mode and the PRO 
binary (the CMD binary is unaffected).

sounds weired because i thought i was using it in cgi mode

bind-extern CGI to [.r .cgi]
        bind-extern RSP to [.j .rsp]

my config is like this

It crashes only if you call READ-CGI.

and u only call it when there is a POST request?

ah, ok, i see it in source read-cgi

You can call it whenever you want, but it is useful only if there's 
some input data.

I have included the READ-CGI mezz in CGI.r to make CGI work on /Core 
2.7.8 on OS X. Testing, will push it in a couple of minutes.

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.