World: r3wp

doh!

here's another one ...

kernel32: make object! [
lib:  load/library %msvcrt.dll

get-env: make routine! [
	varname [string!]
	return: [string!]
] lib "getenv"

put-env: make routine! [
	env-string [string!]
	return:    [integer!]
] lib "_putenv"

remove-env-var: func [name [string!]] [put-env join name "="]

env-var-exists?: func [name [string!]] [
	either "^@" = get-env name [false][true]
]

tz-set: make routine! [
	return:    [integer!]
] lib "_tzset"

free_lib: does [ free lib ]

]

since they both work while the app is running, I guess that's okay 
for windows.

Thanks, but still for win32, do you have one for linux ?

aren't linux env variables just disk files ?

don't know, possibly, but I'm on Windows, I can't test that for now...

http://www.linux.com/howtos/Secure-Programs-HOWTO/environment-variables.shtml

maybe that will help

Looks like it's stored in memory only : "In short, environment variables 
are internally stored as a pointer to an array of pointers to characters; 
this array is stored in order and terminated by a NULL pointer (so 
you'll know when the array ends). The pointers to characters, in 
turn, each point to a NIL-terminated string value of the form ``NAME=value''"

so need some wrapper script to set the env variables?

yes, /usr/bin/env

The problem is that 'REQUEST_URI' is Apache specific, it's not part 
of standard CGI...

I'll see how to handle that when my CGI generic module will be ready 
(for Cheyenne 1.0).

Sorry for QM, I don't have a simple solution to integrate it with 
Cheyenne, for now.

here is mod-rewrite for cheyenne http://reboot.ch/mod-rewrite.r

althought it may need some changes in cheyenne's core as well

I don't need Request_Uri specifically, just something that acts that 
way.  When I say I don't want to fork QM, I mean the script -- a 
few 'if find request/server-software "Cheyenne"' calls are not a 
problem.

For example, if there was a way of hijacking 404s, passing the 'request 
uri' as do/args to %qm.r, that would work too...

I customized 'mod-rewrites'  for Cheyenne by intercepting the requested 
file in httpd.r  works great.. much more powerful than Aoache's mod-rewrite. 
 Same would work for 404s

Doc, Chris, Cheyenne could just redefine get-env, couldn't it?

This gets it working, but doesn't honour existing files.  mod_qm.r 
(with qm at the top of the list of modules in httpd.cfg):

REBOL []

install-HTTPd-extension [
	name: 'mod-qm

	order: [
		url-to-filename last
	]

	url-to-filename: func [svc req conflo][
		req/in/path: "/"
		req/in/target: form req/in/file: %qm.r
		req/file-info: info? req/in/file
		req/handler: select svc/handlers req/in/ext: '.r
		false
	]
]

Then in the CGI handler, I changed this line (just to see if it works, 
not as a recommendation):

soc/path-info: data/in/url

Finally, in the 'request object in QM, I changed the Request_Uri 
line:

path: any [path-info get-env "REQUEST_URI"]

I recognise this may not be the correct usage of Path_Info, though 
I'm not sure what correct usage is -- the CGI spec explanation doesn't 
really clarify things...

Cheering squad: Give us a "C", give us an "h" ... Go "Chris"  


On a more serious note.  I've offered to help design/beta trial REBOL 
Want Ads.  QuarterMaster seems

like a candidate for this.  There isn't any time pressure, as this 
will take a while, but what is your gut feel for Cheyenne support? 
 From reading !Cheyenne you seem to have got a workable solution 
to get at the REQUEST-URI functionality?  Or was that just me reading 
with rose-coloured glasses?


Just FYI, the very first cut is going to be a blog.r test.  But I 
think rebols would appreciate a little more.

Thanks again by the way.

Sorry people.  This was meant as a private message to Chris...but 
now it's out there and that's...ok.
(Could you hear the Stuart Smalley impression?)

I have a 'workable' solution, but it still has a little way to go.

I'm still not sure how to stop the above code blocking some existing 
filetypes.

Ok, try this:
http://www.ross-gill.com/QM/mod_qm.html

It's mod_static with the 404 response replaced.

I've updated the QM source also to be Cheyenne friendly (still needs 
CGI query/post support):
http://www.ross-gill.com/QM/qm.html

Then the only other change in Cheyenne is to handlers/CGI.r
Replace "soc/path-info: none" "soc/path-info: data/in/url"

Ok, before I dig in.  The mod-qm.r replaces mod-static.r?  Or do 
I just slip mod_qm.r into the mods/
dir?

Slip mod_qm.r into the mods/ dir, then replace 'static with 'qm in 
httpd.cfg

Cool.  Doing...

Note, this expects that qm.r is at your www root.

Yep.

My Cheyenne installation has been modified, but I've noticed crashes 
when adding a trailing slash to an existing file (eg. http://cheyenne/index.html/). 
 I think this happens out the box in mod-static -- when you do info? 
%/path/to/file.r/ and file.r exists, it will return info/type of 
'file but when you read %/path/to/file.r/ you get an error.  Is this 
correct? -- view 1.3.50.3.1 core 2.7.0

Also get the errors with the .exe as well.

Chris, sorry to not have chimed in before, I have a quite modified 
cheyenne that is in production for some time, only I have little 
time to help as I'm evely under pressur, somu guys came up with joomla 
in the company I work for, so it's either me coding from 0 or them 
assempling  jomla modules.. I could clean it up and send u a copy 
but this will be obsoleted by Dockimbel next version. it has rewrite 
rules and a slightly modified mysql protocol and a hihly modified 
mysql wrapper  to support stored procedures and getting data easly. 
like database: mysq://localhost/dbName db-open value: db-get 'table 
'column [{id=?} variable ] .

still our hope is having Dock merging somehow your QM with his cheyenne 
apps concept

should name the whole integration ROCKET !!  REBOL in Rockets 

or ROCK  ... REBOL rocks

;-)

Will, thanks for the offer.  For the moment, I'm trying to keep QM 
server agnostic -- mod-QM is just good enough for Cheyenne support 
(also fixes the above slash problem).  QM needs to mature some, and 
I'd rather that development were contained to one script.  But when 
it is more mature, I can see now that it would benefit from a seperate 
Cheyenne implementation that more efficiently takes advantage of 
Cheyenne's features.

'Rockets' -- I like that :)

There was a question a while back about a REBOL web log analyser. 
 TGD did one.

AnalyseIt!.  Needs a license from TGD though.  It states personal 
use, but kakked when

I tried it under 2.7.6.4.2.  Perhaps they sensed I was days away 
from a trial run.

http://www.tgd-consulting.de/Download.html#AnalyseIt

2.7.6.4.2 = 2.7.5.4.2