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
Am 16.01.2012 21:24, schrieb Massimo Manghi:
On lun, 2012-01-16 at 17:01 +0100, Sven wrote:
Hi Massimo,
yes, you are right it, we are upgrading from an ooold 'mod_dtcl'
application to rivet. :-)
We registered ttml also as rivet type:
AddType application/x-httpd-rivet .ttml
AddType application/x-httpd-rivet .rvt
So nothing changes by changing the name.
BTW: Is there another difference to become/being a rvt file?
No, I don't think so. I recalled David's words about mod_dtcl and
mod_rivet where he said that compatibility wasn't a concern and could be
abandoned any time.
The code is already executed in the right directory. So 'puts [pwd]'
gives the correct (intended) directory.
But your proposal to explicitly determine the path helps, e.g. for
handleBBB.ttml:
<?
source [file join [info dirname [info script]] include.tcl]
?>
But what is the reason for failing with the relative pathname? The TCL
version, Rivet? I assume both - a little bit each. I would prefer to
know why the code does not work as expected.
I observed also some other "oddities". (But this may also come from a
wrong TCL understanding. May be I come later back with these.)
One of the actions needed for Apache 2.x was to implicitly chdir into
the directory where the script referenced in the URL is located. It's
done in mod_rivet.c at line 1793 by calling
Rivet_chdir_file(r->filename)
A comment also suggests this call was introduced to comply with the
Apache 2.x webserver.
r->filename is the path to the script referenced in the URL,
Rivet_chdir_file extracts the directory name and goes into it (the code
was taken from mod_ruby and probably suboptimal). In principle this
information could change at every request, so I don't understand why
child processes are retaining this status from request to subsequent
request. Is there a bug hidden somewhere?
BTW: Unfortunately to upgrade to 8.4 is no option in the moment. The
decision is already done. :-(
Best regards
Sven
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
