[24844] in Perl-Users-Digest
Perl-Users Digest, Issue: 6995 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Sep 12 09:06:40 2004
Date: Sun, 12 Sep 2004 06: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 Sun, 12 Sep 2004 Volume: 10 Number: 6995
Today's topics:
Re: "RFC": re [un]pack() <bik.mido@tiscalinet.it>
Re: Network Scanner <ceo@nospam.on.net>
newbie question <nds@none.com>
Re: newbie question <sholden@flexal.cs.usyd.edu.au>
Re: newbie question <nospam@bigpond.com>
Re: newbie question <jurgenex@hotmail.com>
Re: Perl opting for double-byte chars? <flavell@ph.gla.ac.uk>
Re: Perl opting for double-byte chars? $_@_.%_
Re: Perl opting for double-byte chars? <http://joecosby.com/code/mail.pl>
Re: Perl opting for double-byte chars? <http://joecosby.com/code/mail.pl>
Re: Perl opting for double-byte chars? <tassilo.von.parseval@rwth-aachen.de>
Re: Perl opting for double-byte chars? <http://joecosby.com/code/mail.pl>
Re: Perl opting for double-byte chars? <flavell@ph.gla.ac.uk>
Re: strange output of pack in perl 5.8.0 <dotREMOVEan.halevTHISi@intANDTHISel.com>
Re: use CGI qw(:standard) ??? <noreply@gunnar.cc>
Re: Xah Lee's Unixism <krw@att.bizzzz>
Re: Xah Lee's Unixism <lin8080@freenet.de>
Re: Xah Lee's Unixism <roo@try-removing-this.darkboong.demon.co.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 12 Sep 2004 12:54:06 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: "RFC": re [un]pack()
Message-Id: <qs98k0lcosll5f3ib2292r0onvp5uam6lu@4ax.com>
On 10 Sep 2004 22:36:31 GMT, anno4000@lublin.zrz.tu-berlin.de (Anno
Siegel) wrote:
>pack and unpack suffer from obscurity, not from a lack of flexibility.
I totally agree with you. I find that these two functions are
incredibly powerful and useful, but every time I need them I have to
read the docs two or three times and despite of this generally I still
have to find the correct template by trial and error!
>If anything is wanting it's a means to identify which parts of one
>template interact with which parts of the other. I don't see your
>extension helping much, in fact it makes it natural to put them all
>on one line. Some kind of column formatting (do-able with explicit
>pack/unpack) is a better approach.
I see... though, as of the *second* suggestion (i.e. by means of, say,
an arrayref) I gave, the extended syntax wouldn't *necessarily*
enforce the all-on-one-line style:
my $packed = pack [ qw/template1
template2
template3/ ], @data;
However, taking into account your, and Brian McCauley's, knowledgeable
opinion, I think I won't bother anymore!
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sun, 12 Sep 2004 01:53:13 GMT
From: ChrisO <ceo@nospam.on.net>
Subject: Re: Network Scanner
Message-Id: <d_N0d.41$H56.15@newssvr16.news.prodigy.com>
Chad Brown wrote:
> ChrisO <ceo@nospam.on.net> wrote in message news:<8hm0d.9623$ZC7.3452@newssvr19.news.prodigy.com>...
>
>>Chad Brown wrote:
>>
>>>I put together a script for scaning a network. Features are DNS
>>>resolution, selective port scan, scanning of multiple addresses at one
>>>time, and ping sweep. Ports can be customized depending on what is
>>>being sought on a network. If anyone decides to add more ideas to this
>>>please send me a copy. Im very interested in input. (:
>>>
>>
>>Are you doing this for a learning exercise? Because there are already
>>mature, open source network scanners that even a mature, very
>>knowledgable Perl developer would be hard put to match.
>>
>
> Im well aware of the existence of other scanners. I put this together
> so that I could add more stuff onto it and customize and possibly get
> other scripts to work with it.
>
> And about the mature... This project is "YES"... a learning
> exercise... I wouldnt have took it on if I have seen other scanners
> out there. I was looking for constructive help not critisism. Also as
> the post says I was looking for ideas. This is not a cocky display of
> junky code... Yea im not the best at perl.
My post wasn't intended to be critical nor as an insult but rather
intended to alert you to the presence of existing solutions in the event
you were unaware. Most people are happy to be provided with this sort
of input.
I also don't recall making light of your code. Though I stand by my
assertion that the exercise is pointless outside of a learning exercise
even for an experienced Perl coder. Customization, which you claim as
the virtue of your efforts, is precisely what is built into many of the
existing scanners to which I have already alluded and have callable
interfaces.
Nevertheless, don't consider even this message an attempt to "poo-poo"
your efforts. I for one practically re-wrote 'fetchmail' using Perl,
but only because I wasn't already aware of fetchmail. I would have been
grateful to have had someone point out its existance so I wouldn't have
spent all my time re-writing it in Perl. I learned alot from the effort
however... So in that case, this sort of thing is never a "waste."
Anyway, try not to get all "huffy"... If it's valuable to you, then by
all means, have a hearty go at it.
-ceo
------------------------------
Date: Sun, 12 Sep 2004 10:06:11 GMT
From: "NDS Ltd" <nds@none.com>
Subject: newbie question
Message-Id: <ncV0d.1328$_67.1149@newsfe2-win.ntli.net>
hi,
at the prompt on my linux box if i type
perl test.pl
i gets the message 'perl is working'
but if i view the same file through my browser (it is in cgi-bin) i get
Internal Server Error
The server encountered an internal error or misconfiguration and was unable
to complete your request. bla bla bla..
in the logs it says...
[Sun Sep 12 10:51:31 2004] [error] (8)Exec format error: exec of
/home/e-smith/files/ibays/networkdata/cgi-bin/test.pl failed
[Sun Sep 12 10:51:31 2004] [error] [client 192.168.1.4] Premature end of
script headers: /home/e-smith/files/ibays/networkdata/cgi-bin/test.pl
Any help appreciated...
------------------------------
Date: 12 Sep 2004 10:16:45 GMT
From: Sam Holden <sholden@flexal.cs.usyd.edu.au>
Subject: Re: newbie question
Message-Id: <slrnck88gd.26i.sholden@flexal.cs.usyd.edu.au>
On Sun, 12 Sep 2004 10:06:11 GMT, NDS Ltd <nds@none.com> wrote:
> hi,
>
> at the prompt on my linux box if i type
>
> perl test.pl
>
> i gets the message 'perl is working'
>
> but if i view the same file through my browser (it is in cgi-bin) i get
> Internal Server Error
> The server encountered an internal error or misconfiguration and was unable
> to complete your request. bla bla bla..
>
>
> in the logs it says...
>
> [Sun Sep 12 10:51:31 2004] [error] (8)Exec format error: exec of
> /home/e-smith/files/ibays/networkdata/cgi-bin/test.pl failed
Your script isn't executable when run as
/home/e-smith/files/ibays/networkdata/cgi-bin/test.pl
(ie. with no "perl " at the start)
Fixing that is system dependant, but since you say "linux" I'd say
you need to add an appropriate #! line to the start of the script.
See your OS documentation for details.
> [Sun Sep 12 10:51:31 2004] [error] [client 192.168.1.4] Premature end of
> script headers: /home/e-smith/files/ibays/networkdata/cgi-bin/test.pl
CGI scripts have to follow the CGI specification, regarding what they output.
Yours doesn't follow it and hence doesn't work.
There a bunch of FAQs regarding CGI, available via:
perldoc -q CGI
Maybe the one entitled:
My CGI script runs from the command line but not the browser. (500 Server Error)
will provide you with the answer.
--
Sam Holden
------------------------------
Date: Sun, 12 Sep 2004 20:19:54 +1000
From: Gregory Toomey <nospam@bigpond.com>
Subject: Re: newbie question
Message-Id: <2qim23Fvp9lpU1@uni-berlin.de>
NDS Ltd wrote:
> hi,
>
> at the prompt on my linux box if i type
>
> perl test.pl
>
> i gets the message 'perl is working'
>
> but if i view the same file through my browser (it is in cgi-bin) i get
> Internal Server Error
See http://www.perl.com/doc/FAQs/cgi/idiots-guide.html
gtoomey
------------------------------
Date: Sun, 12 Sep 2004 11:07:11 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: newbie question
Message-Id: <z5W0d.432$g9.425@trnddc06>
NDS Ltd wrote:
The first thing you should do is familiarize yourself with the available
online documentation for Perl.
perldoc is _THE_ standard tool to query not only the manuals but also the
FAQ. Try
perldoc perldoc
to find out how to use it and
perldoc perl
to see a table of content.
> at the prompt on my linux box if i type
>
> perl test.pl
>
> i gets the message 'perl is working'
>
> but if i view the same file through my browser (it is in cgi-bin) i
> get Internal Server Error
This problem is described in the FAQ, see
perldoc -q 500
jue
------------------------------
Date: Sun, 12 Sep 2004 02:12:26 +0100
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Perl opting for double-byte chars?
Message-Id: <Pine.LNX.4.61.0409120207260.27805@ppepc56.ph.gla.ac.uk>
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--616733697-428399201-1094951328=:27805
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: 8BIT
Content-ID: <Pine.LNX.4.61.0409120209031.27805@ppepc56.ph.gla.ac.uk>
On Sat, 11 Sep 2004, it was written:
> I am working on a problem, I have text in a database which includes
> the word "más". The "á" is ASCII value 225/E1 .
ASCII is a 7-bit code. There is no such "value" in ASCII.
> It is definitely this inside the database.
You need to learn a little more about character coding.,
> The code pulls the text out of the database and assigns it to a
> variable, but when I print the variable it is now "más"
Your usenet posting claims:
Content-Type: text/plain; charset=ISO-8859-1
You don't seem to understand what that means.
>, the "á" has been replaced by C3A1 .
Perhaps you confused the software into believing that you wanted
characters (for which Perl has an internal representation) rather than
bytes.
> Digging around in various Perl docs, I found some references which say
> that Perl will decide whether to use double-byte for chars > 127, it
> looks like that is what's happening here.
Do you have utf8 in your locale?
--616733697-428399201-1094951328=:27805--
------------------------------
Date: Sun, 12 Sep 2004 03:00:11 GMT
From: $_@_.%_
Subject: Re: Perl opting for double-byte chars?
Message-Id: <%YO0d.1644$yJ3.1346@trndny08>
Bëelphazoar <http://joecosby.com/code/mail.pl> wrote in message-id:
<9i57k0hfs4ov5orh4cji217f55icn6lnrq@4ax.com>
>
>
>I am working on a problem, I have text in a database which includes
>the word "más". The "á" is ASCII value 225/E1 .
>
>It is definitely this inside the database.
>
>The code pulls the text out of the database and assigns it to a
>variable, but when I print the variable it is now "más", the "á" has
>been replaced by C3A1 .
>
>I am PRETTY sure that this is not happening within the code I am
>working on, if I am following the code flow correctly it looks like it
>does nothing but pull the text from the database and pass it back.
>
>Digging around in various Perl docs, I found some references which say
>that Perl will decide whether to use double-byte for chars > 127, it
>looks like that is what's happening here.
>
>I tried doing this:
>
>use bytes;
>$myVar = pullTextFromDb();
>no bytes;
>
>but I still got the double-byte translation.
>
>Does anybody have any pointers about how to proceed further debugging
>this?
>
Try perldoc encode
------------------------------
Date: Sat, 11 Sep 2004 23:34:55 -0700
From: Bëelphazoar <http://joecosby.com/code/mail.pl>
Subject: Re: Perl opting for double-byte chars?
Message-Id: <ofr7k0h53p61baobrh4ubfncba5g9rdk2s@4ax.com>
On Sun, 12 Sep 2004 03:00:11 GMT, $_@_.%_ wrote:
>
>Bëelphazoar <http://joecosby.com/code/mail.pl> wrote in message-id:
><9i57k0hfs4ov5orh4cji217f55icn6lnrq@4ax.com>
>>
>>
>>I am working on a problem, I have text in a database which includes
>>the word "más". The "á" is ASCII value 225/E1 .
>>
>>It is definitely this inside the database.
>>
>>The code pulls the text out of the database and assigns it to a
>>variable, but when I print the variable it is now "más", the "á" has
>>been replaced by C3A1 .
>>
>>I am PRETTY sure that this is not happening within the code I am
>>working on, if I am following the code flow correctly it looks like it
>>does nothing but pull the text from the database and pass it back.
>>
>>Digging around in various Perl docs, I found some references which say
>>that Perl will decide whether to use double-byte for chars > 127, it
>>looks like that is what's happening here.
>>
>>I tried doing this:
>>
>>use bytes;
>>$myVar = pullTextFromDb();
>>no bytes;
>>
>>but I still got the double-byte translation.
>>
>>Does anybody have any pointers about how to proceed further debugging
>>this?
>>
>
>Try perldoc encode
>
>
>
No documentation found for "encode".
--
Joe Cosby
http://joecosby.com/
"I will be warned of the dangers of time travel!",
remembered Tilly, of the warning she was given in the
future, of the perils of the past, which she presently
thought had been both historic and foresighted, "though
knowing now what I will know then makes it somewhat
anachronistic".
-Dr. Hieronymous Zinn, from The Novel
------------------------------
Date: Sat, 11 Sep 2004 23:43:03 -0700
From: Bëelphazoar <http://joecosby.com/code/mail.pl>
Subject: Re: Perl opting for double-byte chars?
Message-Id: <tgr7k05ml3lirbcu3gjmi05j2i0te18tgv@4ax.com>
On Sun, 12 Sep 2004 02:12:26 +0100, "Alan J. Flavell"
<flavell@ph.gla.ac.uk> wrote:
>On Sat, 11 Sep 2004, it was written:
>
>> I am working on a problem, I have text in a database which includes
>> the word "más". The "á" is ASCII value 225/E1 .
>
>ASCII is a 7-bit code. There is no such "value" in ASCII.
>
>> It is definitely this inside the database.
>
>You need to learn a little more about character coding.,
>
>> The code pulls the text out of the database and assigns it to a
>> variable, but when I print the variable it is now "más"
>
>Your usenet posting claims:
>
>Content-Type: text/plain; charset=ISO-8859-1
>
>You don't seem to understand what that means.
>
It means that I am telling any client which tries to read my post that
I am using ISO code page 8859-1
This is a table of character representations corresponding to 8-bit
values, with 256 members.
As you say, ASCII only defines the low 7 bits, whcih are the same
character representations in most english-based code pages.
In addition to ASCII there is unicode, which is 16-bit, and which,
somewhere in my application, is apparently being used when the "á" is
used because it is greater than 127.
Perl, from what I understand from the documentation I could find, will
sometimes decide to use Unicode values where text is in the 128-255
range. This appears to be the heart of the problem, because at one
point the application appears to be trying to represent the "á"
character in Unicode, but then anywhere subsequent the environment is
failing to translate the resulting 2-byte character back to the
appropriate represenation.
I apologize if I was not sufficiently rigorous in my description of
what I know so far. I thought it was reasonably clear what I was
saying.
>>, the "á" has been replaced by C3A1 .
>
>Perhaps you confused the software into believing that you wanted
>characters (for which Perl has an internal representation) rather than
>bytes.
>
>> Digging around in various Perl docs, I found some references which say
>> that Perl will decide whether to use double-byte for chars > 127, it
>> looks like that is what's happening here.
>
>Do you have utf8 in your locale?
I don't know. Can you tell me how I would check that? I don't know a
great deal about the Perl environment.
--
Joe Cosby
http://joecosby.com/
"I will be warned of the dangers of time travel!",
remembered Tilly, of the warning she was given in the
future, of the perils of the past, which she presently
thought had been both historic and foresighted, "though
knowing now what I will know then makes it somewhat
anachronistic".
-Dr. Hieronymous Zinn, from The Novel
------------------------------
Date: Sun, 12 Sep 2004 09:29:43 +0200
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: Perl opting for double-byte chars?
Message-Id: <2qic7aFvvu6nU1@uni-berlin.de>
Also sprach Bëelphazoar:
> On Sun, 12 Sep 2004 02:12:26 +0100, "Alan J. Flavell"
><flavell@ph.gla.ac.uk> wrote:
> In addition to ASCII there is unicode, which is 16-bit,
No, that's not Unicode. Unicode is foremost just a mapping between
numbers and characters. Each character thusly has a unique number. When
you talk about bits, you are really talking about encodings. Unicode
defines three encodings: UTF-(8|16|32). Perl internally uses UTF-8 which
is a variable width encoding meaning a character can have anything
between one and four bytes.
The same is true for UTF-16 which you must have been thinking of. The
most common characters fit into two bytes. However, all the other
characters do exist as well in this encoding. They are encoded in two
byte-couples.
This distinction sounds like hairsplitting, but it's crucial if you ever
want to understand what Unicode is about and how to use it properly.
>>Do you have utf8 in your locale?
>
> I don't know. Can you tell me how I would check that? I don't know a
> great deal about the Perl environment.
Perl uses the environment of your system, not its own. So check your
environment variables.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Sun, 12 Sep 2004 01:43:55 -0700
From: Bëelphazoar <http://joecosby.com/code/mail.pl>
Subject: Re: Perl opting for double-byte chars?
Message-Id: <i728k0tdmktlaksjhm62dh26g9ra40gpa0@4ax.com>
On Sun, 12 Sep 2004 09:29:43 +0200, "Tassilo v. Parseval"
<tassilo.von.parseval@rwth-aachen.de> wrote:
>Also sprach Bëelphazoar:
>
>> On Sun, 12 Sep 2004 02:12:26 +0100, "Alan J. Flavell"
>><flavell@ph.gla.ac.uk> wrote:
>
>> In addition to ASCII there is unicode, which is 16-bit,
>
>No, that's not Unicode. Unicode is foremost just a mapping between
>numbers and characters. Each character thusly has a unique number. When
>you talk about bits, you are really talking about encodings. Unicode
>defines three encodings: UTF-(8|16|32). Perl internally uses UTF-8 which
>is a variable width encoding meaning a character can have anything
>between one and four bytes.
>
>The same is true for UTF-16 which you must have been thinking of. The
>most common characters fit into two bytes. However, all the other
>characters do exist as well in this encoding. They are encoded in two
>byte-couples.
>
>This distinction sounds like hairsplitting, but it's crucial if you ever
>want to understand what Unicode is about and how to use it properly.
>
>>>Do you have utf8 in your locale?
>>
>> I don't know. Can you tell me how I would check that? I don't know a
>> great deal about the Perl environment.
>
>Perl uses the environment of your system, not its own. So check your
>environment variables.
>
Thanks.
At some point, Perl does seem to be making the decision to alter the
data which I am pulling from the database, changing the particular
character from an 8-bit value to a 16-bit value.
The job at hand for me is to make it stop doing this.
As you and the preceding person have pointed out, I don't know
everything there is to know about character encodings. I apologize if
I have caused any confusion in describing character encoding
incorrectly.
I would appreciate any pointers you might have on where would be a
good place to start looking at system variables to find the relevant
environment variables, but it does seem clear enough, assuming I am
understanding the code I am looking at, that Perl is changing a text
value for whatever reason and based on whatever system of character
encoding from an 8-bit value which works to a 16-bit value which
doesn't.
It seems, as far as I can tell, as if that is something I will need to
solve within Perl. Maybe I am mistaken, but I don't see how the
operating system is going to make a decision to force data inside a
Perl application to alter based on it's active character encoding
setup.
If how Perl makes the decision to change the 8-bit value to a 16-bit
value is based on the active system character encoding setup, then any
pointers anybody could provide as to how it makes this decision, or
what exactly I should be looking at, would be most appreciated.
Again, as I say, my job at hand here is to convince Perl not to change
the existing 8-bit value I am pulling from the database into a 16-bit
value which no longer works for what I am doing.
>Tassilo
--
Joe Cosby
http://joecosby.com/
"Typhoon Rips Through Cemetery, Hundreds Dead."
- Newspaper Headline
------------------------------
Date: Sun, 12 Sep 2004 11:31:34 +0100
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Perl opting for double-byte chars?
Message-Id: <Pine.LNX.4.61.0409121103550.4316@ppepc56.ph.gla.ac.uk>
On Sun, 12 Sep 2004, it was written:
[snip]
> At some point, Perl does seem to be making the decision to alter the
> data which I am pulling from the database, changing the particular
> character
So write and instrument a small test case, small enough to be posted
here (minus the database itself, OK) with some sample printouts of the
data at the various points in the processing, preferably in
hexadecimal (any attempt to splatter 8-bit characters into a Usenet
posting usually turns into a failure to communicate, in my
experience).
> from an 8-bit value to a 16-bit value.
This may seem like hair splitting, but what you exhibited so far
appeared to be a utf-8 character. Which in this case consisted of two
octets (bytes), but that's not the same thing as "a 16-bit value".
> The job at hand for me is to make it stop doing this.
Possibly. That depends on what range of characters you hope to be
able to handle in your system. But let's try to understand where
we're at, before discussing where to go from there.
> As you and the preceding person have pointed out, I don't know
> everything there is to know about character encodings. I apologize if
> I have caused any confusion in describing character encoding
> incorrectly.
Oh, it's quite normal... Naturally I'd urge you to take time to learn
a bit more about it, believing - as I do - that it'll save you effort
later; but as it's one of my specialist subjects, "I would say that,
wouldn't I?"...
> I would appreciate any pointers you might have on where would be a
> good place to start looking at system variables to find the relevant
> environment variables,
man printenv
man locale
(assuming unix-family OS),
> but it does seem clear enough, assuming I am
> understanding the code I am looking at, that Perl is changing a text
> value
Perl doesn't magically "change text values": it handles text in the
way that it thinks it's been asked to handle it.
My feeling is that, sooner rather than later, you're going to need
this stuff anyway, so I'd start on perldoc perluniintro and then
perldoc perlunicode (or the links near the foot of the index page
http://www.perldoc.com/perl5.8.0/pod.html or whichever version you are
using).
But if you're determined that you just want to get utf8 out of the way
for the moment, and you're sure you'll never be showing Perl a
character outside of the iso-8859-1 range, then look for discussions
on apparent incompatibilities between RedHat 9 and Perl 5.8, which
discuss how RedHat's introduction of utf8 into the locale caused Perl
to switch into its Unicode mode, and how to take it out again (I don't
have the details at my fingertips right now, sorry).
> It seems, as far as I can tell, as if that is something I will need to
> solve within Perl. Maybe I am mistaken, but I don't see how the
> operating system is going to make a decision to force data inside a
> Perl application to alter based on it's active character encoding
> setup.
Oh, but it does. At least in 5.8.0. Google for "redhat perl 5.8.0
utf8 locale" (without the quotes) and read the first few links, I
think they'll help.
> If how Perl makes the decision to change the 8-bit value to a 16-bit
> value
Please stop saying "16 bit value"; it's sure to cause confusion
somewhere down the line. What you're talking about here is a
character stored in Perl's native unicode format, which is utf-8: this
particular character happens to occupy two bytes in storage, but it's
not useful to talk about it as a "16-bit value", and it risks
confusing it with utf-16 format (which is the OS's native storage
format on Windows NT-based systems, by the way, and commonly used also
for storing unicode characters in databases).
good luck
------------------------------
Date: Sun, 12 Sep 2004 13:34:41 +0300
From: "Dotan Halevi" <dotREMOVEan.halevTHISi@intANDTHISel.com>
Subject: Re: strange output of pack in perl 5.8.0
Message-Id: <ci18nv$ufm$1@news01.intel.com>
Brian, thanks.
I'm using a non-US locale, and the binmode did the magic:
$ perl -e 'binmode(STDOUT);print(pack("v", 0xabcd))'| hexdump
0000000 abcd
0000002
Dotan
"Brian McCauley" <nobull@mail.com> wrote in message
news:chq4mu$dcr$1@slavica.ukpost.com...
>
>
> Dotan Halevi wrote:
>
> > __________ test #2 over RedHat 9.0, perl 5.8.0-88 __________
> > $ perl -e 'print(pack("v", 0xabcd))'| hexdump
> > 0000000 8dc3 abc2
> > 0000004
> > ___________ end ________________________
> >
> > What is wrong here ???
>
> It would appear that somewhere between pack() and STDOUT it's getting
> utf8 encoded.
>
> I assue that the output of pack() is a byte string but when you pass it
> to a utf8 encoded filehandle it interprets the bytes of the string as
> Unicode code-points.
>
> I think this has to do with some sort of locale setting since I don't
> see in on my (non-Redhat) Linux box.
>
> I'd guess it's fixable by explicitly saying binmode(STDOUT) but I can't
> check since I can't reproduce the problem.
>
------------------------------
Date: Sun, 12 Sep 2004 03:45:01 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: use CGI qw(:standard) ???
Message-Id: <2qho4iFv5leeU1@uni-berlin.de>
Scott Bryce wrote:
> It is probably safe to assume that the CGI module is installed,
> unless this line of the script causes an error. If the module isn't
> there, there isn't anything we can do to help you.
Not true. If, contrary to expectation, CGI.pm would not be installed
already, it is a plain Perl module that can easily be installed in a
local library.
> This is not the place to get help configuring CGI scripts that you
> have found on the internet.
Very true.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sat, 11 Sep 2004 23:10:52 -0400
From: keith <krw@att.bizzzz>
Subject: Re: Xah Lee's Unixism
Message-Id: <pan.2004.09.12.03.10.50.15253@att.bizzzz>
On Sat, 11 Sep 2004 14:51:56 -0700, Jack Peacock wrote:
> "Chuck Dillon" <spam@nimblegen.com> wrote in message
> news:chsbod$q0i$1@grandcanyon.binc.net...
>> Your argument is shallow if you direct it to the person who happens to be
>> holding the office of President at the moment. The President can't
>> introduce or pass law.
>>
> Laws no, but the definition of a law can be ambiguous. Congress has given
> federal agencies under the President broad power to issue regulations with
> the same effect as laws, but without going through the legislative process.
> Anyone who has ever battled with the Bureau of Land Management or ran afoul
> of the Endangered Species Act knows that "laws" are often created by fiat in
> a Washington DC office building.
>
> Then there are presidential Executive Orders which are often attempts to end
> run around a lack of congressional cooperation. Clinton attempted to use
> this to outlaw firearms posession in federal housing until the Supreme Court
> put a stop to it.
>
> And finally there are international treaties, which operate with the force
> of law but are not passed by the House of Representatives. The President
> signs it and the Senate confirms it, but half the legislative process is cut
> out. Often all that protects the country from disasters like the Kyoto
> Treaty is a filibuster by a Senate minority.
In the case of Kyoto, no filibuster was necessary. Even Kerry wouldn't
have voted for it (it went doen 99-0 in a trial balloon). ...though might
today. Who knows what he'd support tomorrow. He's been on eight sides
(and still inventing more) of the Iraq issue.
--
Keith
------------------------------
Date: Sat, 11 Sep 2004 23:30:28 +0200
From: lin8080 <lin8080@freenet.de>
Subject: Re: Xah Lee's Unixism
Message-Id: <41436E74.F659DEB1@freenet.de>
Steve O'Hara-Smith schrieb:
> One thing I always found amusing is the amount of science *fiction*
> written in the first half of this period about what would happen if the
> worlds computers became linked together.
Hi,
as long as nothing new goes in, nothing. Maybe we read yesterdays
papers?
stefan
------------------------------
Date: Sun, 12 Sep 2004 11:20:57 +0100
From: Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk>
Subject: Re: Xah Lee's Unixism
Message-Id: <1094984458.94479@teapot.planet.gong>
keith wrote:
> On Sat, 11 Sep 2004 16:05:52 +0000, SM Ryan wrote:
[SNIP]
>> Iraq had nothing to do with terrorism
>
> Bullshit. It may have had nothing to do with 9/11, but only the infirm
> would believe Iraq had nothing to do with terrorism.
Show me the hard evidence. All I've seen are word association
games. I'm sure you would expect me to provide evidence if I
accused the US of harbouring convicted terrorists.
The US reminds me of Ronnie's "Evil Empire" at the moment. :(
--
Cheers,
Rupert
------------------------------
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 6995
***************************************
