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
>
