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

ID: 18462 Updated by: edink@php.net Reported By: ceo@l-i-e.com -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: RedHat 6.2 PHP Version: 4.2.1 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2002-07-22 16:55:14] ceo@l-i-e.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 ------------------------------------------------------------------------ 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