Dancer uses a flexible nickname resolver. Alternative nicknames are userdefined.
gives 'robot'. If this nick is in use it tries 'robot_', then 'robotA', 'robot2', 'robottwo', and then starts again from the beginning.
gives 'robot', 'robert', 'rybt', and 'rabbit'.
As of version 4.16 Dancer supports dynamic reloading of configuration files trigged via SIGHUP. This lets bot maintainers distribute user and config files between bots independently of IRC, and it even lets you write any kind of user interface you want to edit the files, as long as you send Dancer a SIGHUP to let it know when to reload.
Reloading is not a critical event, so it may take place up to 5 seconds after the SIGHUP is recieved.
If Dancer is installed in ~/bot on your system, you may send it a SIGHUP as such:
$ kill -HUP `cat ~/bot/.pid`
or, if your platform supports it, by executing
$ killall -HUP dancer
If you wish to avail of this feature, you need to consider security on your systems. The feature itself is not a security risk, however the practises used to update your Dancer config may become one. We will try to identify as many possible, so you can make an educated decision on if or how to use this. You should always adhere to your system's security policy.
There are two parts to using this feature in a useful manner. One is a transport mechanism for the configuration files, and the other is the actual sending of SIGHUP. In addition, all the Dancers on your channel may be run by one person with multiple accounts, or they may be run by multiple people who may not trust each other 100%. We can only provide you with guidelines and examples. You must do the rest.
In a push model, the transport can be done via ftp upload, remote copy (rcp), secure copy (scp) to name a few. In a pull model, the transport can be via the same ways, and via a HTTP download. If you want this process to be automated, it must forego password authentication and similar.
As described above, you may send a SIGHUP signal using the kill command. This can be done, either from a cron job, or from some form of remote execution like remote shell (rsh) or secure shell (ssh). We recommend the latter.
An ssh RSA key with no password and restricted access is often a good choice for these kind of tasks, but you may prefer a different solution.