Re: PHP vs Perl for system scripts (non-web)

Paul Chvostek <paul+php@it.ca> wrote... : > > I have to write a swath of code to manage system-related stuff based on > database content. Scripts will be run as root by cron, and determine > what they have to do via user interaction and SQL lookups. Functions > will include manipulation of system configuration files, legacy text > file configs, and some signalling with posix_kill. On some of the > machines in question, there won't even be an httpd installed, so I'd be > building a php as a standalone binary, and running it with shell magic > and a -q option. I've done this kind of stuff in the past in smaller > environments, and it seems to work nicely. PHP can easily do all that, probably even easier that with Perl. Perl is somewhat too painful to write scripts in. For my needs, i whether use PHP or Ruby for stand-alone apps. Ruby is less flexible than PHP but its "pure" OOP and I often need to resort to it. > I'm more comfortable writing stuff in PHP. I use PHP alot more, and I > find the resultant code more readable and easier to maintain. You answered yourself again - if you are more comfortable with PHP then why hassle with painful Perl? > Aside > from Perl's ubiquity and the dubious advantage of future flexibility by > using Perl's DBI interface to talk to different SQL servers (I'm using > MySQL at the moment), are there any compelling reasons I should write > system stuff in Perl rather than PHP? PHP natively works quite well with mySQL, thus its another reason to use it. -- Maxim Maletsky maxim@php.net