I am a little bit surprised, I could simplify a bit more. handleAAA.rvt
now looks like:
<html>
<head><title>Handler A</title>
</head>
<body>
<pre></pre>
<?
#puts "<pre>handlerA running in<b>[pwd]</b><pre>"
proc procB { } {
source include.tcl
set args {}
regsub "astring" "anotherstring" "globalvar_local" args
}
procB
?>
</body>
</html>
May be there is something more simple.
Best regards
Sven
Am 18.01.2012 22:32, schrieb Sven:
Hi Massimo,
I attached a "project" where I can reproduce it. Maybe there are some
other things that are important I did not mention yet (hopefully not).
There are some important things:
1) that quirky code for at least one rvt file: see AAA/handleAAA.rvt
in the attachment
2) the [pwd] in handleAAA.rvt seems to prevent the problem to occur!!!
So I comment it out.
3) the count of serving Apache instances/children shall be low enough:
'ServerLimit 1' was perfect for this purpose
Point 2) indicates that there is some issue with the TCL interpreter.
Isn't it?
Thank you
Sven
Am 18.01.2012 19:36, schrieb Massimo Manghi:
I tried to reproduce the problem tonight but unsuccessfully.
My scheme has some small difference in that the code is placed in .rvt
files. Both scripts in A/ and B/ source an include.tcl file
handlerA.rvt:
<html>
<head><title>Handler A</title>
</head>
<body>
<?
puts "<pre>handlerA running in<b>[pwd]</b><pre>"
source include.tcl
?>
</body>
</html>
include.tcl:
puts "A:[info script] -> [pwd]
(%s/A/B/ and you get the counterpart for directory B/)
The ouptut is consistent, so more info about the internal status of your
child processes is needed.
-- Massimo
On mer, 2012-01-18 at 13:49 +0100, Sven wrote:
Hi Massimo,
I tried your approach with success. I added
RivetServerConf BeforeScript "load_env reqenv; cd [file dirname
$reqenv(SCRIPT_FILENAME)]"
to our Rivet directives.
But I'm not quite sure if this the right place for the command. Because
for me it is the correction of a misbehaviour. But as long as it is not
clear who is guilty and if there is not introduced an unwanted
side-effect, this way sounds as a good solution.
Thanks and best regards
Sven
Am 18.01.2012 12:08, schrieb Massimo Manghi:
Hi Sven
I think a more practical approach could be to tell Rivet to
work starting from a specific directory at every request. It's
easy because Rivet has the BeforeScript directive for this sort
of things
RivetServerConf BeforeScript "cd<my-app-root-dir>"
you may change this command and cd into the filename dir by
elaborating it a bit. The filename variable is stored in one
of the environment variables (see 'load_env' command)
RivetServerConf BeforeScript "load_env reqenv"
RivetServerConf BeforeScript "cd [file dirname $reqenv(FILENAME)]"
Developing with Rivet I progressively moved everything
has to be done at each request into the BeforeScript. The more
I think of it the stronger I feel it's the consistent way to
work. Template scripts just 'fill the holes' in the template using
data prepared before the actual template is run.
Keep in mind that Rivet configuration directives concatenate
in a single script subsequent calls to the same directive
RivetServerConf BeforeScript "cd<my webspace>"
RivetServerConf BeforeScript "source myAppRequestProcessing.tcl"
it could be your solution if your scripts assume to work starting
from the a specific<my webspace> directory. This feature is helpful
also because you may have script generic enough to be deployed
in different places and let the configuration set up the
environment for them
-- Massimo
On mer, 2012-01-18 at 09:47 +0100, Sven wrote:
Hello Massimo,
I think I found a solution. Thank you for your hint about the
implicit
chdir.
In mod_rivet.c (after the chdir fore Apache ) I added some code to
chdir
also for the TCL interpreter:
//XXX: Dirty fix
Tcl_Obj *chdir = Tcl_NewStringObj("cd [file dirname ", -1);
Tcl_IncrRefCount(chdir);
Tcl_AppendToObj(chdir, r->filename, -1);
Tcl_AppendToObj(chdir, "]", -1);
Tcl_EvalObjEx(interp, chdir, TCL_EVAL_DIRECT);
Tcl_DecrRefCount(chdir);
I dont know if this robust and the most efficient way. But it
works for me.
In the end I don't know exactly why it is that way. The interpreter
somewhere holds a structure with the cwd, which may be out of sync
with
different subsequent requests. But it was still working correctly
in the
most cases. But why it doesn't work only if some very special
code is
executed ...
Best regards
Sven
<snipped>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
