Table of Contents

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:

  1. At the input prompt, when you want to use a variable value
  2. When you have stored trusted code, in a variable and you want to run it
  3. 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:

  1. To double-expand a variable
  2. 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 loaded. 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 xevaling a command that changes the current window or server will appear to have no effect.