Bug #18462 Updated: php -c /path/to/different/php.ini doesn't work

ID: 18462 Updated by: ceo@l-i-e.com Reported By: ceo@l-i-e.com Status: Bogus Bug Type: PHP options/info functions Operating System: RedHat 6.2 PHP Version: 4.2.1 New Comment: 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 Previous Comments: ------------------------------------------------------------------------ [2002-07-23 17:43:04] 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-23 14:13:00] ceo@l-i-e.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-22 21:25:14] 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-22 21:19:30] ceo@l-i-e.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 20:35:30] 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 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18462 -- Edit this bug report at http://bugs.php.net/?id=18462&edit=1