The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.


Bot::BasicBot - simple irc bot baseclass


  # with all defaults
  Bot::BasicBot->new( channels => ["#bottest"] )->run();

  # with all known options
  Bot::BasicBot->new( channels => ["#bottest"],

                      server => "",
                      port   => "6667",

                      nick      => "basicbot",
                      alt_nicks => ["bbot", "simplebot"],
                      username  => "bot",
                      name      => "Yet Another Bot",

                      ignore_list => [qw(dipsy dadadodo laotse)],

                      store =>
                      Bot::Store::Simple->new(filename => "store.file"),

                      log   =>
                      Bot::Log::Simple->new(filename => "log.file"),


Basic bot system designed to make it easy to do simple bots, optionally forking longer processes (like searches) concurrently in the background.

Main Methods


Creates a new instance of the class. Name value pairs may be passed which will have the same effect as calling the method of that name with the value supplied.


Runs the bot. Hands the control over to the POE core.


This is the main method that you'll want to override in your subclass - it's the one called by default whenever someone says anything that we can hear, either in a public channel or to us in private that we shouldn't ignore.

You'll be passed a reference to a hash that contains the arguments described below. Feel free to alter the values of this hash - it won't be used later on.


Who said it (the nick that said it)


The channel in which they said it. Has special value "msg" if it was in a message. Actually, as you can send a message to many channels at once in the IRC spec, but no-one actually does this so it's just the first one in the list


The body of the message (i.e. the actual text)


The text that indicates how we were addressed. Contains the string "msg" for private messages, otherwise contains the string off the text that was stripped off the front of the message if we were addressed, e.g. "Nick: ". Obviously this can be simply checked for truth if you just want to know if you were addressed or not.

You should return what you want to say. This can either be a simple string (which will be sent back to whoever was talking to you as a message or in public depending on how they were talking) or a hashref that contains values that are compatible with say (just changing the body and returning the structure you were passed works very well.)

Returning undef will cause nothing to be said.


This is a secondary method that you may wish to override. In its default configuration, it will simply pass anything emoted on channel through to the said handler.

emoted receives the same data hash as said.


This method allows you to fork arbitrary background processes. They will run concurrently with the main bot, returning their output to a handler routine. You should call forkit in response to specific events in your said routine, particularly for longer running processes like searches, which will block the bot from receiving or sending on channel whilst they take place if you don't fork them.

forkit takes the following arguments:


A coderef to the routine which you want to run. Bear in mind that the routine doesn't automatically get the text of the query - you'll need to pass it in arguments (see below) if you want to use it at all.

Apart from that, your run routine just needs to print its output to STDOUT, and it will be passed on to your designated handler.


Optional. A method name within your current package which we can return the routine's data to. Defaults to the built-in method say_fork_return (which simply sends data to channel).


Optional. Use this to pass on the body of the incoming message that triggered you to fork this process. Useful for interactive proceses such as searches, so that you can act on specific terms in the user's instructions.


The nick of who you want any response to reach (optional inside a channel.)


Where you want to say it to them in. This may be the special channel "msg" if you want to speak to them directly


Optional. Setting this to a true value causes the person to be addressed (i.e. to have "Nick: " prepended to the front of returned message text if the response is going to a public forum.


Optional. This should be an anonymous array of values, which will be passed to your run routine. Bear in mind that this is not intelligent - it will blindly spew arguments at run in the order that you specify them, and it is the responsibility of your run routine to pick them up and make sense of them.


Say something to someone. You should pass the following arguments:


The nick of who you are saying this to (optional inside a channel.)


Where you want to say it to them in. This may be the special channel "msg" if you want to speak to them directly


The body of the message. I.e. what you want to say.


Optional. Setting this to a true value causes the person to be addressed (i.e. to have "Nick: " prepended to the front of the message text if this message is going to a pulbic forum.

say automatically calls c<cannonical_nick> to resolve nicks to the current nick for someone, so even if they've changed their nick when you say something it should (assuming POE gets round to sending it in time) be sent to the right person.

You can also make non-OO calls to say, which will be interpreted as coming from a process spawned by forkit. The routine will serialise any data it is sent, and throw it to STDOUT, where POE::Wheel::Run can pass it on to a handler.


emote will return data to channel, but emoted (as if you'd said "/me writes a spiffy new bot" in most clients). It takes the same arguments as say, listed above.


fork_said is really an internal method, the default handler for output from a process forked by forkit. It actually takes its input from a non-object call to say, thaws the data, picks up arguments, and throws them back at say again. Don't ask - this is the way POE::Wheel::Run works, and this jiggery-pokery gives us a nice object interface.


This is the other method that you should override. This is the text that the bot will respond to if someone simply says help to it. This should be considered a special case which you should not attempt to process yourself. Saying help to a bot should have no side effects whatsoever apart from returning this text.


An optional method to override, gets called after we have connected to the server

Access Methods

Get or set methods. Changing most of these values when connected won't cause sideffects. e.g. changing the server will not cause a disconnect and a reconnect to another server.

Attributes that accept multiple values always return lists and either accept an arrayref or a complete list as an argument.


The server we're going to connect to. Defaults to "".


The port we're going to use. Defaults to "6667"


The nick we're going to use. Defaults to five random letters and numbers followed by the word "bot"


Alternate nicks that this bot will be known by. These are not nicks that the bot will try if it's main nick is taken, but rather other nicks that the bot will recognise if it is addressed in a public channel as the nick. This is useful for bots that are replacements for other bots...e.g, your bot can answer to the name "infobot: " even though it isn't really.


The username we'll claim to have at our ip/domain. By default this will be the same as our nick.


The name that the bot will identify itself as. Defaults to "$nick bot" where $nick is the nick that the bot uses.


The channels we're going to connect to.


The quit message. Defaults to "Bye".


The list of irc nicks to ignore public messages from (normally other bots.) Useful for stopping bot cascades.


These are the POE states that we register in order to listen for IRC events.


Called when we start. Used to fire a "connect to irc server event"


Called in order to try aggressive reconnecting. A little overhead here, because the bot just blindly tests whether it's connected every 20 seconds, but it means that server drops will be picked up, and the bot will be far stabler during netsplits and random sever barfs.


Called when we're stopping. Shutdown the bot correctly.


Called when we connect to the irc server. This is used to tell the irc server that we'd quite like to join the channels.

We also ignore ourselves. We don't want to hear what we have to say.


Called if we are disconnected from the server. Logs the error and then dies.


Called if there is an irc server error. Logs the error and then dies.


Called if we get kicked. If we're kicked then it's best to do nothing. Bots are normally called in wrapper that restarts them if we die, which may end us up in a busy loop. Anyway, if we're not wanted, the best thing to do would be to hang around off channel.


Called if someone joins. Used for nick tracking


Called if someone changes nick. Used for nick tracking


Called if we recieve a private or public message. This formats it into a nicer format and calls 'said'


Called if someone "emotes" on channel, rather than directly saying something. Currently passes the emote striaght to irc_said_state which deals with it as if it was a spoken phrase.


Called by irc_said_state and irc_emoted_state in order to format channel input into a more copable-with format.


Called whenever a process forked by POE::Wheel::Run (in forkit) terminates, and allows us to delete the object and associated data from memory.


Called if a process forked by POE::Wheel::Run (in forkit) hits an error condition for any reason. Does nothing, but can be overloaded in derived classes to be more useful

Other States

Other States

Bot::BasicBot implements AUTOLOAD for sending arbitrary states to the underlying POE::Component::IRC compoment. So for a $bot object, sending


is equivalent to

    $poe_kernel->post(BASICBOT_ALIAS, "foo", "bar");



Logs the message. Calls the logging module if one was initilised, otherwise simple prints the message to STDERR.

get($key) or get($storename, $key)

Gets the key from the store. Uses the store module loaded if initilised, otherwise uses an internal hash. By default uses the "main" store.

set($key, $value) or set($storename, $key, $value)

Sets the key in the store. Uses the store module loaded if initilised, otherwise uses an internal hash.


Return true if this nick should be ignored. Ignores anything in the ignore list or with a nick ending in "bot".


Takes a nick and hostname (of the form "nick!hostname") and returns just the nick


Simon Batistoni <>

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.


The initial version of Bot::BasicBot was written by Mark Fowler, and many thanks are due to him.

Nice code for dealing with emotes thanks to Jo Walsh.

Various patches from Tom Insam, including much improved rejoining, AUTOLOAD stuff, better interactive help, and a few API tidies.


Bot::BasicBot is based on POE, and really needs the latest version as of writing (0.22), since POE::Wheel::Run (used for forking) is still under development, and the interface recently changed. With earlier versions of POE, forking will not work, and the makefile process will carp if you have < 0.22. Sorry.

You also need POE::Component::IRC.


During the make, make test make install process, POE will moan about its kernel not being run. I'll try and gag it in future releases, but hey, release early, release often, and it's not a fatal error. It just looks untidy.

Don't call your bot "0".

Nick tracking blatantly doesn't work yet. In Progress.

fork_error_state handlers sometimes seem to cause the bot to segfault. I'm not yet sure if this is a POE::Wheel::Run problem, or a problem in our implementation.


Proper tests need to be written. I'm envisaging a test suite that will connect a Bot::BasicBot instance to a test channel on a server, and then connect another user who can interface with the bot and check its responses. I have a basic stub for this, but as of writing, nothing more :( It will be done asap, I promise, and will then be forked to provide a more comprehensive test suite for building bots that can, for example, duplicate the functionality of an infobot.

Mark Fowler has done some work on making BasicBot work with other messaging systems, in particular Jabber. It looks like this will be combined with Bot::BasicBot, and become a new module, Bot::Framework. Bot::BasicBot is, after all, supposed to be basic :)




Possibly Infobot, at

2 POD Errors

The following errors were encountered while parsing the POD:

Around line 468:

'=item' outside of any '=over'

Around line 616:

You forgot a '=back' before '=head2'