Re: perl

[prev] [thread] [next] [lurker] [Date index for 2006/12/27]

From: Daniel Pittman
Subject: Re: perl
Date: 01:42 on 27 Dec 2006
peter@xxxxxxx.xxx (Peter da Silva) writes:

>> The "easy in a good way" part. Or rather, the "easy in a way which
>> doesn't need shell access, know where the perl on your system is, and
>> require that you completely rebuild your simple beginner web page and
>> wrap it in a hashbang and print statements in order to just put
>> today's date at the top".
>
> Well, I don't know about getting todays date on the top, but the rest
> of that sounds like Perl if it's not packaged with your system. You
> know that once upon a time there were still a few systems like that? 
>
> Of course Apple includes Perl in OS X.
>
> Unfortunately, they now also include PHP.
>
> Now, riddle me this. Why, when the OS ships with a Cocoa binding for
> fetching web pages, and it ships with libcurl, and it ships with Perl,
> and Tcl, and god knows what else... why would someone run a PHP script
> to fetch a file over HTTP?

You are asking the wrong question to experience the true and honest hate
that PHP, and people skilled in PHP, expose.

The *real* question is why someone would write a PHP script to do this:

  1.  determine the current date, by executing date(1) with the
      appropriate arguments.  (in the format year/month/day)
  2.  run mkdir -p to create the path in a storage area
  3.  run mysqldump to store a dump of the database into that location
  4.  use the mail function to send a message stating that this was done

Then, of course, put the wrong email address into the script so the
messages bounce, then run the whole thing under cron.

Which is really worthy of hate.


Oh, wait, no, it was better than that: they ran this as their normal,
unprivileged user account.  The script, and their home directory, were
world readable.  They hard-coded the database administrator username and
password into the script.

Which would have eventually broken the script, save that they had
hard-coded those same details everywhere else through the god-awful
application[1], so it could never be changed.

Of course, this was the system level database backup, so there was a
chunk of the global file system space that was writable to the world --
so the script could write into it.


No, wait, the really hate-worth part is that I had to look at the script
to find out what it was doing at one point.  It was six lines of PHP
code.  The script, in total, was close to 10K of data and around 300
lines -- including comments.

Those comments, of course, were things like:

 *
 * [ten lines of this cut for brevity]
 * @flooble bargle baz
 * [and ten lines of that]
 *
 * This function needs to be documents.


...and, actually, in all honesty, the real hate was this:

This script ran on the production servers.  It never, ever expired a
backup.  It finally, as you might expect, filled up all available disk
space with copies of the database.

Around line 270 or so it featured one vaguely helpful comment:

   "One day we should probably delete these"

In context it was obvious that they were thinking of the dumps.


Thanks, team.  Your use of PHP where a three line shell script was
appropriate was enough to clue me in that you were idiots, but the
helpful content of the script really iced the cake.

	Daniel

Plus it spat out fifty lines of crap on stdout as part of the process,
contributing to this company simply ignoring all email to root.


Footnotes: 
[1]  Written, for real hate, in undocumented Perl, with the revision
     confusion system of 'cp script.cgi script1.new.old.23.cgi', and
     extended by 'cp script.cgi another.cgi', then changing one line in
     five thousand.

-- 
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: contact@xxxxxxxxxxxxxxxxxxxxxx.xxx.xx
                 http://digital-infrastructure.com.au/

Generated at 22:02 on 27 Dec 2006 by mariachi 0.52