Placing those values inside double quotes (") would fix it..
But as I guess that's not an option we have to fix the parser..for php.ini, ! is special..

Maybe the best way to fix this is to have separate scanner/parser for browscap.ini..

Oh, and the reason I cannot delimit certain values with double-quotes is because browscap.dll does not strip out the quotes. If I entered "Yahoo! Slurp" as a browser name then everyone using browscap.ini on IIS would see "Yahoo! Slurp", including the double quotes as the browser name.

Hi, Derick.

Since there are so many people still using very early versions of 4.3.x I know it will be a very long time before everyone upgrades to 5.* and that means I'll be stuck in the same untenable situation I'm in right now for a very long time.

Kindly remove the link to my website from your documentation page. It's not fair to your users to refer them to a browscap.ini file that does not work in PHP.

~gary.

I posted this on internals but I should probably add it to 
the bug report, too... 
 
A patch for this against HEAD is available at 
 
http://bugs.tutorbuddy.com/download.php/browscap.patch.tar.gz 
 
It contains the new parser (which goes into ext/standard) 
and updates to the makefiles for *ix and win32. I've 
tested the patch on linux and win2k, and I'd like to 
commit to HEAD for inclusion in 5.1. Backporting to 5.0 
would be nice, too, if possible. 
 
J 

Gary Keith has already (2004-10-02) kindly modified his browscap.ini in order to prevent a specific crash about the Nutch browser. But the browscap parser should anyway include a security: when one assign a parent to the same parent in browscap.ini, there is an infinite loop that should be prevented.

Example in browscap.ini:
[Nutch]
parent=Nutch

Then in a PHP script:
$browser=get_browser('Nutch');

Effect:
Infinite loop that takes 100% CPU forever.

This would have to be caught during module start up, but 
what should be done about it? Have the parser crap out and 
stop processing when this happens, leaving an error 
message in the logs or on stderr or whatever? Spit out a 
warning but continue processing? What assumptions should 
be made about the screwed up entry, should it just be 
discarded? 
 
This should probably be in it's own bug report, btw, this 
is a seperate issue from the original report. (The new 
parser fixes the original bug report, but not this issue, 
which may or may not be fixed, as it's kind of a problem 
with the ini file itself, akin to calling a function with 
infinite recursion...) 
 
J 

This is now fixed in CVS. Now it is possible to use the plain browscap.ini everybody else uses and there is no more need for the "special" quoted version for PHP.