From: Collin S. <col...@co...> - 2005-02-01 20:29:57
|
I am trying to install Apache::PageKit on Apache2 on a Gentoo box. I seem to be in the home stretch but have hit a stumbling block. I installed mod_perl 1.99.17-r1 and libapreq2 2.04.03 and Apache::PageKit 2.14_12. However, when I try to start Apache2, I get -- # APACHE2_OPTS='-DPERL' /etc/init.d/apache2 start * Apache2 has detected a syntax error in your configuration files: Syntax error on line 73 of /usr/lib/apache2/conf/vhosts/vhosts.conf: Failed to load PageKit::Common (Can't locate Apache/Constants.pm in @INC (@INC contains: /app/apache2/site/www.collinstarkweather.com/pagekit/Model /home/httpd/perl /usr/lib/perl5/site_perl/5.8.5/i686-linux /usr/lib/perl5/site_perl/5.8.5/Apache2 /usr/lib/perl5/site_perl/5.8.5 ... blah blah blah ... /usr/lib/perl5/site_perl/5.8.5/Apache2/Apache/PageKit.pm line 156.\n # -- I feel like I am missing something fundamental. If I try to install Apache::Constants with `perl -MCPAN -e 'install Apache::Constants`, installation of mod_perl-1.29 commences, which is not what I want. Is Apache::Constants supposed to be bundled with mod_perl? Thanks, -Collin P.S. Output of `make test` (summary: All test successful) is below my sig in case it is helpful. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Collin Starkweather, Ph.D. col...@co... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ starky@www Apache-PageKit-2.14_12 $ make test /usr/bin/perl5.8.5 -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -clean [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl5.8.5 /home/starky/junk/Apache-PageKit-2.14_12/t/TEST -clean --documentroot '/home/starky/junk/Apache-PageKit-2.14_12/eg' Can't locate t/conf/apache_test_config.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.8.5/i686-linux /usr/lib/perl5/site_perl/5.8.5/Apache2 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.5/i686-linux/Apache2 /usr/lib/perl5/vendor_perl/5.8.5/i686-linux /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/5.8.5/i686-linux /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.2/i686-linux /usr/lib/perl5/vendor_perl/5.8.2/i686-linux /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/apache2) at /usr/lib/perl5/vendor_perl/5.8.5/i686-linux/Apache/TestRun.pm line 771. APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \ /usr/bin/perl5.8.5 -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -bugreport -verbose=0 [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl5.8.5 /home/starky/junk/Apache-PageKit-2.14_12/t/TEST -bugreport -verbose=0 --documentroot '/home/starky/junk/Apache-PageKit-2.14_12/eg' Can't locate t/conf/apache_test_config.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.8.5/i686-linux /usr/lib/perl5/site_perl/5.8.5/Apache2 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.5/i686-linux/Apache2 /usr/lib/perl5/vendor_perl/5.8.5/i686-linux /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/5.8.5/i686-linux /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.2/i686-linux /usr/lib/perl5/vendor_perl/5.8.2/i686-linux /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/apache2) at /usr/lib/perl5/vendor_perl/5.8.5/i686-linux/Apache/TestRun.pm line 771. /usr/sbin/apache2 -d /home/starky/junk/Apache-PageKit-2.14_12/t -f /home/starky/junk/Apache-PageKit-2.14_12/t/conf/httpd.conf -D APACHE2 using Apache/2.0.52 (prefork MPM) waiting 60 seconds for server to start: ....... waiting 60 seconds for server to start: ok (waited 5 secs) server localhost:8529 started t/01_dummy....................ok t/02_language.................ok t/03_charset..................ok t/04_anon_cookies.............ok t/05_account..................ok t/06_login....................ok t/07_restricted...............ok t/08_fresh_cookie_redirect....ok t/09_charset_tmpl.............ok t/10_pkit_comment.............ok All tests successful. Files=10, Tests=67, 13 wallclock secs (10.28 cusr + 0.59 csys = 10.87 CPU) [warning] server localhost:8529 shutdown starky@www Apache-PageKit-2.14_12 $ |
From: Boris Z. <bo...@2b...> - 2005-02-02 01:39:09
|
Hi Collin, It looks that you update a application from mod_perl 1 to mod_perl 2. In mod_perl 2, there is no Apache::Constants anymore ;-). Is is renames to Apache::Const. Findout what you are doing there. Mostlikely it is use Apache::Constants qw/REDIRECT DONE OK/; or similar. Replace that line with use Apache::Const qw/REDIRECT DONE OK/; propably thats enough. Am Dienstag, 1. Februar 2005 05:12 schrieb Collin Starkweather: > I am trying to install Apache::PageKit on Apache2 on a Gentoo box. I > seem to be in the home stretch but have hit a stumbling block. > > I installed mod_perl 1.99.17-r1 and libapreq2 2.04.03 and > Apache::PageKit 2.14_12. However, when I try to start Apache2, I get > > -- > # APACHE2_OPTS='-DPERL' /etc/init.d/apache2 start > * Apache2 has detected a syntax error in your configuration files: > Syntax error on line 73 of /usr/lib/apache2/conf/vhosts/vhosts.conf: > Failed to load PageKit::Common (Can't locate Apache/Constants.pm in > @INC (@INC contains: > /app/apache2/site/www.collinstarkweather.com/pagekit/Model > /home/httpd/perl /usr/lib/perl5/site_perl/5.8.5/i686-linux > /usr/lib/perl5/site_perl/5.8.5/Apache2 /usr/lib/perl5/site_perl/5.8.5 > ... blah blah blah ... > /usr/lib/perl5/site_perl/5.8.5/Apache2/Apache/PageKit.pm line 156.\n > # > -- > > I feel like I am missing something fundamental. If I try to install > Apache::Constants with `perl -MCPAN -e 'install Apache::Constants`, > installation of mod_perl-1.29 commences, which is not what I want. Is > Apache::Constants supposed to be bundled with mod_perl? > > Thanks, > > -Collin > > P.S. Output of `make test` (summary: All test successful) is below my > sig in case it is helpful. -- Boris |
From: Russell D. W. <rw...@in...> - 2006-06-14 20:10:31
|
Hello all, Long time no post :-). We've encountered the following problem in our PageKit application. When pulling data from a database and using $model->fillinform to populate form fields, we're seeing problems when the data contains certain international characters, such as "á" -- as well as potentially some others. Basically, if the word "Testá" is pulled from the database, the HTML form field will look like: <input type="text" value="Test? name="blah"> Obviously, this causes problems, as the value is not terminated properly with a quote, and the true value is not shown in the form field. I tested HTML::FillInForm separately and this problem does not appear. The problem may be due to some parsing that pagekit does after it runs the the page through HTML::FillInForm. Boris and others, do you have any idea as to what might cause this? Thanks, Russell |
From: Boris Z. <bz...@2b...> - 2006-06-15 21:33:00
|
Hi, Am 14.06.2006 um 22:10 schrieb Russell D. Weiss: > Hello all, > > Long time no post :-). > > We've encountered the following problem in our PageKit =20 > application. When > pulling data from a database and using $model->fillinform to =20 > populate form > fields, we're seeing problems when the data contains certain =20 > international > characters, such as "=E1" -- as well as potentially some others. > > Basically, if the word "Test=E1" is pulled from the database, the =20 > HTML form > field will look like: > > <input type=3D"text" value=3D"Test? name=3D"blah"> Obviously, this = causes > problems, as the value is not terminated properly with a quote, and =20= > the true > value is not shown in the form field. I tested HTML::FillInForm =20 > separately > and this problem does not appear. The problem may be due to some =20 > parsing > that pagekit does after it runs the the page through HTML::FillInForm. > > Boris and others, do you have any idea as to what might cause this? > I remember that problem. The reason is, that you lost the encoding of =20= your string somewhere. mysql for example does it always wrong. =20 Pagekit try to ship around the problem by removeing the utf8 flag =20 before we pass the data to fillinform. and force utf8 on the result. =20 There might be a bug or some strings in your page are not in the =20 propper encoding. The other source of such errors are =20 Apache::Request. Since anything stored there lost the utf8 flag. I think your input is somewhere not your default_input_charset. The =20 source of the problem is your database, or inputparams. Pagekit does =20 the right thing as far as I know for all sorts of input unless you =20 mix the charsets. I have working solutions for any input but it takes a while to =20 explain all of them ;-) One is to convert all my inputs from the =20 database to default_input_charset with Encode::decode or I use =20 postgres with pg_enable_utf8 ;-) the other one is the right charset =20 from __from__ fields since browsers answer in a different charset =20 from time to time. The trick is to send a hidden field with known =20 chars like '=E1' and check that first. if it is the same as '=E1' in =20 latin1 you know the encoding for all other fields easy enough other =20 wise compare to another charset. The third point is to use a own =20 Apacje::Request object to handle the utf8 flag correctly. I can show =20 a example if you like. It is really hard to handle the charset issue =20 correct. If there is a mistake you get a '?' for the char in =20 question. The form trick is explained somehow with my answers to this =20= tread on pm: http://www.perlmonks.com/index.pl?node_id=3D401315 I really know it is confusing, what version of pagekit do you use? I =20 remember there was a change to handle more wrong cases. Feel free to =20 ask more specific and I try to came up with a better description ;-) The basic problem is this: use Encode; use DBI; # setup a test database my $dbh =3D DBI->connect( "dbi:SQLite:dbname=3D/tmp/dbfile", "", "", { PrintError =3D> 0, RaiseError =3D> 1 = } ); eval { $dbh->do(q{ CREATE TABLE t_storage ( id INTEGER, str VARCHAR=20 (255) ) }) }; eval { $dbh->do(q{ DELETE FROM t_storage }) }; # and our test stringss my $str =3D 'test' . chr(0xe1); #latin1 string my $utf8_str =3D decode( 'iso-8859-1', $str ); # same string, but = utf8 compare( "compare \$str, \$utf8_str:\n", $str, $utf8_str ); # serialize the data into a database removes the utf8 flag only postgres # can handle this correct on request $dbh->do( q{ INSERT INTO t_storage VALUES ( 1, ? ) }, {}, $str ); my ($str_from_db) =3D $dbh->selectrow_array(q{ SELECT str FROM t_storage WHERE id =3D 1 }); $dbh->do( q{ INSERT INTO t_storage VALUES ( 2, ? ) }, {}, $utf8_str ); my ($utf8_str_from_db) =3D $dbh->selectrow_array(q{ SELECT str FROM t_storage WHERE id =3D 2 }); # compare again compare( "compare \$str_from_db, \$utf8_str_from_db:\n", $str_from_db, $utf8_str_from_db ); # compare again compare( "compare \$utf8_str, \$utf8_str_from_db:\n", $utf8_str, $utf8_str_from_db ); { use bytes; print "compare binary \$utf8_str, \$utf8_str_from_db:\n"; print $utf8_str eq $utf8_str_from_db ? "same" : "different", $/, $/; } # ######## ## Subs ######## sub compare { print shift; my ( $s1, $s2 ) =3D @_; # compare { use bytes; print length $s1, $/; # length $str print length $s2, $/; # length $utf8_str } # supprise for most people print $s1 eq $s2 ? "same" : "different", $/, $/; } > Thanks, > Russell > > > > _______________________________________________ > Pagekit-users mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagekit-users -- Boris |
From: Russell D. W. <rw...@in...> - 2006-06-21 18:49:12
|
Thanks, Boris. It's a fairly large application, so modifying the entire app to use the "trick" to detect the encoding that the browser is using would work, but might be a bit of a pain to build-in to the entire app. Actually, using Encode::encode and encoding to UTF8 before outputting via $model->fillinform() seemed to work and "fix" the output. I'm not sure that this is the "proper" way of doing things though. Rather than modifying the entire app and each "fillinform()" call, I was considering modifying the PageKit code that calls HTML::FillInForm and wrap the Encode::encode call into there. I'm not sure if this is a great way to go, or if it is safe in general. Actually, I don't pretend to be all that good when it comes to character sets and encoding in general. What are your thoughts on this? Thanks, Russell ----- Original Message ----- From: "Boris Zentner" <bz...@2b...> To: "Russell D. Weiss" <rw...@in...> Cc: <pag...@li...> Sent: Thursday, June 15, 2006 5:32 PM Subject: Re: [Pagekit-users] Character set or parsing issue? Hi, Am 14.06.2006 um 22:10 schrieb Russell D. Weiss: > Hello all, > > Long time no post :-). > > We've encountered the following problem in our PageKit > application. When > pulling data from a database and using $model->fillinform to > populate form > fields, we're seeing problems when the data contains certain > international > characters, such as "á" -- as well as potentially some others. > > Basically, if the word "Testá" is pulled from the database, the > HTML form > field will look like: > > <input type="text" value="Test? name="blah"> Obviously, this causes > problems, as the value is not terminated properly with a quote, and > the true > value is not shown in the form field. I tested HTML::FillInForm > separately > and this problem does not appear. The problem may be due to some > parsing > that pagekit does after it runs the the page through HTML::FillInForm. > > Boris and others, do you have any idea as to what might cause this? > I remember that problem. The reason is, that you lost the encoding of your string somewhere. mysql for example does it always wrong. Pagekit try to ship around the problem by removeing the utf8 flag before we pass the data to fillinform. and force utf8 on the result. There might be a bug or some strings in your page are not in the propper encoding. The other source of such errors are Apache::Request. Since anything stored there lost the utf8 flag. I think your input is somewhere not your default_input_charset. The source of the problem is your database, or inputparams. Pagekit does the right thing as far as I know for all sorts of input unless you mix the charsets. I have working solutions for any input but it takes a while to explain all of them ;-) One is to convert all my inputs from the database to default_input_charset with Encode::decode or I use postgres with pg_enable_utf8 ;-) the other one is the right charset from __from__ fields since browsers answer in a different charset from time to time. The trick is to send a hidden field with known chars like 'á' and check that first. if it is the same as 'á' in latin1 you know the encoding for all other fields easy enough other wise compare to another charset. The third point is to use a own Apacje::Request object to handle the utf8 flag correctly. I can show a example if you like. It is really hard to handle the charset issue correct. If there is a mistake you get a '?' for the char in question. The form trick is explained somehow with my answers to this tread on pm: http://www.perlmonks.com/index.pl?node_id=401315 I really know it is confusing, what version of pagekit do you use? I remember there was a change to handle more wrong cases. Feel free to ask more specific and I try to came up with a better description ;-) The basic problem is this: use Encode; use DBI; # setup a test database my $dbh = DBI->connect( "dbi:SQLite:dbname=/tmp/dbfile", "", "", { PrintError => 0, RaiseError => 1 } ); eval { $dbh->do(q{ CREATE TABLE t_storage ( id INTEGER, str VARCHAR (255) ) }) }; eval { $dbh->do(q{ DELETE FROM t_storage }) }; # and our test stringss my $str = 'test' . chr(0xe1); #latin1 string my $utf8_str = decode( 'iso-8859-1', $str ); # same string, but utf8 compare( "compare \$str, \$utf8_str:\n", $str, $utf8_str ); # serialize the data into a database removes the utf8 flag only postgres # can handle this correct on request $dbh->do( q{ INSERT INTO t_storage VALUES ( 1, ? ) }, {}, $str ); my ($str_from_db) = $dbh->selectrow_array(q{ SELECT str FROM t_storage WHERE id = 1 }); $dbh->do( q{ INSERT INTO t_storage VALUES ( 2, ? ) }, {}, $utf8_str ); my ($utf8_str_from_db) = $dbh->selectrow_array(q{ SELECT str FROM t_storage WHERE id = 2 }); # compare again compare( "compare \$str_from_db, \$utf8_str_from_db:\n", $str_from_db, $utf8_str_from_db ); # compare again compare( "compare \$utf8_str, \$utf8_str_from_db:\n", $utf8_str, $utf8_str_from_db ); { use bytes; print "compare binary \$utf8_str, \$utf8_str_from_db:\n"; print $utf8_str eq $utf8_str_from_db ? "same" : "different", $/, $/; } # ######## ## Subs ######## sub compare { print shift; my ( $s1, $s2 ) = @_; # compare { use bytes; print length $s1, $/; # length $str print length $s2, $/; # length $utf8_str } # supprise for most people print $s1 eq $s2 ? "same" : "different", $/, $/; } > Thanks, > Russell > > > > _______________________________________________ > Pagekit-users mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagekit-users -- Boris _______________________________________________ Pagekit-users mailing list Pag...@li... https://lists.sourceforge.net/lists/listinfo/pagekit-users |
From: Boris Z. <bz...@2b...> - 2006-06-21 21:48:21
|
Hi Russell, Am 21.06.2006 um 20:48 schrieb Russell D. Weiss: > Thanks, Boris. > > It's a fairly large application, so modifying the entire app to use =20= > the > "trick" to detect the encoding that the browser is using would =20 > work, but > might be a bit of a pain to build-in to the entire app. > Not really, just build your own class, that acts like =20 Apache2::Request and point A::P in your global config to that class =20 (see: request_class). In that case you have only one place to edit =20 for your whole app. > Actually, using Encode::encode and encoding to UTF8 before =20 > outputting via > $model->fillinform() seemed to work and "fix" the output. I'm not =20 > sure that Just overload fillinform. This might fix the problem, but the source =20 of the error still remains. But if all your data is in the right format, this is unneeded. > > this is the "proper" way of doing things though. Rather than =20 > modifying the > entire app and each "fillinform()" call, I was considering =20 > modifying the No, just replace fillinfoerm in your modelcode and call $m-=20 >SUPER::fillinform later. > PageKit code that calls HTML::FillInForm and wrap the =20 > Encode::encode call > into there. I'm not sure if this is a great way to go, or if it is =20= > safe in > general. Actually, I don't pretend to be all that good when it =20 > comes to > character sets and encoding in general. > character encoding is a big pain. Your goal must be, that all input =20 is in one charset. my choice is always utf8. This means that my =20 database provide utf8 data my templtes are in utf8 and my data too. =20 Whenever my data came from a unsure datasource like a database I =20 check once if the utf8flag is set for utf8 data. if so im happy. =20 otherwise I check if the binary data is utf8. if so I just set the =20 utf8 flag and Im done. otherwise I convert the data with the =20 Encode::decode function. All this has to be done only once. Form data is a bit more difficult and need more checks. Thats where =20 the A::P::R class takes place. Look for a example at the first lines =20 of the Apache2/PageKit.pm file. > What are your thoughts on this? your big helper's here are Encode::decode, Encode::encode, Encode::is_utf8, Encode::_utf8_on, =20 Encode::_utf8_off Devel::Peek::Dump and the DBI qw(:utils) functions DBI::data_string_desc DBI::data_diff if you put some hours in your request_class most if not all your =20 problems go away. > > Thanks, > Russell > > ----- Original Message ----- > From: "Boris Zentner" <bz...@2b...> > To: "Russell D. Weiss" <rw...@in...> > Cc: <pag...@li...> > Sent: Thursday, June 15, 2006 5:32 PM > Subject: Re: [Pagekit-users] Character set or parsing issue? > > > Hi, > > Am 14.06.2006 um 22:10 schrieb Russell D. Weiss: > >> Hello all, >> >> Long time no post :-). >> >> We've encountered the following problem in our PageKit >> application. When >> pulling data from a database and using $model->fillinform to >> populate form >> fields, we're seeing problems when the data contains certain >> international >> characters, such as "=E1" -- as well as potentially some others. >> >> Basically, if the word "Test=E1" is pulled from the database, the >> HTML form >> field will look like: >> >> <input type=3D"text" value=3D"Test? name=3D"blah"> Obviously, this = causes >> problems, as the value is not terminated properly with a quote, and >> the true >> value is not shown in the form field. I tested HTML::FillInForm >> separately >> and this problem does not appear. The problem may be due to some >> parsing >> that pagekit does after it runs the the page through =20 >> HTML::FillInForm. >> >> Boris and others, do you have any idea as to what might cause this? >> > > I remember that problem. The reason is, that you lost the encoding of > your string somewhere. mysql for example does it always wrong. > Pagekit try to ship around the problem by removeing the utf8 flag > before we pass the data to fillinform. and force utf8 on the result. > There might be a bug or some strings in your page are not in the > propper encoding. The other source of such errors are > Apache::Request. Since anything stored there lost the utf8 flag. > > I think your input is somewhere not your default_input_charset. The > source of the problem is your database, or inputparams. Pagekit does > the right thing as far as I know for all sorts of input unless you > mix the charsets. > > I have working solutions for any input but it takes a while to > explain all of them ;-) One is to convert all my inputs from the > database to default_input_charset with Encode::decode or I use > postgres with pg_enable_utf8 ;-) the other one is the right charset > from __from__ fields since browsers answer in a different charset > from time to time. The trick is to send a hidden field with known > chars like '=E1' and check that first. if it is the same as '=E1' in > latin1 you know the encoding for all other fields easy enough other > wise compare to another charset. The third point is to use a own > Apacje::Request object to handle the utf8 flag correctly. I can show > a example if you like. It is really hard to handle the charset issue > correct. If there is a mistake you get a '?' for the char in > question. The form trick is explained somehow with my answers to this > tread on pm: > > http://www.perlmonks.com/index.pl?node_id=3D401315 > > I really know it is confusing, what version of pagekit do you use? I > remember there was a change to handle more wrong cases. Feel free to > ask more specific and I try to came up with a better description ;-) > > The basic problem is this: > > use Encode; > use DBI; > > # setup a test database > my $dbh =3D DBI->connect( "dbi:SQLite:dbname=3D/tmp/dbfile", > "", "", { PrintError =3D> 0, RaiseError =3D> =20= > 1 } ); > eval { $dbh->do(q{ CREATE TABLE t_storage ( id INTEGER, str VARCHAR > (255) ) }) }; > eval { $dbh->do(q{ DELETE FROM t_storage }) }; > > # and our test stringss > my $str =3D 'test' . chr(0xe1); #latin1 string > my $utf8_str =3D decode( 'iso-8859-1', $str ); # same string, but =20= > utf8 > > compare( "compare \$str, \$utf8_str:\n", $str, $utf8_str ); > > # serialize the data into a database removes the utf8 flag only =20 > postgres > # can handle this correct on request > $dbh->do( q{ INSERT INTO t_storage VALUES ( 1, ? ) }, {}, $str ); > my ($str_from_db) =3D > $dbh->selectrow_array(q{ SELECT str FROM t_storage WHERE id =3D 1 = }); > $dbh->do( q{ INSERT INTO t_storage VALUES ( 2, ? ) }, {}, $utf8_str ); > my ($utf8_str_from_db) =3D > $dbh->selectrow_array(q{ SELECT str FROM t_storage WHERE id =3D 2 = }); > > # compare again > compare( "compare \$str_from_db, \$utf8_str_from_db:\n", > $str_from_db, $utf8_str_from_db ); > > # compare again > compare( "compare \$utf8_str, \$utf8_str_from_db:\n", > $utf8_str, $utf8_str_from_db ); > > { > use bytes; > print "compare binary \$utf8_str, \$utf8_str_from_db:\n"; > print $utf8_str eq $utf8_str_from_db ? "same" : "different", $/, =20= > $/; > } > > # > > ######## > ## Subs > ######## > sub compare { > print shift; > my ( $s1, $s2 ) =3D @_; > > # compare > { > use bytes; > print length $s1, $/; # length $str > print length $s2, $/; # length $utf8_str > } > > # supprise for most people > print $s1 eq $s2 ? "same" : "different", $/, $/; > } > > > >> Thanks, >> Russell >> >> >> >> _______________________________________________ >> Pagekit-users mailing list >> Pag...@li... >> https://lists.sourceforge.net/lists/listinfo/pagekit-users > > -- > Boris > > > > > _______________________________________________ > Pagekit-users mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagekit-users > > > All the advantages of Linux Managed Hosting--Without the Cost and =20 > Risk! > Fully trained technicians. The highest number of Red Hat =20 > certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?=20 > cmd=3Dlnk&kid=3D107521&bid=3D248729&dat=3D121642 > _______________________________________________ > Pagekit-users mailing list > Pag...@li... > https://lists.sourceforge.net/lists/listinfo/pagekit-users -- Boris |