How about changing that block of code to be something like:
if {[info commands ::rivet::exit] != ""} { rename ::exit ::Rivet::tclcore_exit proc ::exit {args} { if {$args != "" && [string is integer $args]} { eval ::rivet::exit {*}$args } else { eval ::rivet::exit 0 } } } On Sat, Sep 2, 2017 at 11:48 AM, Jeff Lawson <j...@bovine.net> wrote: > That's understandable, but we find it useful to be able to write > command-line scripts (outside of mod_rivet) that use packages included with > Rivet. It would be nice if the replacement of the global ::exit were only > done when the package is being loaded under the context of mod_rivet. > > Also, it looks like "proc ::exit {code}" breaks the normal allowance for > exit having an optional argument. > > > > On Sat, Sep 2, 2017 at 10:35 AM, Massimo Manghi <man...@biol.unipr.it> > wrote: > >> >> On 09/01/2017 09:51 PM, Jeff Lawson wrote: >> >>> The following Tcl script seems to fail under Rivet 2.3.4 with: >>> >>> invalid command name "::rivet::exit" >>> >>> #!/usr/local/bin/tclsh >>> package require Rivet >>> exit 0 >>> >>> >>> I don't think we had problems with this under Rivet 2.2, is this a >>> regression? >>> >>> >> If I understand what you did you required package Rivet thus running >> init.tcl which shadows the core exit command with rivet's ::rivet::exit >> >> rename ::exit ::Rivet::tclcore_exit >> proc ::exit {code} { >> >> if {[string is integer $code]} { >> eval ::rivet::exit $code >> } else { >> eval ::rivet::exit 0 >> } >> >> } >> >> But ::rivet::exit is defined in rivetCore.c. The bottom line is: you have >> to run the script from mod_rivet, with the current code you can't setup the >> interpreter for running this command and other commands in rivetCore.c from >> a standalone Tcl script. >> >> Sometime ago I considered to make rivetCore.c a package in its own right, >> much like the rivet library or the rivet parser. The majority of the >> commands in it make sense only if a valid request_rec pointer is passed, >> thus I couldn't see a clear advantage for having something like a >> rivet::core package except for the modular design. You can end up having an >> external package and perhaps test different rivet::core versions without >> rebuilding. But we have never been in a situation where a dozen of >> programmers are contending the development by working in parallel on >> different mod_rivet components ;-) >> >> -- Massimo >> > >