php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #18462 php -c /path/to/different/php.ini doesn't work
Submitted: 2002-07-21 15:34 UTC Modified: 2002-07-24 00:37 UTC
From: ceo at l-i-e dot com Assigned:
Status: Not a bug Package: PHP options/info functions
PHP Version: 4.2.1 OS: RedHat 6.2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: ceo at l-i-e dot com
New email:
PHP Version: OS:

 

 [2002-07-21 15:34 UTC] ceo at l-i-e dot com
The following weekly cron job worked fine until a recent upgrade/install of PHP 4.2.1 using:


./configure \
--enable-calendar \
--enable-bcmath \
--with-jpeg-dir \
--with-png-dir=/usr/local \
--with-tiff-dir \
--enable-ftp \
--with-gd=/usr/local \
--enable-gd-imgstrttf \
--with-ttf \
--with-freetype-dir=/usr/local \
--with-t1lib \
--with-imap \
--with-ldap \
--with-pgsql \
--with-mysql=/usr/src/mysql \
--disable-debug \
--with-kerberos \
--with-imap-ssl \
--with-pdflib \
--with-swf=/usr/src/libswf \
--with-xmlrpc=/usr/local \
--with-expat-dir=/usr/local \
--with-dom \
--with-zlib \
--enable-sockets



./harvest.php
X-Powered-By: PHP/4.2.1^M
Content-type: text/html^M
^M
<br />
<b>Fatal error</b>:  Failed opening required 'connect.inc' (include_path='.:/usr/local/lib/php') in <b>/home/www/pocketguide/cron/harvest.php</b> on line <b>6</b><br />


head ./harvest.php

#!/usr/bin/php -c /home/pocketguide/php.ini -q
<?php
        /* harvest.php
                Automatically harvest performers and dates from venue web-sites
        */

        require 'connect.inc';

        require 'publication.inc';



grep include_path /home/pocketguide/php.ini
include_path    = "./:/home/pocketguide/include/"                  ; UNIX: "/path1:/path2"  Windows: "\path1;\path2"


In essence, it would appear that the "-c" option is no longer working.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-07-21 19:25 UTC] edink@php.net
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



 [2002-07-21 19:28 UTC] edink@php.net
Correction: since -c takes path to php.ini, the command should be:

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


 [2002-07-22 16:55 UTC] ceo at l-i-e dot com
#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
 [2002-07-22 20:35 UTC] sniper@php.net
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
 [2002-07-22 21:19 UTC] ceo at l-i-e dot com
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
 [2002-07-22 21:25 UTC] sniper@php.net
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?

 [2002-07-23 14:13 UTC] ceo at l-i-e dot com
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
 [2002-07-23 17:43 UTC] edink@php.net
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.
 [2002-07-24 00:37 UTC] ceo at l-i-e dot com
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
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Jan 18 08:03:18 2022 UTC