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

Reply via email to