Ugh. Don’t do that at all. Overriding Tcl’s [info] command (or any core
commands) by renaming and replacing is a path to doom.
The good news is that we no longer have to. As of 8.5.something, [info] is a
namespace ensemble command. I do think it’s worthwhile to make [info script]
do the right thing, so you have two ways of doing it.
Option 1
proc ::tcl::info::script {{filename “”}} {
return [::rivet::env SCRIPT_FILENAME]
}
This replaces Tcl’s call for the [info script] command with a proc of our own
making that just returns our script no matter what while maintaining the same
call structure for compatibility. But it overwrites a Tcl core function, even
if it is buried behind an ensemble.
Option 2
proc ::rivet::InfoScript {{filename “”}} {
return [::rivet::env SCRIPT_FILENAME]
}
set map [namespace ensemble configure ::info -map]
dict set map script ::rivet::InfoScript
namespace ensemble configure ::info -map $map
Option 2 obviously has a few more steps, but is probably more correct. Anyone
looking at the ensemble can immediately tell we’ve overridden the script
command. They can also still reach the original [info script] command by
calling ::tcl::info::script if they want. It actually does more than just tell
you the startup script. :)
Damon
On Jan 20, 2014, at 3:39 AM, Massimo Manghi <[email protected]> wrote:
> Hi
>
> I'm wondering if actually is worth keeping these lines of code in
> Rivet_SendContent
>
> Tcl_Obj *infoscript = Tcl_NewStringObj("info script ", -1);
> Tcl_IncrRefCount(infoscript);
> Tcl_AppendToObj(infoscript, r->filename, -1);
> Tcl_EvalObjEx(interp, infoscript, TCL_EVAL_DIRECT);
> Tcl_DecrRefCount(infoscript);
>
> the purpose of running this Tcl fragment is to coax 'info script' to
> return the full path to the current script. Notice that this code is
> unconditionally run on every request handled by mod_rivet.c. Not a big
> deal in terms of performance, but we could save some time at every
> request if we approach the problem in a different way (and in any case
> it's not a good design to have code computing something that could never
> be used when this same information can be obtained by other means and
> only on demand)
>
> My proposal is to rename Tcl's info command in Rivet:init (to a
> different namespace?) and provide our own 'info' command which will fall
> back to the default in every case except when the command call reads
> exactly 'info script'. In this case the string returned by
>
> [::rivet::env SCRIPT_FILENAME]
>
> would be returned or the same information could be fetched from
> request_rec by a new specific command (the presence of a specific
> environment variable is configuration dependent, I still have to
> understand whether SCRIPT_FILENAME is guaranteed to exist)
>
> --
> -- Massimo Manghi
>
> Dipartimento di Neuroscienze
> Unità di Biofisica e Fisica Medica
> via Volturno 39
> 43125 Parma
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
