I find the guy to whom you're replying to be obnoxious, but he's not wrong about it being poor for CLI stuff. Loads of stuff non-obviously behaves differently in a web context versus a CLI context (and while it's documented, you still have to know about it). It doesn't have good stream processing facilities. It, as mentioned, requires a php.ini and requires you to think about that when you're writing scripts in it.
It can be done. It is not something I would recommend under almost any circumstances. (But, then, I wouldn't recommend Ruby for any-any circumstances, so...)
The only real differences from running PHP/CLI that come to mind are:
* PHP_SAPI is defined to 'cli' (as compared to 'fastcgi' or similar)
* $_GET/$_POST are empty, and $_SERVER is missing the HTTP_XXX variables (duh)
* By default, there's no max execution time
I dunno, it works perfectly fine for me. It's certainly easier to read and write than shell, and I genuinely can't think of a time that an ini directive had any effect on what I was doing - unless you count the presence or lack thereof of an extension, but everyone knows that PHP's extension handling is pretty crappy.
I guess it all depends on what you're trying to do. I agree that stream handling is a little rough, although that has little bearing on what I tend to do (YMMV).
At the end of a day, it's a tool, and I have tasks that need to be done. That tool either is or isn't capable of accomplishing those tasks, and based on my own abilities it may or may not be faster than using other tools (contrary to popular opinion, I find Ruby extremely painful to work with, and avoid it at all costs; if it works for other people, good for them!)
It can be done. It is not something I would recommend under almost any circumstances. (But, then, I wouldn't recommend Ruby for any-any circumstances, so...)