@aDevil & SladeKraven:
Since many people read these posts, and we're trying to help people by giving them good solutions, it should be noted that both your solutions are vulnerable to exploits.
To make it clear: parameters passed to scid/scon are evaluted
twice which is potentially very dangerous if you do not take this into consideration.
- What you should do is either:
- Do as Kelder suggested. First set the connection to the one that you want, and then execute the command:
scid <cid>
command
optional scid -r
This is the same as doing: scid <cid> | command | scid -r - Put the parameters in a variable, and pass that escaped variable to scon/scid, so that with the first evaluation, the var is evaluated to the varname, and with the second evaluation, the varname is evaluated to its contents, being the parameters.
var %params = $1-
scid <cid> msg #channel % $+ params
An innocent example which shows the double evaluation is when people want to relay messages on a channel from one network to a channel on another network.
When doing "scid <cid> msg #channel $1-" what happens?- First evaluation: parameters passed to a command called from a script or from the command line with double // are evaluated, so the $1- is evaluated to the message. Let's say this message was "$me and $findfile(c:\,*,0) are good friends".
- Second evaluation, the connection has been set to the specified cid, and now the parameters are evaluated once more because they've reached the target connection. What happens? $me and $findfile evaluate, resulting in the sending to the other channel of: "FiberOPtics and 27614 are good friends".
That is not what we wanted to relay, we wanted to relay the actual $me and $findfile, though because of this double evaluation we got the other results.
As you can see this is a pretty harmless example, mainly because I wouldn't want to give people ideas. Beware that I could delete ones entire harddrive with the kind of code you've given them, simply by saying the right words.
Greets