AllProtection.tcl (Stable: v4.8 / Beta: v4.9b4)

[awyeah]

Sir_Fz needs autoupdater

here's one, updating once a day:

Code: Select all

proc autoupd {src url} {
	catch {set token [::http::geturl $url]}
	if ![info exists token] return
	if {[::http::ncode $token] == 200} {
		set file [open $src w]
		puts -nonewline $file [::http::data $token]
		close $file
		uplevel #0 {source $src}
	} else {
		putlog "update error: [::http::code $token]"
	}
	::http::cleanup $token
}

bind time - "22 02 % % %" {autoupd scripts/bar.tcl http://foo.com/bar.tcl;#}

This will once a day download a new copy of the same script, (script name file should be the same now) and overwrite the existing copy?

We would have to put a rehash at the end in the procedure to make it more effective.

[demond]

This will once a day download a new copy of the same script, (script name file should be the same now) and overwrite the existing copy?

yep; it's actualy a simplified variant of my update proc in spambuster, where I also check the version and overwrite/reload script only if newer

We would have to put a rehash at the end in the procedure to make it more effective.

there's no point of rehashing, you need to reload that particular script only, not all of your scripts

[Sir_Fz]

this is too much update!!!!
whenever I setup one version another one gets released!!
man this is frustrating..... u should fix all problem together and publish a better one.........................

I already configured the script 4 times...

That's why it's still a beta version, it may have alot of bugs. And my job is to release a newer version whenever I fix bugs. Just be patient and always use the most updated version until we find that the script has no any more bugs.

Sir_Fz needs autoupdater

lol, that would be a good idea but unfortunately I'm bad at these http stuff. How exactly does this work ? and how can we make it check for a newer version ? Also, the configuration will all be reset since we're sourcing the downloaded file so the user will have to edit it again which would be the same as downloading it by himself.

[^DooM^]

Maybe have all the configuration in a seperate script and just update the core procs?

[andrie]

i have done test ur script, i like it but still now i don't understand what is mean random drone ?
i have a little error from ur script "Tcl error [nosense:kick]: wrong # args: should be "nosense:ban nick uhost chan"
can u fixed that ?
thanks a lot cause i like this tcl

[demond]

lol, that would be a good idea but unfortunately I'm bad at these http stuff. How exactly does this work ? and how can we make it check for a newer version ? Also, the configuration will all be reset since we're sourcing the downloaded file so the user will have to edit it again which would be the same as downloading it by himself.

you can scan for a "set version" line through the downloaded via http file, and if it has newer numerical version id, write over the old one and reload it at [uplevel #0]

in my scripts, I never reset global variables that have already been set (if ![info exists var] {set var something}), and warn the user not to edit the script itself but to configure what needs to be configured in their config file and then source the script; this way when the script is reloaded, it won't mess up current execution context - it will merely update procs code

of course, autoupdating should be off by default, or else some people will think that you are in the business of cracking shell accounts

[Sir_Fz]

i have done test ur script, i like it but still now i don't understand what is mean random drone ?
i have a little error from ur script "Tcl error [nosense:kick]: wrong # args: should be "nosense:ban nick uhost chan"
can u fixed that ?
thanks a lot cause i like this tcl

Random drones are users who join with random nicks or idents, and the proc nosense:nick follows a certain algorythm to detect these nicks as random, that's all. As for the error you reported, well I don't think it should give you such an error unless you've changed something in the script. Please type ".set errorInfo" in your partyline and show the result here.

you can scan for a "set version" line through the downloaded via http file, and if it has newer numerical version id, write over the old one and reload it at [uplevel #0]

in my scripts, I never reset global variables that have already been set (if ![info exists var] {set var something}), and warn the user not to edit the script itself but to configure what needs to be configured in their config file and then source the script; this way when the script is reloaded, it won't mess up current execution context - it will merely update procs code

Well I was talking about the variables that are set by the user like channels, type of punishments, kick reason...etc all will be needed to be reconfigured after sourcing the new file. ^DooM^'s idea was what I was thinking of too, but sometimes the configurations are needed to be upgraded too.

[demond]

Well I was talking about the variables that are set by the user like channels, type of punishments, kick reason...etc all will be needed to be reconfigured after sourcing the new file. ^DooM^'s idea was what I was thinking of too, but sometimes the configurations are needed to be upgraded too.

au contraire

in user's config:

Code: Select all

set sirfz_chan #foobar
set sirfz_type 3
source sirfz.tcl

in sirfz.tcl:

Code: Select all

if ![info exists sirfz_chan] {set sirfz_chan #default}
if ![info exists sirfz_type] {set sirfz_type 1}

when sirfz.tcl is reloaded (re-sourced), sirfz_chan and sirfz_type are preserved; you can even force the user to have dedicated sirfz.conf file - and your global vars will be preserved even after rehash (see my script spambuster.tcl for details)

[Sir_Fz]

Yeah, got that... but that means I have to add alot of info exists into the script

[^DooM^]

Once its done it shouldn't really need to be updated that often its only in beta stage its updated a lot

[Sir_Fz]

Once its done it shouldn't really need to be updated that often its only in beta stage its updated a lot

I agree, and it seems that the current version is pretty stable (no bugs so far). I have a new version with some improvements, but I want to wait a bit more before releasing any new version (wait for bugs, if any), let the reports get stacked a little bit

[^DooM^]

Dude, put a link to your script in your signature Cause I keep having to look back to find the url. Cheers Plus its good advertising

[Alchera]

Dude, put a link to your script in your signature Cause I keep having to look back to find the url. Cheers Plus its good advertising

Goodie.... I got lost scrolling back... LOL

[sKy]

My only suggestion:
If there are other scirpts which provides publik commands (!help or whatever), the bind pub will not trigger your bind pubm against channel/repeatingflood.
Maybe you can find a way to let each bind pub trigger you bind pubm too?

Anyway, really great script. You have done a good work.

[Alchera]

I don't know, but I am a firm believer in the KISS (Keep It Simple Stupid) principle and the drone code I personally consider too long and convoluted.

I am guessing the aim is to detect and ban consonant nicks. If so, there's 8 lines of code whereas the following will do the same job:

Code: Select all

if {[regexp -nocase {^[^aeiou_^-`]{5,}$} $nick]} {
      ...
}

I also think looking at nick lengths greater than 5 more appropriate as there is a 100% chance of not punishing an innocent user also, numerical idents should be ignored as a lot of IRC users (that are definitely not flood bots) use them.

With the above scenerio you'd probably 'hit' one, maybe two, innocent users per 24 hr period.