php-general Digest 12 Sep 2005 05:04:00 -0000 Issue 3677
Topics (messages 222144 through 222152):
Re: Stripping control M character (^M)
222144 by: Burhan Khalid
Best way to update PHP on RH 9
222145 by: Todd Cary
222146 by: Greg Donald
222149 by: bruce
PHP Sessions
222147 by: Chris Wagner
222148 by: Jasper Bryant-Greene
Payflow Pro compile error
222150 by: Dan Harrington
222151 by: Vizion
Re: PHP page counter
222152 by: Vedanta Barooah
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Philip Hallstrom wrote:
Hello All,
I'm having some issues with carriage returns. Specifically the control M
character (^M). I have attempted to clean and validate the file I'm
creating. Here's the code.
while ($row = mysql_fetch_array($result)){
// assign and clean vars
$artist = trim($row[artist]);
$tdDate = trim($row[start_date]);
$venue = trim($row[venue]);
$city = trim($row[CITY]);
$state = trim($row[STATE]);
$country = trim($row[COUNTRY]);
$tdId = trim($row[td_id]);
// create string
$line = "$artist|||$tdDate||$venue|$city|$state|$country|$tdId\n";
// validate the string
if(preg_match("/.*.|||.*.||.*.|.*.|.*.|.*.|.*.n\//", $line)){
// record is correct so write line to file
fwrite($handle,$line);
}
}
So ^M slips right by trim and my preg_match line.
Where is the carriage return appearing in your line of output? Trim
will remove these, but only at the beginning/end of a string so if
$artist = "Paul\rNowosielski" that won't get cleaned up...
Maybe run them through ereg_replace() using "[\n\r]" as a pattern?
Or maybe use the m modifier?
--- End Message ---
--- Begin Message ---
I have RH 9 on our server and if I try to use a rpm for php-4.3.9 or
greater, there are many unresolved dependencies. What is the best way
around this problem?
Todd
--- End Message ---
--- Begin Message ---
On 9/11/05, Todd Cary <[EMAIL PROTECTED]> wrote:
> I have RH 9 on our server and if I try to use a rpm for php-4.3.9 or
> greater, there are many unresolved dependencies. What is the best way
> around this problem?
There are at least a couple ways around this problem.
1) Follow the rpm dependencies until you fulfill them all. There are
lots of great rpm sites around, rpmfind.net, freshrpms.net, etc. This
option has two possible outcomes:
a) You succeed and finally get your desired PHP version installed.
b) You fail and your box is a mess of mostly-upgraded rpms.
2) Rip out your PHP rpms and install PHP from source.
I don't use rpm based distros much anymore, but I usually go for
option #2 anyway.
--
Greg Donald
Zend Certified Engineer
MySQL Core Certification
http://destiney.com/
--- End Message ---
--- Begin Message ---
3rd way...
if you have linux (and you do!) you can get yum.
yum install php
provided you have your yum paths/repos set properly, it'll more or less walk
through the dependency issues for you...
what ever you do, you can/should be expecting that some app will scream that
you're now using a wrong version of php!!!
welcome to dependency hell!!!
-bruce
-----Original Message-----
From: Greg Donald [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 11, 2005 11:46 AM
To: [email protected]
Subject: Re: [PHP] Best way to update PHP on RH 9
On 9/11/05, Todd Cary <[EMAIL PROTECTED]> wrote:
> I have RH 9 on our server and if I try to use a rpm for php-4.3.9 or
> greater, there are many unresolved dependencies. What is the best way
> around this problem?
There are at least a couple ways around this problem.
1) Follow the rpm dependencies until you fulfill them all. There are
lots of great rpm sites around, rpmfind.net, freshrpms.net, etc. This
option has two possible outcomes:
a) You succeed and finally get your desired PHP version installed.
b) You fail and your box is a mess of mostly-upgraded rpms.
2) Rip out your PHP rpms and install PHP from source.
I don't use rpm based distros much anymore, but I usually go for
option #2 anyway.
--
Greg Donald
Zend Certified Engineer
MySQL Core Certification
http://destiney.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
hello,
i recently started using PHP's sessions. i am finding that the sessions
seem to "expire" after 20 or 30 minutes -- or, at least the variables
which i set, within $_SESSION, are getting cleared after this relatively
short amount of time.
before calling session_start(), i do a few initializations:
ini_set('session.use_cookies', 1);
ini_set('session.use_trans_sid', 0);
ini_set('session.save_handler', 'files');
ini_set('session.serialize_handler', 'php');
ini_set('session.name', 'session-id');
i am not setting the 'session.cache_expire' INI variable, and even did a
check to make sure it was not being modified, and i found that it
contains the default value of 180 (minutes).
furthermore, the *cookie* is not expiring. i've also checked
'session.cookie_lifetime', and it is 0 (zero, for "until browser is
closed"). i've also checked the browser's cookie list, and the cookie
is still around at the time that i lose my session variables.
does anyone have any ideas as to why i may be losing my session
variables so early?
thank you!
--- End Message ---
--- Begin Message ---
Chris Wagner wrote:
i recently started using PHP's sessions. i am finding that the sessions
seem to "expire" after 20 or 30 minutes -- or, at least the variables
which i set, within $_SESSION, are getting cleared after this relatively
short amount of time.
before calling session_start(), i do a few initializations:
ini_set('session.use_cookies', 1);
ini_set('session.use_trans_sid', 0);
ini_set('session.save_handler', 'files');
ini_set('session.serialize_handler', 'php');
ini_set('session.name', 'session-id');
i am not setting the 'session.cache_expire' INI variable, and even did a
check to make sure it was not being modified, and i found that it
contains the default value of 180 (minutes).
furthermore, the *cookie* is not expiring. i've also checked
'session.cookie_lifetime', and it is 0 (zero, for "until browser is
closed"). i've also checked the browser's cookie list, and the cookie
is still around at the time that i lose my session variables.
does anyone have any ideas as to why i may be losing my session
variables so early?
Check session.gc_lifetime or similar. That is the garbage collection
routine that goes through and deletes any session data files (in /tmp or
wherever your setup puts them) that are older than that config setting
value.
--
Jasper Bryant-Greene
Freelance web developer
http://jasper.bryant-greene.name/
If you find my advice useful, please consider donating to a poor
student! You can choose whatever amount you think my advice was
worth to you. http://tinyurl.com/7oa5s
--- End Message ---
--- Begin Message ---
Greetings,
It seems that I've gone around and around on this issue starting with PHP3
every time I install a new server.
And here I am again.
OS:
Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:59:02 EST 2004 i686 i686 i386
GNU/Linux
php-5.0.4
library with pfpro listed in /etc/ld.so.conf and I ran ldconfig...
----------------------------------------------
And when I type:
./configure --with-mysql=/usr/local/mysql
--with-apxs=/usr/local/apache/bin/apxs --with-curl --enable-mbstring=en
--with-pfpro
or
./configure --with-mysql=/usr/local/mysql
--with-apxs=/usr/local/apache/bin/apxs --with-curl --enable-mbstring=en
--with-pfpro=/usr/local/src/verisign/payflowpro/linux/lib
or
./configure --with-mysql=/usr/local/mysql
--with-apxs=/usr/local/apache/bin/apxs --with-curl --enable-mbstring=en
--with-pfpro=/usr/local/lib
or anything else I can think of, I get this error message:
[.....]
checking for Verisign Payflow Pro support... yes
checking for pfproInit in -lpfpro... no
checking for PNInit in -lpfpro... no
configure: error: The pfpro extension requires version 2 or 3 of the SDK
And I'm dead.
Anyone have similar situation that knows what to do? Is it the Enterprise
Linux v.3 Is it the PHP 5?
(I have an Enterprise Linux 2 with PHP4 that works just fine!)
Thanks
Dan
--- End Message ---
--- Begin Message ---
On Sunday 11 September 2005 16:46, the author Dan Harrington contributed to
the dialogue on-
[PHP] Payflow Pro compile error:
>Greetings,
>
>It seems that I've gone around and around on this issue starting with PHP3
>every time I install a new server.
>
>And here I am again.
>
>OS:
>Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:59:02 EST 2004 i686 i686 i386
>GNU/Linux
>php-5.0.4
>library with pfpro listed in /etc/ld.so.conf and I ran ldconfig...
>
>----------------------------------------------
>And when I type:
>
>./configure --with-mysql=/usr/local/mysql
>--with-apxs=/usr/local/apache/bin/apxs --with-curl --enable-mbstring=en
>--with-pfpro
>
>or
>
>./configure --with-mysql=/usr/local/mysql
>--with-apxs=/usr/local/apache/bin/apxs --with-curl --enable-mbstring=en
>--with-pfpro=/usr/local/src/verisign/payflowpro/linux/lib
>
>or
>
>./configure --with-mysql=/usr/local/mysql
>--with-apxs=/usr/local/apache/bin/apxs --with-curl --enable-mbstring=en
>--with-pfpro=/usr/local/lib
>
>or anything else I can think of, I get this error message:
>
>[.....]
>checking for Verisign Payflow Pro support... yes
>checking for pfproInit in -lpfpro... no
>checking for PNInit in -lpfpro... no
>configure: error: The pfpro extension requires version 2 or 3 of the SDK
>
>And I'm dead.
>
>Anyone have similar situation that knows what to do? Is it the Enterprise
>Linux v.3 Is it the PHP 5?
>
>(I have an Enterprise Linux 2 with PHP4 that works just fine!)
>
>Thanks
>Dan
This might be useful:
from
http://us2.php.net/pfpro
After weeks of searching and trying to install Payflow Pro on Red Hat
Enterprise Linux 3, I finally was able to make it work. Naturally I was very
hesitant to recompile my php configuration, but with a little help from
redhat, and about 3 hours, it was installed. I'll try to outline the steps as
best I can.
I'm running RedHat EL 3.0, php-4.3.2, apache 2.0.46.
Anyone running EL 3 is a member of the redhat network, so use up2date to
download the latest php source rpm.
up2date --get-source php (this will download the source rpm
into /var/spool/up2date)
rpm -i /var/spool/up2date/php-4.3.2 (or whatever version of php it gives you,
installing this source rpm will not affect your current php configuration)
cd /usr/src/redhat/SPECS
rpmbuild -bp php.spec (unpack the sources and apply patches)
I had a couple of dependency requirements (imap-devel, unixODBC-devel; yours
may vary; up2date 'whatever you need'; if you had to install dependant rpms,
run rpmbuild -bp php.spec again)
vi php.spec (edit the spec file and include the --with-pfpro)
on line 285 or 286, you'll see where the ./configure command is generated.
Adjust any defaults as necessary, I didn't need to, and add
--with-pfpro=[DIR]. Make sure to place this outside the if's, I placed mine
before ifarch(%ix86).
If you followed the instructions above, and unpacked pfpro into /usr/local,
you would add
--with-pfpro=--with-pfpro=/usr/local/verisign/payflowpro/sunsparc, where my
version was linuxrh9. I'm running modssl, my config was
--with-pfpro=shared,/usr/local.
Make sure that you have followed php.net's instructions and copied pfpro.h and
libpfpro.so to the appropriate directories.
Now that we've added our config line, build the rpm. You will get a compile
error if you have the incorrect version of the SDK. RedHat EL users should
have downloaded the SDK for RedHat 9.x.
rpmbuild -bb php.spec (this will take awhile)
**According to documentation on redhat, new versions of rpm added a feature
which causes a build termination if it finds files not "intended" to be
included in the package. Obviously, since we added pfpro, it wasn't intended
to be there. To get around this do the follow:
Edit your php.spec file (same one from earlier), and include
%define _unpackaged_files_terminate_build 0
I added this as the second line under the comments, mine looks like this:
%{!?oracle:%define oracle 0}
%define _unpackaged_files_terminate_build 0
This will allow the build to continue with these unpackaged files.
5 minutes later, if no errors were returned, it should that it build a whole
bunch of rpms, all related to php. Now lets install them.
Redhat recommeded uninstalling existing rpms and installing these new ones, as
opposed to using rpm -Uvh. So, uninstall the cooresponding php rpms. If it
complains about dependancies, use --nodeps. Now, install rpm -i your new
ones. You can install them all on the same line if you'd like.
rpm -i php-4.x.x. php-imap-4.x. php-mysql-4.x.x
Done! Now to quote Sean from below:
5) Copy /usr/src/redhat/BUILD/php-X.X.X/build-apache/modules/pfpro.so
to /usr/lib/php4.
6) Add "extension=pfpro.so" to /etc/php.d/pfpro.ini using the other .ini files
as templates.
Restart apache, and you should now be able to invoke the Payflow Pro
functions!
mark at tuscaloosadesigncompany dot com
25-Sep-2004 04:02
After upgrading my slackware system's glibc to 2.3.3 (which is the first
version of glibc on slackware that does not include a __ctype compatibility
patch) and spending far too much time trying to figure out why the configure
script could not figure out I had version 3 of the payflow pro library, the
simple solution was to download the "Linux (Redhat 9.x)" version of the
payflow SDK because Verisign has linked this version of the library to the
glibc 2.3.x version of the __ctype functions (which are of the form
__ctype_xxx_loc instead of __ctype_xxx).
You should avoid the "Linux - (libc6 / glibc2 / ELF kernels 2.0.36 and above)"
version of the SDK unless you have a glibc version < 2.3.x.
If you're having this problem, check your config.log for the following lines:
/usr/local/lib/libpfpro.so: undefined reference to `__ctype_b'
/usr/local/lib/libpfpro.so: undefined reference to `__ctype_tolower'
You can also run the following command to find out which version of the
__ctype functions the library was linked to:
readelf -s /usr/local/lib/libpfpro.so | grep ctype
sean at trunkmonkey dot com
17-Aug-2004 08:09
To expand on Michael's instructions on getting Payflow Pro working as a
loadable module under FreeBSD, you can do the same thing under RedHat
Enterprise and Fedora:
1) Drop pfpro.h and libpfpro.so into their respective directories per
Requirements above.
2) Install the RedHat Enterprise or Fedora PHP SRPM.
3) Add "--with-pfpro=shared,/usr/local \" to the "%configure \" line in
php.spec.
4) Run rpmbuild -bc php.spec
5) Copy /usr/src/redhat/BUILD/php-X.X.X/build-apache/modules/pfpro.so
to /usr/lib/php4.
6) Add "extension=pfpro.so" to /etc/php.d/pfpro.ini using the other .ini files
as templates.
/Sean/
--
40 yrs navigating and computing in blue waters.
English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus.
Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after
completing engineroom refit.
--- End Message ---
--- Begin Message ---
there is one here : http://www.phpclasses.org/browse/package/2212.html
see if it suffices your need,
thanks,
vedanta
On 9/11/05, Michelle Konzack <[EMAIL PROTECTED]> wrote:
> G'Morning *,
>
> Does anyone know, where I can get a PHP-Code for
> a high performance page counter ?
>
> I need one, which can handle very high traffic
> (15.000 Hits/h) becase my own one sucks (locking). :-/
>
> It can be text/plain or php-gd based.
>
> Greetings
> Michelle
>
> --
> Linux-User #280138 with the Linux Counter, http://counter.li.org/
> Michelle Konzack Apt. 917 ICQ #328449886
> 50, rue de Soultz MSM LinuxMichi
> 0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com)
>
>
>
--
*~:~*~:~*~:~*~:~*~:~*~:~*~:~*~:~*~:~*~:~*
--- End Message ---
