Looking at the code...
Urk. Looks like there's one insurmountable problem. Since the function works dynamically on incoming requests, it can
only recognize exact IPs, meaning /32. Normally you would never do this in htaccess except in truly exceptional cases. (I could make something up, but there's no point: an exception means, by defintion, something exceptional.)
That means you can use it in the short term, but you will need to go into your htaccess periodically, sort it by lines, and change all those individual aaa.bbb.ccc.ddd blocks into whole ranges like aaa.bbb.ccc/19 or aaa.bbb/14. Your machine can't do that; it involves manual lookups. But if you count on your fingers* you will see that 2^32 possible blocks-- considering only IPv4 --can quickly balloon into a seriously unworkable htaccess.
You can compromise by using only the first three pieces: if the request comes from aa.bb.cc.dd write the code to look at aa.bb.cc alone. The chances of different behaviors coming from within the same /24 are generally too small to bother with.
If you meet an exception, send 'em my way: they're probably in my target demographic. There's basically just one line to change. Maybe a few surrounding lines to get the text added in the right place. (And, incidentally, the idea of letting anything other than me-the-human-user edit my htaccess makes my skin crawl. But obviously it does work.)
Current version using mod_setenvif
$content = "SetEnvIf Remote_Addr ^" . $bad_bot_ip . "$ getout\r\n";
(Do you have to say \r\n to make it work on all servers? Or is that just so you can read the file with your eyeballs on your local Windows machine? I just say \n.)
If you're doing this in mod_rewrite, the overall structure would be
RewriteCond %{REMOTE_HOST} ^bad-IP-here$
RewriteRule .* - [F]
RewriteCond %{REMOTE_HOST} ^other-IP-here$
RewriteRule .* - [F]
... except that in real life you would never do it like that. It would be either
RewriteCond %{REMOTE_HOST} ^bad-IP-here$ [OR]
RewriteCond %{REMOTE_HOST} ^other-IP-here$ [OR]
RewriteCond %{REMOTE_HOST} ^third-IP-here$
RewriteRule .* - [F]
or
RewriteCond %{REMOTE_HOST} ^(bad-IP-here|other-IP-here|third-IP-here)$
RewriteRule .* - [F]
At this point you get into php details. It is obviously easiest to code a fresh rule for each bad robot. But if they start piling up it will slow your site to a crawl. So more likely you'd want to pre-seed your htaccess with the starter rule, and then write the php to insert lines as needed. Most straightforward is probably to add lines like
RewriteCond %{REMOTE_HOST} ^fourth-bad-IP-here$ [OR]
before the existing
RewriteCond %{REMOTE_HOST} ^bad-IP-here$ [OR]
That was in mod_rewrite. If you go with mod_authz-whatever (there are dozens of them and nobody can possibly be expected to remember the exact name!) then it becomes a simpler
Deny from bad-IP-here
You definitely don't need the robots.txt exemption in its original form; in fact your htaccess should already have a
<Files "robots.txt">
et cetera. Anything inside a <Files> or <FilesMatch> overrides other rules if there's a conflict.
* Cursory business with calculator tells me you could come out with a mod_authz section running into the gigabytes :)
