[ramsan] says: A typical problem when trying to define the command script is when you want
to mix variables that need to be substituted now and others that need to be
substituted later. ([KBK] points out [[2004-06-05]] that there's a detailed
discussion of this problem, with solutions, under [Quoting Hell] - and that the
examples on this page are, in his opinion, examples of poor practice.) 

Some examples:

   * If variables need to be substituted now:

        button $b -command [list $b configure -background red]
        button $b -command "[list $b configure -background red] ; [list puts \
           "pressed $b"]"

   * If variables need to be substituted later:

       button $b -command {
           set aa $some_global_var
       }

   * If there is a mixture:

       button $b -command [list some_function $b] ;# recommended solution

   * If you really want to avoid to create new functions and want an inline solution, there are some possibilities:

       button $b -command [string map [list %W [list $b]] {
           set aa $some_global_var
           %W configure -background red
       }]

or:

      set cmd {
           set aa $some_global_var
           %W configure -background red
      }
      button $b -command [string map [list %W [list $b]] $cmd]

it is the same but different disposition.

There are other solutions that become easily complex and error prone:

       button $b -command "
           set aa \$some_global_var
          $b configure -background red
       "

[DGP]  Actually, your last three examples are all buggy.
They will all fail if the value of ''$b'' contains
white space.  Avoid Quoting Hell.  Stick with the
helper proc.

[ramsan] The two examples with '''string map''' should be OK now.

[RJM] One can also use the [subst] command to properly create a command string. Of course, the subst command does not handle variables with white spaces correctly as [list] does, but this can be corrected by using "-quoting around the variable. This is possible since the WHOLE command is not quoted with "s. Contrary to [list], subst allows multiple line command strings without backslashing, and the -nocommand option helps leaving nested commands untouched (which [list] does not do). Regarding string map: I personally find this ugly.

The example from above is correspondingly modified. I also added a nested command here, which may be typical. For this purpose I wrote [bind] instead of button.

       bind $b <3> [subst -nocommand {
           set aa \$some_global_var
           focus [winfo parent %W]
          "$b" configure -background red
       }]
----
[KBK] much prefers avoiding [Quoting Hell] with an auxiliary proc:
   proc handle_b3 { w } {
       set ::aa $::some_global_var; # I reproduce your example, but I'd
                                    # use namespace-specific vars here
       focus [winfo parent $w]
       $w configure -background red
   }
   bind $b <3> [list [namespace code handle_b3] %W]
If you're planning to reuse a family of bindings, it's also wise to place them on
a [bindtag] other than the widget name.  That way, when you create a widget that
uses the bindings, you need just the one line of code that adds the tag to the
widget's bindtags. All of these solutions with [subst], [string map], and the
like appear horribly unmaintainable.  Moreover, as [DGP] points out,
''most of the examples on this page have bugs.''

----
[[
[Category Example]
]]