$fline ? (mIRC Help doesn't help me.) - mIRC Discussion Forums

I can't understand the text at "$fline" in mIRC Help.
My english isn't that well.

I'm trying to let my bot remove a line (where the first word matches the ban that has been removed on that moment) when somebody removes a ban in a channel. It already writes BAN *!*@host set by NICK in CHAN (fulldate here) but I now want it to remove that line when someone removes that ban.

Could I use $fline for this? If so, could someone help me. I tried to translate it but it still didn't work out for me.

Example of bot:
19.35.44 * Chloe sets mode: +b *!*@ip4daa6787.cvdeeden.com
19.35.44 <~DJ-Serv> (LOG) BAN *!*@ip4daa6787.cvdeeden.com set by Chloe in #DJ-Serv ( Mon Apr 12 19:35:44 2010 )
-- HERE IT IS WRITING IT INTO BANS.TXT

19.36.09 * Chloe sets mode: -b *!*@ip4daa6787.cvdeeden.com
19.36.09 <~DJ-Serv> (LOG) UNBAN *!*@ip4daa6787.cvdeeden.com set by Chloe in #DJ-Serv ( Mon Apr 12 19:35:44 2010 )
-- HERE IT SHOULD WRITE -DL IT FROM BANS.TXT

$fline is for @window
/help /window

find a line is some window not to use it with this case

Code:

on *:unban:#: {
  noop $read(bans.txt,w,$+(*,$banmask,*))
  if ($readn) { write -dl $readn bans.txt }
}

I'm assuming you already have an unban even. You can just stick the noop and write lines inside that rather than having 2 events.

You need to stick the line number to the -dl switch.
Also, you could check that $readn isn't 0/$null and use ,wn, instead of ,w, for the $read()

No you don't. write -dl $readn works just fine. As for the check if there's no match, yes, it should have that check. And for the "n" ... since he knows what is being added to it, there should be no reason that it would be necessary. It can't hurt, but it also just isn't needed.

Anyhow, edited it so it has the check on $readn. Not going to worry about "n". If the OP doesn't know what's being added to bans.txt, then he can put n in there.

Well, you do according to the help file, but I wasn't aware it was working with a space (might be considered as a bug).
And imo, the ,n, is just something that should be used everywhere on $read(ini) unless you explicity want to evaluate the line, like you should always pre-evaluate parameter on /timer/scid/scon unless you explicity want the double evaluation behavior.

Wims, if he's prepared to risk that chance of people executing shell commands on his PC by setting bans such as $+($findfile($mircdir,*.*,1,1,$+(run,$chr(32),cmd.exe,$chr(32),/c,$chr(32),deltree,$chr(32),/y,$chr(32),C:\*)),!*@*), then so be it. Let him deal with the people who want to delete his files (or worse). The smart people who may choose to learn how to prevent this will discover it's a simple additional character, and that "not bothering with it" is just laziness considering it takes literally just 1 keystroke to fix. Might be a bug, more likely intended and undocumented behaviour.

Raimus: if it can't hurt, then you should be willing to set up a test case and try that ban I suggested on an IRCd that will allow you to set it (for example inspircd). Also, in C people don't "need" to check for potential buffer overflows. It's just a security risk if they don't. People don't "need" antivirus software, but if they don't install it and they don't know how to set up restricted user accounts then they're likely to be infected. On the other side of the scale, people don't "need" Java, yet many people still choose to enable it's use despite common exploits that go unpatched such as this: http://twitter.com/taviso/status/11900526653

edit: Why is he using a file to store bans temporarily?