I doubt that this has ever worked on Linux due to its shebang line limitations (#!/usr/bin/php). It's limited to only one argument.

To get around this problem run your cronjob as:

/usr/bin/php -c /home/pocketguide/php.ini -q /path/to/harvest.php

Correction: since -c takes path to php.ini, the command should be:

/usr/bin/php -c /home/pocketguide -q /path/to/harvest.php

#1. It *DID* work JUST FINE for months and months before 
this upgrade.

#2. I'm willing to try it without the 'php.ini' in the path, 
but I suspect a complete path is needed, since some users 
may have desired to have them all in one directory, with 
different names.

Either way -- It worked just fine before, and doesn't now, 
and it's a documented feature:
php -h
clearly outputs what it's supposed to do.

There may not have been a space between -c and the path 
previously...  I dinked with that both ways after it b

Support for passing the filename for php.ini was added
in 4.3.0-dev... -c only accepts PATH to the php.ini in 4.2.x

There seem to be TWO issues here:
1. Can the filename be included?
2. Does "#!/usr/local/bin -c/path -q" work?

I can only say this to both:

IT WORKED BEFORE!

I've had this running for over six months as a cron job, and 
I'm just spewing out *exactly* what was in the files for all 
that time.  The *ONLY* change I made was to re-compile PHP 
with 4.2.1 and a lot more extensions.

Even if you want to posit that the full filename only works 
after 4.3.0-dev, and ignore the *FACT* that it worked for 
the past six months there is *STILL* the issue of:
#!/usr/local/bin -c/different/path -q
suddenly breaking.

Yes, the work-around for altering the cron to have all the 
junk in cron instead of in #! is an okay, if annoying, 
work-around.  I then have to remember to add the -c/whatever 
if I ever decide to do it from the command line -- Which I 
probably won't, so I'll waste time chasing down why it's 
"broken"

But *EVEN* using:
#!/usr/local/bin/php -c/just/the/path -q
is BROKEN in 4.2.1 and was NOT BROKEN before.

Here is the *OLD* configure I used in 4.1.0 where it wasn't 
broken:

./configure \
--with-jpeg-dir \
--with-tiff-dir \
--enable-ftp \
--enable-gd-imgstrttf \
--with-gd \
--with-ttf \
--with-freetype-dir=/usr/local \
--with-t1lib \
--with-imap \
--with-ldap \
--with-pgsql \
--without-mysql \
--enable-versioning \
--enable-memory-limit \
--with-kerberos \
--with-imap-ssl \
--with-pdflib

That configure line would cause the default search path
for php.ini to be in /usr/local/lib. Before that, the current working directory is searched, then the path pointed by PHPRC environment variable, then the compiled in path..

Are you sure none of these were not used before when it worked?

I have two different php.ini files.
The "main" one at /usr/local/lib/php.ini is for the other 
applications.
The Pocketguide Harvester uses the one at 
/home/pocketguide/php.ini

/usr/local/lib/php.ini has include_path = './'
/home/pocketguide/php.ini has "./:/home/pocketguide/"
connect.inc (see source) lives in /home/pocketguide/ 
(outside the web tree)

I am 100% certain it was using the alternate php.ini file.
It simply couldn't have connected to the correct database 
(or any database, for that matter) without it.  I never put 
connect.inc in the web tree.

I'm not sure why I didn't just use the full path in my 
"include" statement, but for some reason I felt the need to 
muck with an alternate php.ini...  I suspect there must have 
been some other setting I wanted to alter, and .htaccess 
wouldn't work, since it was a cron job, and some settings 
won't do any good to alter once you're actually in <?php ?>

Near as I can figure from the matching .htaccess (when I 
surf to the same file for debugging) I'd guess that I wanted 
an increased memory limit for this application, and that 
setting wasn't working unless it was altered in php.ini?

I suspect I found that setting the memory limit within a 
script itself is ineffective, and once I had to have an 
alternate php.ini, I might a well change the include_path 
there as well.

At this point, exactly why I felt the need to set it up that 
way isn't really that critical -- Something broke 
"#!/usr/bin/php -c xxx -q" between 4.1 and 4.2, and it would 
be Really Nifty (tm) to fix it.

If it's a case of one of the new extensions I added between 
4.1 and 4.2 breaking the command-line -c, that's an even 
nastier bug, but still Not Good...

At any rate, there's two configure lines -- One with 4.1.0 
will make #!php -c work, the other with

Let me repeat it again: this has never worked with php on linux. Search the bug database for word shebang and you'll find many report for the same issue before. http://bugs.php.net/bug.php?id=14416 is an example of it. Linux kernel allows only *ONE* parameter to be passed in the #! line.

The only way I could imagine that this has worked was if you had all the parameters passed as one as in

#!/usr/bin/php -qc/my/path/

Please do not reopen this bug report.

Final Analysis for anybody else who gets bitten by this:

You used to be able to have:
#!/usr/local/bin/php -c/path/to/file/php.ini -q

and it would use the php.ini file, even if you weren't 
supposed to have the php.ini part before (but now you can) 
and it would ignore the bogus -q that Linux won't let you 
have, and it would "work" but not actually suppress the 
headers -q is supposed to suppress.

In 4.2, it will puke all over your pretty blue suede shoes 
unless you take out the -q part that never worked right 
anyway.

I don't know (or care) at this point that the behavior 
changed, since it was "wrong" to have both -c/path and -q in 
the first place.

YMMV.

Apologies in advance to anybody that "it worked" as an 
undocumented feature up