no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+======Synopsis:======
+[[xeval]] //[see flags below]// //<block>//
+======Description:======
+The [[xeval]] command runs the //<block>// of code after it has gone through
+alias expansion again.
+**EXTREME CAUTION: THE CARELESS USE OF THIS COMMAND IS THE SOURCE OF AN
+INJECTION ATTACK.**  This can't be stressed strongly enough.
+=====Safe uses:=====
+  - At the input prompt, when you want to use a variable value
+  - When you have stored trusted code, in a variable and you want to run it
+  - When you have surrounded //<block>// in curly braces ("{" and "}")
+**IT IS NEVER A SAFE USE OF XEVAL TO EXPAND A VARIABLE TWICE.**
+This can't be stressed strongly enough.
+====At the input line====
+Let's say you have a variable whose value you want to pass to a command.
+Ordinarily you can't do that because the input line is handled literally
+and your $'s don't expand.  You can use [[xeval]] to for $'s to expand
+at the input line.
+===Example of expanding variables at the input line:===
+  /assign myvar isn't this neat?
+  /xeval say This string contains a variable which will expand -> $myvar
+====When you have code stored in a variable====
+According to the language syntax, after a statement is removed from a block,
+it is subject to $ expansion and then executed.  This means that characters
+that are part of the syntax (such as ";") are treated literally and do not
+act as statement separators.
+====Example of converting strings into code:====
+  @ mycode = 'echo hi there!;join #epic'
+  xeval -- $mycode
+====When you have surrounded block with curly braces====
+When dealing with untrusted strings, you want to make sure they don't get
+parsed as statements.  The effect of curly braces is the reverse of [[xeval]]
+so if you wrap //<block>// in curly braces, untrusted strings cannot be
+treated as code:
+===Example of using curly braces to prevent untrusted strings:===
+  on msg * {xeval -w MsgWin {echo $*}}
+=====Unsafe uses:=====
+  - To double-expand a variable
+  - When used with any string you received anywhere but the user
+====Examples of unsafe uses:====
+===Double expanding a variable===
+   @ foo = '$bar'
+   @ bar = 'testing'
+   xeval echo $foo
+That doesn't look so bad, does it?  But what happens if someone does:
+   @ bar = 'testing;exec rm -rf ~'
+That leads to:
+   xeval echo testing;exec rm -rf ~
+If you want to double expand a variable or string, use the %%**%% operator
+   echo ${**foo}
+====When used on any unsafe string====
+An unsafe string is any string received from anywhere except the user at
+the input line or from the file that the user [[load]]ed.  Particularly,
+any string received from irc.
+   on msg * {xeval -w MsgWin xecho -b Msg from $*}
+This is an injection attack because if msg you "testing;exec rm -rf ~"
+then the above command becomes:
+   xeval -w MsgWin echo testing;exec rm -rf ~
+Whenever you are dealing with an untrusted string, always wrap the command
+in curly braces when using [[xeval]].  The above code could be safely written
+as:
+   on msg * {xeval -w MsgWin {xecho -b Msg from $*}}
+======Options:======
+| -server <server desc> | Change from_server to the given server. |
+| -window <window desc> | Change current_window to the given window. |
+| -noisy                | Reverse the effect of %%^%% on statements |
+| --                    | (Two dashes) End option processing.  The //block// begins immediately after this option. |
+It's possible to set //-server// and //-window// independantly of each
+other, which allows you to do crazy things like setting the current window
+to a window whose server is not the same as //-server//.  Best practice is
+to always set them both, and to ensure that the //-server// is set to the
+server that //-window// belongs to.
+The original server and window settings are restored before returning, so
+[[xeval]]ing a command that changes the current window or server will appear
+to have no effect.