[PHP-DEV] $argv and $argc registration
I am not subscribed to this list, so please CC: or reply directly to me.
Thanks!
I may be doing something wrong.. I'm not real sure. Neither $argc or $argv
seem to be registered with the cgi version of php 4.0.6 and up.
The test script:
?php
ini_set ('register_globals', 1);
ini_set ('register_argc_argv', 1);
var_dump ($argc);
var_dump ($argv);
?
exits with the following:
Warning: Undefined variable: argc in ./foo.php on line 5
NULL
Warning: Undefined variable: argv in ./foo.php on line 6
NULL
regardless of any command line options passed to it.
Older scripts that work fine with php 4.0.5 fail with 4.0.6, with identical
build options and php.ini settings. The above script also behaves as expected
on php 4.0.5.
Any ideas? Am I missing something? Does this work for other people?
--
Jeremy
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Imap SSL support (Bug #10330)
On Thu, May 03, 2001 at 09:28:03AM +0200, Jani Taskinen wrote: On Thu, 3 May 2001, Alexander Bokovoy wrote: This code branch should only be triggered if HAVE_IMAP_SSL is defined, which should only happen if you configure php --with-imap-ssl. If you're doing so, it's assumed that you've built c-client with SSL support. Current configure macros in PHP 4.0.x have flaw that breaks your assumption. ext/imap uses several PHP_ARG_WITH() macros in order to find out configuration options. When building ext/imap as standalone dynamically loadable module via phpize (self-contained extension), PHP_ARG_WITH() relies on the value of $php_always_shared (which is 'yes' here) so result of PHP_ARG_WITH always be 'yes' regardless of user input or system checks. You're both wrong. This is really a bug in the IMAP-2001.beta sources. It's not possible to build it with SSL support on Unix. This is known bug since early March but nobody fixed it and in general fixing requires serious rework of PHP4's configure macros concept. Submit a patch or shut up. --Jani Guys (and gals), my original message was simply stating the symptoms of the 'bug' reported, then the actual solution for it. It IS imap 2000*, not php. It does not build itself with ssl unless specifically told to. The Makefile for imap explains. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Imap SSL support (Bug #10330)
The imap module fails with the following (perhaps only when building against imap-2000*): php_imap.c: In function `php_minit_imap': php_imap.c:450: `auth_ssl' undeclared (first use in this function) php_imap.c:450: (Each undeclared identifier is reported only once php_imap.c:450: for each function it appears in.) The solution is to rebuild the imap c-client library with something resembling make slx SPECIALAUTHENTICATORS=ssl EXTRACFLAGS=/path/to/openssl/includes/ This just failed for me on 4.0.5-RC8 and imap-2000c. I never built imap in this manner previously, and the php-imap module has never failed on releases prior to the 4.0.5-RC's, as they don't look for an auth_ssl function in the c-client library. Thanks! Jeremy -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Imap SSL support (Bug #10330)
On Mon, Apr 30, 2001 at 01:22:32PM -0500, J. Jones wrote: make slx SPECIALAUTHENTICATORS=ssl EXTRACFLAGS=/path/to/openssl/includes/ Whoops! make that make slx SPECIALAUTHENTICATORS=ssl EXTRACFLAGS=-I/path/to/openssl/includes/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] is_link() behavior
On Wed, Apr 25, 2001 at 01:05:00AM -0500, J. Jones wrote: On Wed, Apr 25, 2001 at 08:56:47AM +0200, Andi Gutmans wrote: I commited another fix. is_link() should work correctly now. If things have improved and you have problems with lstat() and filetype() (which I think there's a good chance that they are screwed up) let me know. Thanks, Andi --new output :(01:02am ~/php): ./fs-test.php is_link passed readlink passed: /bin/false filetype passed: link lstat passed: Array ( [0] = 770 [1] = 749 [2] = 41471 [3] = 1 [4] = 0 [5] = 0 [6] = 0 [7] = 10 [8] = 988178527 [9] = 988178527 [10] = 988178527 [11] = 4096 [12] = 1 ) is_link passed readlink passed: /this/file/does/not/exist Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or directory) in ./fs-test.php on line 11 filetype failed Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or directory) in ./fs-test.php on line 14 lstat failed --end Ok.. is_link() and readlink() (I realize this is in a separate section, but I still use it as opposed to lstat() to get the link's target) are the only two functions that work on broken symlinks. filetype(), lstat(), and file_exists() all fail (the latter probably should, eh?). I assume all the filesomeinfo() functions will fail also, since they are based on lstat() or stat(). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] is_link() behavior
This was originally posted to php-general, but for some reason I believe it may belong here. I apologize if I'm wrong. Forgive me for my ignorance, but I've noticed some unwanted behavior (IMO, at least) with the is_link() function. Given the simple code.. if ( is_link (/tmp/this_is_a_symlink) ) print (Success\n); and the file.. lrwxrwxrwx 1 root root 5 Apr 23 21:19 /tmp/this_is_a_symlink - /bin/ the above obviously prints 'Success\n'. However, if I BREAK the symlink, with something like the following.. lrwxrwxrwx 1 root root 4 Apr 23 21:21 /tmp/this_is_a_symlink - foo the script fails with.. Warning: stat failed for /tmp/this_is_a_symlink (errno=2 - No such file or directory) in ./test.php on line 3. The file /tmp/this_is_a_symlink is still a symlink, so it seems to me that the is_link() function should still return true, whether or not the symlink's target exists. Is there perhaps a function I have yet to discover that provides that behavior, without verifying the link's target? I ask this because much of linux's /proc contains (intentionally) broken symlink's and is_link()'s behavior is making the scouring of /proc difficult on me. ;) Thanks for any input.. J. Jones P.S. The script ran as root, so filesystem permissions aren't the issue. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] is_link() behavior
On Tue, Apr 24, 2001 at 10:50:36AM +0200, Andi Gutmans wrote:
It definitely seems as if the logic in the code (filestat.c) is kind of
screwed up.
If no one has time to look at it I can try and take a look at it later on.
Andi
At 01:35 AM 4/24/2001 -0500, J. Jones wrote:
Forgive me for my ignorance, but I've noticed some unwanted behavior
(IMO, at least) with the is_link() function. Given the simple code..
if ( is_link (/tmp/this_is_a_symlink) )
print (Success\n);
and the file..
lrwxrwxrwx 1 root root 5 Apr 23 21:19 /tmp/this_is_a_symlink - /bin/
the above obviously prints 'Success\n'.
However, if I BREAK the symlink, with something like the following..
lrwxrwxrwx 1 root root 4 Apr 23 21:21 /tmp/this_is_a_symlink - foo
the script fails with..
Warning: stat failed for /tmp/this_is_a_symlink (errno=2 - No such file or
directory) in ./test.php on line 3.
The file /tmp/this_is_a_symlink is still a symlink, so it seems to me that
the is_link() function should still return true, whether or not the symlink's
target exists. Is there perhaps a function I have yet to discover that
provides that behavior, without verifying the link's target?
I grew impatient, and devised a simple (2 line) workaround in filestat.c.
Basically it just required NOT doing a stat() if is_link() was calling
php_stat(). This probably isn't 'the' fix, but it works great for me, and
I know you guys are pretty busy. Attached is my diff against
php-4.0.4pl1's ext/standard/filestat.c.
Thanks for the great language! Keep it up!
J. Jones
--- php-4.0.4pl1/ext/standard/filestat.cThu Dec 7 13:15:02 2000
+++ php-4.0.4pl1/ext/standard/filestat.cTue Apr 24 16:43:06 2001
@@ -467,6 +467,7 @@
#if HAVE_SYMLINK
BG(lsb).st_mode = 0; /* mark lstat buf invalid */
#endif
+ if (type != 14) {
if (V_STAT(BG(CurrentStatFile),BG(sb))==-1) {
if (type != 15 || errno != ENOENT) { /* fileexists() test must
print no error */
php_error(E_NOTICE,stat failed for %s (errno=%d -
%s),BG(CurrentStatFile),errno,strerror(errno));
@@ -474,6 +475,7 @@
efree(BG(CurrentStatFile));
BG(CurrentStatFile)=NULL;
RETURN_FALSE;
+ }
}
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] is_link() behavior
On Wed, Apr 25, 2001 at 07:22:03AM +0200, Andi Gutmans wrote:
Hi,
I just commited a patch which also cleaned up some other stuff (although it
could still use some fixing up).
Please check the latest CVS to see if it works now.
Also can you please check the lstat() command? I think it has the same
problem (I didn't fix it because I want to be sure) and I think filetype()
might also not work correctly on links which aren't pointing to anything
(at least not give all the right information).
Andi
Hey.. I pulled just the filestat.c out of CVS into php-4.0.4pl1..
hopefully that isn't the issue (I recieved no warnings during the compile,
and nothing really seemed to have changed much in the ext/standard/
directory).
--code:
function link_func_test ($file)
{
if ( is_link ($file)) { print (is_link passed\n); }
else { print (is_link failed\n); }
if (($temp_filetype = filetype ($file))) { print (filetype passed:
$temp_filetype\n); }
else { print (filetype failed\n); }
if (($temp_lstat = lstat ($file))) { print (lstat passed:\n\n);
print_r ($temp_lstat); }
else { print (lstat failed\n); }
}
$file = '/tmp/test-link-func';
// This was if (file_exists ($file)), but it's borked too! ;)
@ unlink ($file);
if (symlink ('/bin/false', $file)) { link_func_test ($file); }
else { print (Good symlink failed\n); }
@ unlink ($file);
if (symlink ('/this/file/does/not/exist', $file)) { link_func_test ($file); }
else { print (Bad symlink failed\n); }
--End
--output:
:(00:36am ~/php): ./fs-test.php
is_link passed
filetype passed: link
lstat passed:
Array
(
[0] = 770
[1] = 1273
[2] = 41471
[3] = 1
[4] = 0
[5] = 0
[6] = 0
[7] = 10
[8] = 988177003
[9] = 988177003
[10] = 988177003
[11] = 4096
[12] = 1
)
Warning: lstat failed for (null) (errno=14 - Bad address) in ./fs-test.php
on line 5
is_link failed
Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
directory) in ./fs-test.php on line 8
filetype failed
Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
directory) in ./fs-test.php on line 11
lstat failed
--end
If there are other changes to the tree which may be affecting this I will
grab the full CVS tree and try again. Feel free to send me any patches
directly for testing.
Thanks!
J. Jones
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] is_link() behavior
Oh.. the readlink () function works fine in both instances.. readlink passed: /bin/false readlink passed: /this/file/does/not/exist -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] is_link() behavior
On Wed, Apr 25, 2001 at 08:56:47AM +0200, Andi Gutmans wrote: I commited another fix. is_link() should work correctly now. If things have improved and you have problems with lstat() and filetype() (which I think there's a good chance that they are screwed up) let me know. Thanks, Andi --new output :(01:02am ~/php): ./fs-test.php is_link passed readlink passed: /bin/false filetype passed: link lstat passed: Array ( [0] = 770 [1] = 749 [2] = 41471 [3] = 1 [4] = 0 [5] = 0 [6] = 0 [7] = 10 [8] = 988178527 [9] = 988178527 [10] = 988178527 [11] = 4096 [12] = 1 ) is_link passed readlink passed: /this/file/does/not/exist Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or directory) in ./fs-test.php on line 11 filetype failed Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or directory) in ./fs-test.php on line 14 lstat failed --end That's good enough for me.. is_link() and readlink() (what more do I really need for links?) both work perfect. One thing.. is source tree/main/fopen-wrappers.h renamed to source tree/main/fopen_wrappers.h in CVS, or is that a typo? ;) Thanks alot! Jeremy -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
