I have also been writing PHP command-line scripts, or rather maintaining them.
They are a bad idea, in general. PHP is designed for a very specific purpose: Very quickly building web pages in a CGI or mod_php environment and spitting them out. Everything else is an afterthought, and it shows.
For example, if you try to manipulate the filesystem extensively using PHP you will eventually trip over its "stat cache". PHP caches the result of stat() calls, presumably assuming that, hey, it is more important to avoid redundantly calling stat() during the time-sensitive rendering of your web page than it is to actually return correct information about the state of the filesystem. I mean, how often do symlinks change or files get moved during the rendering of a typical web page? And how much web-page-rendering code really depends on being able to read a link, then read the link again after the link has changed on disk? You can afford to ignore that stuff at the language level, if you're PHP.
The result is that you have to learn about the stat cache and remember to call clearstatcache() all the time when manipulating the filesystem in PHP.
That's just one example of why it's better to use Ruby or Perl to write command-line scripts. These languages were designed with command-line scripting in mind. Indeed, this is the flip side of the reason why PHP eventually drove out Perl as a web development language: Perl was originally designed for command-line scripting, and PHP was originally designed for the web. Use tools for their proper purpose.
Java was originally designed for programming embedded devices. Python was originally designed as a teaching language. One anecdote suggests that Lisp's original designers always intended to add syntax to the language.
Perhaps a decade after a language's invention it's possible to discuss its current suitability and design for specific tasks more than its original design intent.
(I consider PHP's relative ease of deployment over everything else far more explanatory of its ubiquity than any original design intent.)
Things like "stat cache" and "memory leaks" are what I watch out for when I write command line scripts in PHP. Also, I do not run my scripts as a daemon and I make sure that they do not run for more than a set maximum execution time.
So yeah, it may not be the most perfect choice but, it beats : having to learn another language when I know what to look out for when I write a command line script in PHP.
They are a bad idea, in general. PHP is designed for a very specific purpose: Very quickly building web pages in a CGI or mod_php environment and spitting them out. Everything else is an afterthought, and it shows.
For example, if you try to manipulate the filesystem extensively using PHP you will eventually trip over its "stat cache". PHP caches the result of stat() calls, presumably assuming that, hey, it is more important to avoid redundantly calling stat() during the time-sensitive rendering of your web page than it is to actually return correct information about the state of the filesystem. I mean, how often do symlinks change or files get moved during the rendering of a typical web page? And how much web-page-rendering code really depends on being able to read a link, then read the link again after the link has changed on disk? You can afford to ignore that stuff at the language level, if you're PHP.
The result is that you have to learn about the stat cache and remember to call clearstatcache() all the time when manipulating the filesystem in PHP.
That's just one example of why it's better to use Ruby or Perl to write command-line scripts. These languages were designed with command-line scripting in mind. Indeed, this is the flip side of the reason why PHP eventually drove out Perl as a web development language: Perl was originally designed for command-line scripting, and PHP was originally designed for the web. Use tools for their proper purpose.