Forum Discussion

adharkrader's avatar
adharkrader
Icon for Nimbostratus rankNimbostratus
Feb 09, 2016

How can I have [variables] evaluated in a string?

After many rounds of tweaking our redirector iRule, I'd like to make it so the folks thinking up "add this, add that" can add their own information on the redirect by modifying the redirect target string. Currently, I'm using regsub to replace [HTTP::host], [HTTP::uri], etc but then I have to add another regsub every time they want something different.

 

Is there a way to have the target string eval-ed and the [variables] resolved directly? I tried "eval {log local0. $redirect_target}" as a test but the [vars] in the string come through as [vars] instead of being resolved. Is there a way to get them resolved on-the-fly?

 

Thanks - Al

 

2 Replies

  • The curly brackets are interfering with your variable expansion.

    Try this:

     

    set tmp "log local0. $redirect_target"
    eval $tmp
    

     

  • Hi Adharkrader,

    TCL can substitute any [command] or $variables on the fly, by just using...

     

    log local0. "Var1 = $variable1 , Var2 = $variable2 , Request Host = [HTTP::host] , Request URI = [HTTP::uri]"
    

     

    The use of [eval] is just required if the substituted string have to spann multiple command options, or if the command itself isn't subtitution aware...

     

    set headers "\"Server\" \"MyWebserver\" \"X-Powered-By\" \"MyWebserver\""
    eval "HTTP::response 200 content \"Hello World\" noserver $headers"
    
    ... would result into...
    
    HTTP::response 200 content "Hello World" noserver "Server" "MyWebserver" "X-Powered-By" "MyWebserver"
    

     

    ... or ...

     

    eval "unset -nocomplain [info vars temp_*]"
    
    ... may result into...
    
    unset -nocomplain temp_1 temp_2 temp_3
    

     

    ... or ...

     

    eval "set myvar_[IP::client_addr] \"somevalue\""
    
    ... may result into...
    
    set myvar_192.168.0.1 "somevalue"
    

     

    Note: Keep an eye on your performance when using [eval]. Most of the [eval] usecases are not byte-code aware and do therefore have a very impressive overhead!

    Update: Added a third example showing a [command] that isn't substitution aware.

    Cheers, Kai