|
||||||||||||
It was about time the X-Chat perl scripting documentation has finally updated. Well over three years has passed since the last incarnation of this page was updated, and many things have changed. Much of the old documentation has been used, with many updates and changes. I have made a few perl scripts on my own and have untaken this project as a chance to refresh my scripting skills and update myself (and everyone else) of the many changes that have been made over the past few years.
The purpose of this page is to give people some quick documentation of the functionality available within X-Chat to code scripts using Perl. There are many scripts already available, but they don't always work exactly the way you want. This document, with some other references, should help you create your own scripts.
If you're going to do any perl scripting with X-Chat at all, you will need to
know perl. :) It also won't hurt to have had experience writing
tcl for eggdrops or ircII scripts. Otherwise you're going to have to be very
careful to avoid creating conditions which could flood you offline or do other
not-so-optimal things. ;) Thankfully, it shouldn't take most intelligent
people more than a week (month on the outside) enough perl to do some nice
things in it.
|
|
||
Before starting to script, you should probably do some reading. The
following is a table of references that will definitely aid when
creating scripts. It is highly recommended that you save a copy of
these documents locally, as you will be looking at them quite
often!
|
||
| Perl was the first language used for creating scripts in X-Chat, making it the most popular! For those of you who are used to ircII's scripting language, or using eggdrop with tcl, the only thing you will really miss is that the regexps are a lot different, but they're more powerful in perl. For those of you saddled with weak languages for too long, regexps means REGular EXPressions, or "pattern matching wildcard usage" in layman's terms. | ||
| There are currently three basic ways to make things call the subroutines you write for X-Chat. They are message handlers, command handlers, and timeout handlers. Message handlers trigger on messages sent from the IRC server to your client, command handlers are triggered by "/ commands" typed in by the user at the keyboard, and timeout handlers are triggered by GTK+. | ||
| These are very important. Every time you set up a handler, it takes precedent over the built-in functions and commands of X-Chat. That is, whatever thing which triggered your subroutine will go to your code before it goes to X-Chat to be dealt with. In this way you can replace almost every built-in function that the client has with your own routines. The thing to remember is that if your code exits by hitting the end of your subroutine, or by a plain 'return' statement, processing of the event will go on to whatever other things have set up hooks for the event, and then (provided nothing else exits with a return value of 1) to X-Chat itself. There is only one problem with this, and that is that you cannot really control what order the custom routines get called. Normally they will execute in order of which ones were installed first, but a single script has no real way of knowing this. Beware. | ||
If you've never heard of @_ before, then go read a perl
book! When a message handler triggers, the raw line from the IRC
server is passed to the subroutine you specify in @_.
When a command handler is triggered, only the arguments are passed to
the routine through @_ and they are not broken into a
list, but left as one long string. You'll have to parse those
yourself with split. (You can use s/\s+/ /g to collapse
the blank space to single space first.) When a timer handler is
triggered, nothing is passed in @_. Be especially
careful when setting up message handlers for mode changes, since the
modes are not broken up into individual events like they are with
eggdrop. The upside of this is that X-Chat has no mode hooks of it's
own, so you don't have to worry about it too much.
|
||
You never know which scripts may use the same name for a variable,
especially if you are using scripts created by many different people.
If two scripts use the same variable name, it is very likely that
the scripts will walk over each other and clobber data. The reason
for this is that perl scripts, by default, share the same environment
within X-Chat. By turning a script into a perl package,
this separates the namespaces and avoids the clobbering issue. Below
is a skeleton of an X-Chat perl script in a package:
package Sky;
|
||
There are some really nice things about coding for X-Chat, and the
biggest one is that it's fairly good about determining the proper
context for things. If a server sends something that triggers a
message handler, then you can be sure that unless you specify
otherwise, that your IRC::print() or
IRC::command() function call will go back to that server
and that server alone. If you really really need to know what the
current context is, use the IRC::get_info() function as
detailed below.
|
||
|
|||||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||||||||||||||||||||||||||
|
|||||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||||
|
|||||||||||||||
|
|||||||||||||||
|
|||||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||||
|
|||||||||||||
|
|||||||||||||||
|
|||||||||||||||