[25971] in Perl-Users-Digest
Perl-Users Digest, Issue: 8190 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jun 21 21:05:29 2005
Date: Tue, 21 Jun 2005 18:05:12 -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, 21 Jun 2005 Volume: 10 Number: 8190
Today's topics:
Re: "use CGI " hangs "CGI time out " <no@email.com>
Re: "use CGI " hangs "CGI time out " <a.newmane.remove@eastcoastcz.com>
[OT] Re: "use CGI " hangs "CGI time out " <1usa@llenroc.ude.invalid>
Re: [OT] Re: "use CGI " hangs "CGI time out " <No_4@dsl.pipex.com>
Re: [OT] Re: "use CGI " hangs "CGI time out " <ebohlman@omsdev.com>
Re: [OT] Re: "use CGI " hangs "CGI time out " <1usa@llenroc.ude.invalid>
Re: concatenating strings or sprintf? <tadmc@augustmail.com>
DBD::mysql problem <slake2@ns.sympatico.ca>
Re: Email Address Validation <abigail@abigail.nl>
Re: Fixed: ActiveState: Can't spawn "cmd.exe"? <occitan@esperanto.org>
Re: Fixed: ActiveState: Can't spawn "cmd.exe"? <1usa@llenroc.ude.invalid>
Re: Fixed: ActiveState: Can't spawn "cmd.exe"? <occitan@esperanto.org>
Re: Q for the old-timers: antecedents to the ST? <socyl@987jk.com.invalid>
what's the right way to encode this? <sun_tong@users.sourceforge.net>
Re: what's the right way to encode this? <1usa@llenroc.ude.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 20 Jun 2005 16:15:55 +0100
From: Brian Wakem <no@email.com>
Subject: Re: "use CGI " hangs "CGI time out "
Message-Id: <3ho4tbFi2c2qU1@individual.net>
A. Sinan Unur wrote:
> "GMI" <Admin@GoMonitor.com> wrote in
> news:11bdj7n7uacn26d@corp.supernews.com:
>
>
>>my $ErrMsg,$ErrNo=0, $ID ;
>>my $PassWord,$fName,$lName;
>
>
> You should always declare variables in the smallest applicable scope,
> and name them so they are readable.
>
>
> Sinan
It's also worth pointing out that when using strict, 4 errors will occur
in the above two lines as the my only applies to the first variable in
each case.
--
Brian Wakem
------------------------------
Date: Tue, 21 Jun 2005 15:40:39 -0700
From: "Alfred Z. Newmane" <a.newmane.remove@eastcoastcz.com>
Subject: Re: "use CGI " hangs "CGI time out "
Message-Id: <3hrjbkFijpa1U1@individual.net>
Brian Wakem wrote:
> A. Sinan Unur wrote:
>> "GMI" <Admin@GoMonitor.com> wrote in
>> news:11bdj7n7uacn26d@corp.supernews.com:
>>
>>
>>> my $ErrMsg,$ErrNo=0, $ID ;
>>> my $PassWord,$fName,$lName;
>>
>>
>> You should always declare variables in the smallest applicable scope,
>> and name them so they are readable.
>>
>>
>> Sinan
>
>
> It's also worth pointing out that when using strict, 4 errors will
> occur in the above two lines as the my only applies to the first
> variable in each case.
True. I believe thats an error that cna come from spending a long time
with langs like C or C++, wher you can start with the typename and have
a comma delimited list of variables taking that type:
int a,b,c;
All that needs to be done with thw code in question is add ()'s around
the variable list:
(Also note the initialization of $ErrNo=0 had to be corrected as well.)
my ($ErrMsg, $ErrNo, $ID) = (undef, 0);
my ($PassWord, $fName, $lName);
------------------------------
Date: Tue, 21 Jun 2005 23:30:48 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: [OT] Re: "use CGI " hangs "CGI time out "
Message-Id: <Xns967CC680440A0asu1cornelledu@127.0.0.1>
"Alfred Z. Newmane" <a.newmane.remove@eastcoastcz.com> wrote in
news:3hrjbkFijpa1U1@individual.net:
> Brian Wakem wrote:
>> A. Sinan Unur wrote:
>>> "GMI" <Admin@GoMonitor.com> wrote in
>>> news:11bdj7n7uacn26d@corp.supernews.com:
>>>
>>>
>>>> my $ErrMsg,$ErrNo=0, $ID ;
>>>> my $PassWord,$fName,$lName;
>>>
>>>
>>> You should always declare variables in the smallest applicable
>>> scope, and name them so they are readable.
>>>
>>>
>>> Sinan
>>
>>
>> It's also worth pointing out that when using strict, 4 errors will
>> occur in the above two lines as the my only applies to the first
>> variable in each case.
>
> True. I believe thats an error that cna come from spending a long time
> with langs like C or C++, wher you can start with the typename and
> have a comma delimited list of variables taking that type:
>
> int a,b,c;
How about:
int* a, b;
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Wed, 22 Jun 2005 00:56:27 +0100
From: Big and Blue <No_4@dsl.pipex.com>
Subject: Re: [OT] Re: "use CGI " hangs "CGI time out "
Message-Id: <o9SdnTouP_a2NCXfRVnygQ@pipex.net>
A. Sinan Unur wrote:
>
> How about:
>
> int* a, b;
One reason to always write "int *a, b;" (in C, since you would never
declare a or b scalars in Perl).
--
Just because I've written it doesn't mean that
either you or I have to believe it.
------------------------------
Date: 22 Jun 2005 00:22:48 GMT
From: Eric Bohlman <ebohlman@omsdev.com>
Subject: Re: [OT] Re: "use CGI " hangs "CGI time out "
Message-Id: <Xns967CC6A41363Aebohlmanomsdevcom@130.133.1.4>
"A. Sinan Unur" <1usa@llenroc.ude.invalid> wrote in
news:Xns967CC680440A0asu1cornelledu@127.0.0.1:
> "Alfred Z. Newmane" <a.newmane.remove@eastcoastcz.com> wrote in
> news:3hrjbkFijpa1U1@individual.net:
>> True. I believe thats an error that cna come from spending a long time
>> with langs like C or C++, wher you can start with the typename and
>> have a comma delimited list of variables taking that type:
>>
>> int a,b,c;
>
> How about:
>
> int* a, b;
[now getting hopelessly OT]
I got in the habit of writing "type *v" rather than "type* v", reading it
as "the thing v points to is this type" (which, IIRC, is actually how K&R
explained it). "int *a, b;" reads to me unambiguously as "both the
thingy a points to and b are integers" without implying that b is a
pointer. The underlying concept is that pointeritude[tm] and type are
parallel attributes of a variable, rather than pointeritude being an
attribute of type, and therefore the indicator of pointeritude should be
closer to the variable name than the type name.
------------------------------
Date: Wed, 22 Jun 2005 00:28:59 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: [OT] Re: "use CGI " hangs "CGI time out "
Message-Id: <Xns967CD05CEE40Casu1cornelledu@127.0.0.1>
Eric Bohlman <ebohlman@omsdev.com> wrote in
news:Xns967CC6A41363Aebohlmanomsdevcom@130.133.1.4:
> "A. Sinan Unur" <1usa@llenroc.ude.invalid> wrote in
> news:Xns967CC680440A0asu1cornelledu@127.0.0.1:
...
>> How about:
>>
>> int* a, b;
>
> [now getting hopelessly OT]
>
> I got in the habit of writing "type *v" rather than "type* v", reading
> it as "the thing v points to is this type" (which, IIRC, is actually
> how K&R explained it).
I agree, and that's the style I use as well. However, my remark was
related to the following:
#"Alfred Z. Newmane" <a.newmane.remove@eastcoastcz.com> wrote in
# news:3hrjbkFijpa1U1@individual.net:
#
#>>> "GMI" <Admin@GoMonitor.com> wrote in
#>>> news:11bdj7n7uacn26d@corp.supernews.com:
#>>>
#>>>> my $ErrMsg,$ErrNo=0, $ID ;
#>>>> my $PassWord,$fName,$lName;
#
# I believe thats an error that cna come from spending a long time
# with langs like C or C++, wher you can start with the typename
# and have a comma delimited list of variables taking that type:
I was trying to point out that similar errors can be made in C as well.
Anyway, sorry for the drift.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Mon, 20 Jun 2005 09:21:17 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: concatenating strings or sprintf?
Message-Id: <slrndbdk6t.ll2.tadmc@magna.augustmail.com>
Jens Luedicke <jens.luedicke@gmail.com> wrote:
> I have a stupid question, what is more efficient to glue strings
> together? using the . operator or sprintf()?
use Benchmark;
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 20 Jun 2005 16:29:42 GMT
From: "Stephen Lake" <slake2@ns.sympatico.ca>
Subject: DBD::mysql problem
Message-Id: <W9Cte.49787$Ph4.1341060@ursa-nb00s0.nbnet.nb.ca>
Hi all,
i am having a small problem with rows in the DBD::mysql module.
more specifically, what I am trying to do is to insert a value in a mysql
table ONLY if it does NOT exist in there already. Now I know the queries are
working ok but its the num rows thats not evaluating properly and thus I am
getting duplicates in the table that I do not want.
I have read the DBD::mysql doc at CPAN but that didn't solve my problem and
have read the perldoc specifically the sections on Operators and Control
Structures and everything here seems to be in accordance with how its
suppose to be done.
Here is a piece of code that I have and that the problem is manifesting
itself in:
======================================
my $qb = $dbh->prepare("SELECT * FROM stockIndex WHERE pSymbol='$sym'");
$qb->execute;
if($qb->rows()==0) {
if(!$dbh->do("INSERT INTO stockIndex(pSymbol) VALUES('$sym')"))
{
print $dbh->errstr;
}
}
$qb->finish();
=======================================
Can anyone please point out the error in here or give me any idea of what is
going wrong?
Thanx
Steve
------------------------------
Date: 21 Jun 2005 20:57:41 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Email Address Validation
Message-Id: <slrndbgvq4.14f.abigail@alexandra.abigail.nl>
Bob (goff1234@NOSPAM.ntlworld.com) wrote on MMMMCCCXII September MCMXCIII
in <URL:news:a8cgb199n957ue9ucgvmn7anrg3jot5aui@4ax.com>:
][ I am not a code type guy, and the code below was given to me it works
][ but what I would like to do is put in some sort of email address
][ validation as I am not a coder I need as much help as I can get and
][ any help would be better than none.
Hire a coder.
Abigail
--
($;,$_,$|,$\)=("\@\x7Fy~*kde~box*Zoxf*Bkiaox"," "x25,1,"\r");
{vec($_=>1+$"=>$^F<<$^F)=ord($/^substr$;=>$"=int rand 24=>1);
print&&select$,,$,,$,,$|/($|+tr/ //c);redo if y/ //>$^F**2};
------------------------------
Date: Tue, 21 Jun 2005 10:30:39 +0200
From: Daniel Pfeiffer <occitan@esperanto.org>
To: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Fixed: ActiveState: Can't spawn "cmd.exe"?
Message-Id: <42B7D02F.1080203@esperanto.org>
la 14.06.2005 23:36 A. Sinan Unur skribis:
> Daniel Pfeiffer <occitan@esperanto.org> wrote in
> news:42AF457A.9060709@esperanto.org:
>
>>Coming from Unix, makepp assumes PATH to be colon separated and
>>splits it on that.
>
> And what is your excuse for not using File::Spec?
And what is your excuse for not knowing what you are talking about?
File::Spec handles only part of OS specifics, and PATH variables are not one
of them. Even the file system related ones are handled too superficially,
e.g. only string manipulations rather than checking results against the file
system.
Besides the stable version of makepp still supports 5.005, which didn't yet
include this module. And the version that comes with 5.8.6 for Cygwin, though
at 1.1, claims to be beta. It also pretends not to be case_tolerant :-( This
shouldn't be a system specific anyway but a file system specific one. I can
well mount a Samba drive somewhere, giving me mixed case sensitivity within
one path.
And even if Sysiphus thinks that the only MinGW port available for download is
not the usual one, it does exist and is not handled by File::Spec ($^O eq 'msys').
>>I haven't tracked where it gets put together again
>
> Very confidence inspiring.
The result counts, and we verify that with an extensive test suite, as well as
using the bleeding edge version in our various big real life projects.
> Indeed, these posts have helped me decide never to give makepp a shot.
That's freedom as in (lots of) free beer ;-)
> And probably introduced a bunch more given the haphazard way you are
> approaching this.
I've already got some in my finder, none of which would be helped by
File::Spec. But they'll be sorted out.
best regards
Daniel
------------------------------
Date: Tue, 21 Jun 2005 22:16:45 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Fixed: ActiveState: Can't spawn "cmd.exe"?
Message-Id: <Xns967CB9EC116D4asu1cornelledu@127.0.0.1>
Daniel Pfeiffer <occitan@esperanto.org> wrote in
news:42B88A3F.9050805@esperanto.org:
> la 21.06.2005 12:22 A. Sinan Unur skribis:
>> Daniel Pfeiffer <occitan@esperanto.org> wrote in
>> news:42B7D02F.1080203@esperanto.org:
>>
>>>la 14.06.2005 23:36 A. Sinan Unur skribis:
>>>
>>>>Daniel Pfeiffer <occitan@esperanto.org> wrote in
>>>>news:42AF457A.9060709@esperanto.org:
>>>>
>>>>>Coming from Unix, makepp assumes PATH to be colon separated and
>>>>>splits it on that.
>>>>
>>>>And what is your excuse for not using File::Spec?
>>>
>>>And what is your excuse for not knowing what you are talking about?
>>>File::Spec handles only part of OS specifics, and PATH variables are
>>>not one of them.
>>
>> File::Spec->path
>>
>> Takes no argument. Returns the environment variable PATH (or
>> the local platform's equivalent) as a list.
>
> Ooops, I'm sorry! I read over that one too fast, maybe because "path"
> also refers to full filenames (as in canonpath).
>
> However, checking the coding of those functions, they are broken.
> Cygwin wrongly inherits from Unix, and that only splits on :, which
> will completely fail on the like of '/bin:"C:/WINNT":"/Path/with
> space"'.
What are you talking about??? Let me fire up Cygwin shell ... Oooops,
better add a directory with spaces to my path ... Done, now I fire up
the shell.
Here is my $PATH:
PATH='/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:
/cygdrive/c/opt/Perl/bin/:/cygdrive/c/opt/gs8.50/bin:
/cygdrive/c/opt/gs8.50/lib:/cygdrive/c/opt/Perl/bin:
/cygdrive/c/opt/jdk/bin:/cygdrive/c/opt/GTK/2.0/bin:
/cygdrive/c/opt/GIMP-2.2/bin:/cygdrive/c/opt/PuTTY:
/cygdrive/c/Program Files/HighMAT CD Writing Wizard:
/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:
/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/opt/util:
/cygdrive/c/opt/vim/vim63:/cygdrive/c/opt/TeX/bin/win32
Note the requisite path with spaces in the middle of this list. Now:
$ cat p.pl
#!/usr/bin/perl
use strict;
use warnings;
use File::Spec::Functions 'path';
print "$_\n" for path;
__END__
$ ./p.pl
/usr/local/bin
/usr/bin
/bin
/usr/X11R6/bin
/cygdrive/c/opt/Perl/bin/
/cygdrive/c/opt/gs8.50/bin
/cygdrive/c/opt/gs8.50/lib
/cygdrive/c/opt/Perl/bin
/cygdrive/c/opt/jdk/bin
/cygdrive/c/opt/GTK/2.0/bin
/cygdrive/c/opt/GIMP-2.2/bin
/cygdrive/c/opt/PuTTY
/cygdrive/c/Program Files/HighMAT CD Writing Wizard
/cygdrive/c/WINDOWS/system32
/cygdrive/c/WINDOWS
/cygdrive/c/WINDOWS/System32/Wbem
/cygdrive/c/opt/util
/cygdrive/c/opt/vim/vim63
/cygdrive/c/opt/TeX/bin/win32
/usr/bin
/usr/bin
/usr/local/bin
/usr/lib
> I'm amazed that after years of publication the module is
> still so poor.
I don't see a problem.
FYI:
$ perl -v
This is perl, v5.8.6 built for cygwin-thread-multi-64int
$ perl -MFile::Spec -e 'print $File::Spec::VERSION'
3.01
So, I guess, I need to update.
>>> Even the file system related ones are handled too
>>>superficially, e.g. only string manipulations
>>
>> What you were doing was string manipulation using the wrong strings.
>> Using File::Spec->path would have been the right thing to do.
>
> I wasn't referring to that. Makepp needs to know when two files point
> to the same physical file.
That is not what you originally identified as the issue with your code:
#Daniel Pfeiffer <occitan@esperanto.org> wrote in
#news:42AF457A.9060709@esperanto.org:
#
#> I finally sorted this one out. Coming from Unix, makepp assumes PATH
#> to be colon separated and splits it on that. I haven't tracked where
#> it gets put together again (after all we still have the full PATH
#> intact as well) but splitting it on ';' and stripping the quotes has
#> solved the cmd.exe problem :-)
There is no reason to reinvent the wheel, and come up with an octogonal
one.
Besides, I do not see why your application is interested in figuring out
if two paths refer to the same physical file.
>> There was a very illuminating discussion on this in the last few
>> months. Check the archives.
>
> There's quite a bit of discussion -- not sure which you mean. But
> what I see, is that for the nitty details you have to do quite a bit
> of coding around the provided methods. And even then the authors are
> often not sure their thing is still portable.
Given your reputation, I am inclined not believe the assertions above.
File::Spec has never failed me.
> I agree that rebasing makepp's FileInfo.pm on this might make some
> sence. But given the problems and incompleteness of File::Spec it is
> hardly a panacea...
What are the problems with File::Spec?
> Not sure about performance either. FileInfo is very central to
> makepp, and when I took out the method lookup, converting it to
> function calls, makepp became noticeably faster.
I am inclined to believe any performance problems you had were not due to
method versus function calls.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Tue, 21 Jun 2005 23:44:31 +0200
From: Daniel Pfeiffer <occitan@esperanto.org>
To: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Fixed: ActiveState: Can't spawn "cmd.exe"?
Message-Id: <42B88A3F.9050805@esperanto.org>
la 21.06.2005 12:22 A. Sinan Unur skribis:
> Daniel Pfeiffer <occitan@esperanto.org> wrote in
> news:42B7D02F.1080203@esperanto.org:
>
>>la 14.06.2005 23:36 A. Sinan Unur skribis:
>>
>>>Daniel Pfeiffer <occitan@esperanto.org> wrote in
>>>news:42AF457A.9060709@esperanto.org:
>>>
>>>>Coming from Unix, makepp assumes PATH to be colon separated and
>>>>splits it on that.
>>>
>>>And what is your excuse for not using File::Spec?
>>
>>And what is your excuse for not knowing what you are talking about?
>>File::Spec handles only part of OS specifics, and PATH variables are
>>not one of them.
>
> File::Spec->path
>
> Takes no argument. Returns the environment variable PATH (or
> the local platform's equivalent) as a list.
Ooops, I'm sorry! I read over that one too fast, maybe because "path" also
refers to full filenames (as in canonpath).
However, checking the coding of those functions, they are broken. Cygwin
wrongly inherits from Unix, and that only splits on :, which will completely
fail on the like of '/bin:"C:/WINNT":"/Path/with space"'. I'm amazed that
after years of publication the module is still so poor.
> <URL:http://search.cpan.org/~kwilliams/PathTools-3.09/lib/File/Spec.pm>
>
> Even the file system related ones are handled too
>
>>superficially, e.g. only string manipulations
>
> What you were doing was string manipulation using the wrong strings.
> Using File::Spec->path would have been the right thing to do.
I wasn't referring to that. Makepp needs to know when two files point to the
same physical file.
>>rather than checking results against the file system.
>
> There was a very illuminating discussion on this in the last few months.
> Check the archives.
There's quite a bit of discussion -- not sure which you mean. But what I see,
is that for the nitty details you have to do quite a bit of coding around the
provided methods. And even then the authors are often not sure their thing is
still portable.
I agree that rebasing makepp's FileInfo.pm on this might make some sence. But
given the problems and incompleteness of File::Spec it is hardly a panacea...
Not sure about performance either. FileInfo is very central to makepp, and
when I took out the method lookup, converting it to function calls, makepp
became noticeably faster.
Daniel
------------------------------
Date: Mon, 20 Jun 2005 17:01:58 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Re: Q for the old-timers: antecedents to the ST?
Message-Id: <d96sq6$jp8$1@reader1.panix.com>
In <200562020035.916307@ron> Ron Savage <ron@savage.net.au> writes:
>On Mon, 20 Jun 2005 04:47:03 +1000, kj wrote:
>Hi kj
>> technique. After all, there is a very similar technique, which
>> I've seen referred to as "tag shuffling", for randomly shuffling a
>> list. In Perl it would be rendered like this:
>It used to be called a 'tag sort', from the time when computer memory was=
> tiny.
<snip>
Thanks, Ron. Your account is what I was looking for.
kj
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
------------------------------
Date: Tue, 21 Jun 2005 19:23:47 -0400
From: * Tong * <sun_tong@users.sourceforge.net>
Subject: what's the right way to encode this?
Message-Id: <1119396236.ef20079efbfbc223f0d044a01f54a4f0@teranews>
Hi,
I have this file:
$ cat test | od -t u1
0000000 181 220 210 221 149 132 163 168 183 189 193 166 201 234 163 169
^^^^^^
and I want to encode it with Perl. This is what I did:
cat test | perl -pe 's/[\200-\377]/"&#". ord($&). ";"/gxe'
But strangely, the output is
µÜÒÝ•"£¨·½
^^^^^^^
Notice the extreme big number pointed by ^^^?
How can I encode exactly as the "od -t u1" output, i.e., •„
instead of •"?
I know it could be done using some html packages, but I just want to know
how to do it in pure simple Perl. Thank.
--
Tong (remove underscore(s) to reply)
*niX Power Tools Project: http://xpt.sourceforge.net/
- All free contribution & collection
------------------------------
Date: Tue, 21 Jun 2005 23:49:33 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: what's the right way to encode this?
Message-Id: <Xns967CC9AD93B9Fasu1cornelledu@127.0.0.1>
* Tong * <sun_tong@users.sourceforge.net> wrote in
news:1119396236.ef20079efbfbc223f0d044a01f54a4f0@teranews:
> I have this file:
>
> $ cat test | od -t u1
> 0000000 181 220 210 221 149 132 163 168 183 189 193 166 201 234 163
> 169
> ^^^^^^
>
> and I want to encode it with Perl. This is what I did:
>
> cat test | perl -pe 's/[\200-\377]/"&#". ord($&). ";"/gxe'
>
> But strangely, the output is
>
> µÜÒÝ•"£¨·½
> ^^^^^^^
> Notice the extreme big number pointed by ^^^?
>
> How can I encode exactly as the "od -t u1" output, i.e., •„
> instead of •"?
I am assuming it has something to do with utf-8 or other Unicode
related magic I don't understand.
OK, to be able to test a solution, I now have to create a file
containing those bytes. Let's call that input.
D:\Home> cat input | perl -Mbytes -pe "s/[\200-\377]/'&#'.ord($&).';'/gxe"
µÜÒÝ•„£¨·½Á¦É꣩
I am sure someone more knowledgeable than I am will tell me why
this is a bad idea :)
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
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 8190
***************************************
