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
> 
> 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
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Reply via email to