[27781] in Perl-Users-Digest
Perl-Users Digest, Issue: 9145 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Apr 11 18:05:42 2006
Date: Tue, 11 Apr 2006 15:05:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 11 Apr 2006 Volume: 10 Number: 9145
Today's topics:
Re: CGI.pm annoying xHTML output <john@castleamber.com>
Re: CGI.pm annoying xHTML output <null@no.spam>
Re: CGI.pm annoying xHTML output <1usa@llenroc.ude.invalid>
Re: EXAMPLE -- Re: Strange issue with `CHOMP' not worki <tadmc@augustmail.com>
Re: EXAMPLE -- Re: Strange issue with `CHOMP' not worki <ignoramus10782@NOSPAM.10782.invalid>
Re: Strange issue with `CHOMP' not working... <hjp-usenet2@hjp.at>
Re: Strange issue with `CHOMP' not working... <ignoramus10782@NOSPAM.10782.invalid>
Re: tr/// broken? <nospam-abuse@ilyaz.org>
Re: tr/// broken? <rvtol+news@isolution.nl>
Re: tr/// broken? <thundergnat@hotmail.com>
Re: tr/// broken? <nospam-abuse@ilyaz.org>
Re: tr/// broken? <nospam-abuse@ilyaz.org>
Re: XS progamming question <nospam-abuse@ilyaz.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 11 Apr 2006 15:19:39 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: CGI.pm annoying xHTML output
Message-Id: <Xns97A2690D11E88castleamber@130.133.1.4>
FrankB <you.can@request.net> wrote:
> Glenn Jackman formulated the question :
>> At 2006-04-11 06:56AM, FrankB <you.can@request.net> wrote:
>>> Hello,
>>>
>>> when creating a form with CGI.pm, no matter if it is
>>> use CGI;
>>> $q = new CGI qw /:all -debug/;
>>
>> Those lines should read:
>> use CGI qw/:all -debug/;
>> my $q = new CGI;
>
> Ok.
> Is the lexical variable really mandatory ?
If you have put use strict; and use warnings; before use CGI ..., yes.
Also, I recommend to call the variable $cgi instead of $q (or $query).
> Thanks, and I indeed didn't think about checking the module itself..
> (smashes forehead)
Stuff like this *should* be documented IMO.
One final remark: request.net is probably not your domain (if it is, skip
this). Don't abuse a domain you don't own. Use invalid as tld.
--
John Bokma Freelance software developer
&
Experienced Perl programmer: http://castleamber.com/
------------------------------
Date: Tue, 11 Apr 2006 11:32:50 -0500
From: Todd <null@no.spam>
Subject: Re: CGI.pm annoying xHTML output
Message-Id: <e1glni$ks3$3@home.itg.ti.com>
Todd wrote:
> FrankB wrote:
>> Hello,
>>
>> when creating a form with CGI.pm, no matter if it is
>> use CGI;
>> $q = new CGI qw /:all -debug/;
>> print header and start the html etc..
>>
>> print $q->start_form; OR
>> print $q->start_multipart_form();
>> print $q->textfield('blah');
>> print $q->end_form;
>> #etc..
>>
>> it *always* returns an obsolete trailing HTML "<div></div>" container
>> before the closing tag of the form.
>>
>> Any ideas ? It seems not to be
>> a known issue.
>>
>> (Perl 5.8.1 on linux)
>> --
>> FrankB
>>
>>
> Are you using the latest version of CGI? That problem went away when I
> installed 3.15.
>
> Todd
It was fixed in 3.12 (#8):
Todd
http://search.cpan.org/src/LDS/CGI.pm-3.17/Changes
Version 3.12
1. Fixed virtual_port so that it works properly with https protocol.
2. Fixed documentation for upload_hook().
3. Added POSTDATA documentation.
4. Made upload_hook() work in function-oriented mode.
5. Fixed POST_MAX behavior so that it doesn't cause client to hang.
6. Disabled automatic tab indexes and added new -tabindex pragma to
turn automatic indexes back on.
7. The url() and self_url() methods now work better in the context
of Apache
mod_rewrite. Be advised that path_info() may give you confusing
results
when mod_rewrite is active because Apache calculates the path
info *after*
rewriting. This is mostly worked around in url() and self_url(),
but you
may notice some anomalies.
8. Removed empty (and non-validating) <div> from code emitted by
end_form().
9. Fixed CGI::Carp to work correctly with Mod_perl 1.29 in an
Apache 2 environment.
10. Setting $CGI::TMPDIRECTORY should now be effective.
------------------------------
Date: Tue, 11 Apr 2006 18:33:02 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: CGI.pm annoying xHTML output
Message-Id: <Xns97A29429589E6asu1cornelledu@127.0.0.1>
FrankB <you.can@request.net> wrote in news:mn.5b087d648a5db7f5.52380
@request.net:
> Hello,
Don't multi-post.
http://lipas.uwasa.fi/~ts/http/crospost.html
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Tue, 11 Apr 2006 10:47:56 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: EXAMPLE -- Re: Strange issue with `CHOMP' not working...
Message-Id: <slrne3njtc.6r4.tadmc@magna.augustmail.com>
John W. Krahn <someone@example.com> wrote:
> Ignoramus20015 wrote:
>> if( !($dir =~ /^\// ) ) {
>
> Or simply:
>
> if( $dir !~ /^\// ) {
Or:
unless ( $dir =~ /^\// ) {
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Tue, 11 Apr 2006 16:21:03 GMT
From: Ignoramus10782 <ignoramus10782@NOSPAM.10782.invalid>
Subject: Re: EXAMPLE -- Re: Strange issue with `CHOMP' not working...
Message-Id: <PHQ_f.63869$7F6.60712@fe14.usenetserver.com>
I rewrote my module to make it slightly nicer.
Not sure if anyone is interested, but here it is:
======================================================================
package Algebra::Config;
use strict;
require Exporter;
use vars qw($VERSION @ISA @EXPORT @EXPORT_OK %EXPORT_TAGS);
@ISA = qw(Exporter);
@EXPORT= qw( get_config_var get_data_dir get_algebra_root );
@EXPORT_OK = qw( get_config_var );
$VERSION = 2000.0426;
use vars qw( $algebra_data_dir $_values );
sub get_algebra_root {
my $algebra_root = $ENV{'ALGEBRA_ROOT'} || $ENV{'DOCUMENT_ROOT'}
|| die "Webmaster has to define ALGEBRA_ROOT environment variable!";
return $algebra_root;
}
sub get_config_var {
my ($category, $variable) = @_;
return $_values->{$category}->{$variable} if exists $_values->{$category}->{$variable};
my $algebra_root = get_algebra_root;
my $config_file = "$algebra_root/etc/$category";
open( CONFIG, $config_file ) or die "Config file '$config_file' does not exist or is not readable.";
while ( $_ = <CONFIG> ) {
chomp;
if ( /(\n|\r)/ ) {
my $str = substr( $_, 0, 80 );
print STDERR "Algebra::Config: BAD BAD BAD Input string after chomp but BEFORE regex: '$str'.\n";
}
s/(\n|\r)//g;
next if( /^\s*#/ );
next if( /^\s*$/ );
my( $key, $value ) = split( /\s*=\s*/, $_ );
$_values->{$category}->{$key} = $value;
}
close( CONFIG );
return $_values->{$category}->{$variable} if exists $_values->{$category}->{$variable};
$_values->{$category}->{$variable} = undef;
return undef;
}
sub get_data_dir {
my ($category, $variable) = @_;
my $dir = get_config_var( $category, $variable );
if ( $dir !~ /^\// ) {
$dir = $algebra_data_dir . "/$dir";
}
return $dir;
}
$algebra_data_dir = get_config_var( "general", "algebra_data_dir" ) || $ENV{ALGEBRA_ROOT};
$_values = {};
1;
------------------------------
Date: Tue, 11 Apr 2006 21:14:40 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Strange issue with `CHOMP' not working...
Message-Id: <07vg1e.3md.ln@teal.hjp.at>
Ignoramus20015 wrote:
> On 10 Apr 2006 16:09:23 GMT, xhoster@gmail.com <xhoster@gmail.com>
> wrote:
>> Ignoramus20015 <ignoramus20015@NOSPAM.20015.invalid> wrote:
>>> I have a mod_perl based website algebra.com. In a few places, it
>>> does 'chomp' when it reads various files.
>>>
>>> It all worked fine for years and I had not touched any code lately,
>>> especially nothing related to chomp.
[...]
> Well, the problems are with reading config files on my local disk, not
> user submitted data. I just checked dates on some of them, they are
> quite old and have not changed.
Maybe you restarted the server with wrong environment settings? I
managed to start qpsmtpd-forkserker with PERL_UNICODE set some time ago,
which had a rather surprising effect on the mails passed through it :-)
Older versions of the HP-UX printing system also didn't like the LANG
variable being set (that's not written in perl, though).
hp
--
_ | Peter J. Holzer | Löschung von at.usenet.schmankerl?
|_|_) | Sysadmin WSR/LUGA |
| | | hjp@hjp.at | Diskussion derzeit in at.usenet.gruppen
__/ | http://www.hjp.at/ |
------------------------------
Date: Tue, 11 Apr 2006 19:33:18 GMT
From: Ignoramus10782 <ignoramus10782@NOSPAM.10782.invalid>
Subject: Re: Strange issue with `CHOMP' not working...
Message-Id: <2wT_f.628$DR1.150@fe27.usenetserver.com>
On Tue, 11 Apr 2006 21:14:40 +0200, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> Ignoramus20015 wrote:
>> On 10 Apr 2006 16:09:23 GMT, xhoster@gmail.com <xhoster@gmail.com>
>> wrote:
>>> Ignoramus20015 <ignoramus20015@NOSPAM.20015.invalid> wrote:
>>>> I have a mod_perl based website algebra.com. In a few places, it
>>>> does 'chomp' when it reads various files.
>>>>
>>>> It all worked fine for years and I had not touched any code lately,
>>>> especially nothing related to chomp.
> [...]
>> Well, the problems are with reading config files on my local disk, not
>> user submitted data. I just checked dates on some of them, they are
>> quite old and have not changed.
>
> Maybe you restarted the server with wrong environment settings? I
> managed to start qpsmtpd-forkserker with PERL_UNICODE set some time ago,
> which had a rather surprising effect on the mails passed through it :-)
>
> Older versions of the HP-UX printing system also didn't like the LANG
> variable being set (that's not written in perl, though).
Thanks... The bug would show up after the server runs for a little
while. I think that my bug was that I was opening that file often, and
neglected to close it. That probably caused this strange behavior
after a while by overflowing something or other. Since I cleaned up
that module, the bug does yet have to manifest itself.
i
------------------------------
Date: Tue, 11 Apr 2006 16:17:49 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: tr/// broken?
Message-Id: <e1gkrd$2hr$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
<zbrg@mail.invalid>], who wrote in article <443b8741$0$5170$626a54ce@news.free.fr>:
> > >perl5.8.7 -wle "$_ = q(abcdefg); tr/\x{e000}-\x{e0ff}/ /c; print"
> > UTF-16 surrogate 0xdfff at -e line 1.
> > Malformed UTF-8 character (UTF-16 surrogate 0xdfff) at -e line 1.
> > abcdefg
> >That spurious warning can be worked about, but I think the behaviour
> >is not up to documentation; is it?
> Its in the perldiag manpage :
>
> UTF-16 surrogate %s
> (W utf8) You tried to generate half ...
First of all, I assume that "its" is this broken warning (actually,
one of two [duplicate] warnings). Since it does not apply to the
situation I discuss, I can hardly find your finding this message in
the list of warnings relevant.
Second, what I was discussing was not the warning, but the ACTION. Do
you think the RESULT ('abcdefg') is "correct"?
Thanks anyway,
Ilya
P.S. Actually, the text in perldiag is also wrong:
> of an UTF-16 surrogate by requesting a Unicode character between the
> code points 0xD800 and 0xDFFF (inclusive). That range is reserved
> exclusively for the use of UTF-16 encoding (by having two 16- bit
> UCS-2 characters); but Perl encodes its characters in UTF-8, so what
> you got is a very illegal character. If you really know what you
> are doing you can turn off this warning by "no warnings 'utf8';".
Perl (the language) does not encode its characters in UTF-8.
Characters are not encoded in any way, they just "are". And, if you
consider implementation, the internal encoding is not UTF-8 either (it
is called in perl world as "utf8", and is a proper superset). Sigh...
------------------------------
Date: Tue, 11 Apr 2006 18:46:56 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: tr/// broken?
Message-Id: <e1gu0l.1m4.1@news.isolution.nl>
Ilya Zakharevich schreef:
> I'm trying to use tr/// operator (instead of RExen), and do not think
> it works... The simplified example is
>
> >perl5.8.7 -wle "$_ = q(abcdefg); tr/\x{e000}-\x{e0ff}/ /c; print"
> UTF-16 surrogate 0xdfff at -e line 1.
> Malformed UTF-8 character (UTF-16 surrogate 0xdfff) at -e line 1.
> abcdefg
>
> The original code contained something like
>
> perl5.8.7 -wle "$_ = qq(abcd\x{e155}efg);
> tr/\x{e100}-\x{e1ff}\x00-\x{1FFFFF}/\x00-\xFF_/; print"
> Unicode character 0x1fffff is illegal at -e line 1.
> ________
>
> That spurious warning can be worked about,
Is it a "spurious warning"?
perl -MO=Deparse -e '$_ = qq(\x{d7ff}\x{d800})'
perl -MO=Deparse -e 'tr/\x{d7ff}\x{d800}//'
> but I think the behaviour
> is not up to documentation; is it?
It isn't.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Tue, 11 Apr 2006 15:53:13 -0400
From: thundergnat <thundergnat@hotmail.com>
Subject: Re: tr/// broken?
Message-Id: <g8idnSdjQ4e2lKHZRVn-iw@rcn.net>
Ilya Zakharevich wrote:
> I'm trying to use tr/// operator (instead of RExen), and do not think
> it works... The simplified example is
>
> >perl5.8.7 -wle "$_ = q(abcdefg); tr/\x{e000}-\x{e0ff}/ /c; print"
> UTF-16 surrogate 0xdfff at -e line 1.
> Malformed UTF-8 character (UTF-16 surrogate 0xdfff) at -e line 1.
> abcdefg
>
> The original code contained something like
>
> perl5.8.7 -wle "$_ = qq(abcd\x{e155}efg);
> tr/\x{e100}-\x{e1ff}\x00-\x{1FFFFF}/\x00-\xFF_/; print"
> Unicode character 0x1fffff is illegal at -e line 1.
> ________
>
> That spurious warning can be worked about, but I think the behaviour
> is not up to documentation; is it?
>
It /does/ appear to be a bug in tr. Not in that it has a problem with
characters in the range D800–DFFF, that doesn't surprise me much. Those
/aren't/ legal utf-8 character codes. The thing that DOES surprise me is
that tr considers \x{e000} (and \x{d7ff}!) to be in the range
\x{d800}-\x{dfff}. Seems like tr is confused about the surrogates range.
no error:
perl -wle "$_ = q(abcdefg); tr/\x{e001}-\x{e0ff}/ /c; print"
error
perl -wle "$_ = q(abcdefg); tr/\x{e000}/ /c; print"
error
perl -wle "$_ = q(abcdefg); tr/\x{d7ff}/ /c; print"
no error
perl -wle "$_ = q(abcdefg); tr/\x{d7fe}/ /c; print"
------------------------------
Date: Tue, 11 Apr 2006 21:56:39 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: tr/// broken?
Message-Id: <e1h8mn$90n$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Dr.Ruud
<rvtol+news@isolution.nl>], who wrote in article <e1gu0l.1m4.1@news.isolution.nl>:
> > The original code contained something like
> >
> > perl5.8.7 -wle "$_ = qq(abcd\x{e155}efg);
> > tr/\x{e100}-\x{e1ff}\x00-\x{1FFFFF}/\x00-\xFF_/; print"
> > Unicode character 0x1fffff is illegal at -e line 1.
> > ________
> >
> > That spurious warning can be worked about,
>
> Is it a "spurious warning"?
Looks so. What makes you doubt it? I'm working with Perl characters,
not Unicode characters; and IIRC, even Unicode goes up to 0x1fffff...
Or is it 0x10ffff?
> perl -MO=Deparse -e 'tr/\x{d7ff}\x{d800}//'
What is your point? I do not see which output makes you think this is
relevant... Did you try
perl -MO=Deparse -e 'tr/\x{7ff}\x{800}//'
Thanks,
Ilya
------------------------------
Date: Tue, 11 Apr 2006 22:04:28 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: tr/// broken?
Message-Id: <e1h95c$979$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Dr.Ruud
<rvtol+news@isolution.nl>], who wrote in article <e1gu0l.1m4.1@news.isolution.nl>:
> Is it a "spurious warning"?
> perl -MO=Deparse -e 'tr/\x{d7ff}\x{d800}//'
Oups, ignore my preceeding message; I was using wrong quotes... So I
see now where the Perl bug is:
>perl -MO=Deparse -e "tr/\x{0000}-\x{ffff}//"
Malformed UTF-8 character (character 0xffff) at -e line 1.
Malformed UTF-8 character (character 0xffff) at -e line 1.
use utf8 ();
tr/\000//;
-e syntax OK
>perl -MO=Deparse -e "tr/\x{0000}-\x{fff0}//"
use utf8 ();
tr/\000-\x{fff0}//;
-e syntax OK
So some Perl developer thought that Perl characters == Unicode
characters, and mangles the pattern without reporting errors...
A lot of thanks,
Ilya
------------------------------
Date: Tue, 11 Apr 2006 16:25:09 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: XS progamming question
Message-Id: <e1gl95$2ju$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Ferry Bolhar
<bol@adv.magwien.gv.at>], who wrote in article <1144757709.228745@proxy.dienste.wien.at>:
> > perl -wle "sub aa {print 12} BEGIN{ delete $main::{aa} } aa()"
> > Undefined subroutine &main::aa called at -e line 1.
> > But make sure that the glob is removed BEFORE any call to these
> > subroutines is compiled.
> Why? What will happen else?
Check it yourselves. Removing globs from symbol tables has no effect
on already compiled code referencing these globs - the code tree
already contains C pointers to the globs (I mean access to global
vars, arrays, hashes, subroutines etc), it won't go through symbol
tables again.
Hope this helps,
Ilya
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9145
***************************************
