[23956] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 6157 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 18 18:10:58 2004

Date: Wed, 18 Feb 2004 15:10:19 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Wed, 18 Feb 2004     Volume: 10 Number: 6157

Today's topics:
    Re: more stripping <hillmw@ram.lmtas.lmco.com>
    Re: more stripping <emschwar@pobox.com>
    Re: more stripping <gnari@simnet.is>
    Re: more stripping thumb_42@yahoo.com
    Re: more stripping <usenet@morrow.me.uk>
    Re: more stripping <spamtrap@dot-app.org>
    Re: more stripping <noreply@gunnar.cc>
    Re: Posting Usenet News Messages <gnari@simnet.is>
    Re: Posting Usenet News Messages <ron.parker@povray.org>
    Re: Posting Usenet News Messages <gnari@simnet.is>
    Re: Posting Usenet News Messages <usenet@morrow.me.uk>
    Re: Posting Usenet News Messages <drumspoorly@reachone.net>
    Re: Posting Usenet News Messages <ron.parker@povray.org>
    Re: Posting Usenet News Messages <usenet@morrow.me.uk>
    Re: Regular Expresions & pattern matching (mis)understa <tadmc@augustmail.com>
    Re: Replacing unicode characters <bart.lateur@pandora.be>
    Re: Replacing unicode characters <bart.lateur@pandora.be>
    Re: suggestion for a best book <tadmc@augustmail.com>
    Re: suggestion for a best book <usenet@c0s.org>
    Re: suggestion for a best book <uri@stemsystems.com>
        Sybperl - how to specify my own interfaces file (Sudip)
    Re: Sybperl - how to specify my own interfaces file <uri@stemsystems.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Wed, 18 Feb 2004 13:09:17 -0600
From: Michael Hill <hillmw@ram.lmtas.lmco.com>
To: gnari <gnari@simnet.is>
Subject: Re: more stripping
Message-Id: <4033B85D.530FA65C@ram.lmtas.lmco.com>

> for example, I have seen roll-your-owners use unsafe methods to
> import querystring/form params into program symboltable.
> like cgi?foo=1&bar=x being evaled into $foo and $bar.
> 
> gnari

And how does the cgi.pm module help there? 
If those params are unsafe the developer should be using 'post' instead
of a 'querystring'.


------------------------------

Date: Wed, 18 Feb 2004 12:40:08 -0700
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: more stripping
Message-Id: <etod68cgorr.fsf@fc.hp.com>

Michael Hill <hillmw@ram.lmtas.lmco.com> writes:
>> for example, I have seen roll-your-owners use unsafe methods to
>> import querystring/form params into program symboltable.
>> like cgi?foo=1&bar=x being evaled into $foo and $bar.
>> 
>> gnari
>
> And how does the cgi.pm module help there? 

By not doing it.  You can get the values of parameters with the
param() function, or by using Vars().  Personally, I prefer param(),
as I (almost) always know what parameters I'm supposed to be
accepting.

> If those params are unsafe the developer should be using 'post' instead
> of a 'querystring'.

It's not the params that are unsafe, it's automatically vififying
variables based on them that's unsafe.  Even PHP developers realized
the error of their ways quite some time ago, and have turned that
behaviour off by default.

Furthermore, any idiot can spend about 30 seconds with LWP::Simple and
fake a POST request as easily as a GET.  If you think POST is somehow
'more secure', that's another good indication you should be using
CGI.pm instead of rolling your own, as it indicates (to me) that
you're less likely to check POST variables for sanity.  Which brings
up another nice thing about CGI.pm: it doesn't care if you use GET or
POST; its API is the same either way.

Also, your code doesn't correctly handle URI decoding, multi-valued
parameters, or a failed or incomplete read()s either.  All of which
are pretty common for hand-rolled code, and all of which are handled
correctly in CGI.pm.  Frankly, as someone else has pointed out, if you
can afford to use Date::Manip, you can afford to use CGI.pm, and doing
that will vastly clean up your code, allowing it to focus more on what
it does, and less on how it does it.

-=Eric
-- 
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
		-- Blair Houghton.


------------------------------

Date: Wed, 18 Feb 2004 19:21:55 -0000
From: "gnari" <gnari@simnet.is>
Subject: Re: more stripping
Message-Id: <c10dv0$4n8$1@news.simnet.is>

"Michael Hill" <hillmw@ram.lmtas.lmco.com> wrote in message
news:4033B85D.530FA65C@ram.lmtas.lmco.com...
> > for example, I have seen roll-your-owners use unsafe methods to
> > import querystring/form params into program symboltable.
> > like cgi?foo=1&bar=x being evaled into $foo and $bar.
> >
> > gnari
>
> And how does the cgi.pm module help there?
by not using those unsafe methods, of course

> If those params are unsafe the developer should be using 'post' instead
> of a 'querystring'.

that makes of no difference at all

gnari





------------------------------

Date: Wed, 18 Feb 2004 21:28:51 GMT
From: thumb_42@yahoo.com
Subject: Re: more stripping
Message-Id: <mOQYb.353456$na.521291@attbi_s04>

Michael Hill <hillmw@ram.lmtas.lmco.com> wrote:
>> >
>> > Can anyone talk to what security holes may be there?
>> 
>> Google may be very educational (hint: this topic has been discussed a few
>> times before).
>> 
>> jue
> 
> I'm not asking for a comprehensive listing of security holes using cgi,
> but rather inherent security holes because I am using *hand rolled* cgi
> instead of the cgi module.

In general I don't see many *security problems* with rolling your own parsing.
(except maybe someone giving you bogus data or posting way more data
than they really ought to, or feeding you data that some how chokes up your
regex's into doing things it shouldn't.)

Where you may run into trouble is in how you use those parsed values, but
the exact same things can be said for CGI.pm, or indeed reading it straight
from the terminal.

Incidently, I think parsing it yourself is a good excercise. Maybe not that
great all the time, or in production code, or w/out having a good reason for
it, but.. for simple stuff if you want to parse it youself purely for the
fun of it, go ahead. (I should hope we've all tried it once or twice, just
to see what it's like.. I've hand-parsed a few times for kicks, but I
usually use CGI.pm) 

The only "good reasons" I've ever had (and they really weren't that great of
'reasons') were times before CGI.pm was standard, and for file uploading.
Part of it, I'll admit was purely because I enjoyed it and wanted to explore
models that were different than CGI.pm. 

I wondered what it'd be like if each parameter had attributes associated to
it, or if regardless of file upload or regular CGI it would save over a
certain chunk-size to a temp file, and treat file uploads the same as
regular form variables. (unless the sizes exceeded a certain amount) Or,
what if I wanted the exact order of the form variables, or... wanted some
sort of callback subrouting for each line of input, or something akin to
XML::Parser with a handler for start, chardata, end I really don't see
anything wrong with exploring those possibilities and kicking them around a
bit to see the pros and cons.

If someone tells you to have a closed mind and not explore stuff.. Well, I'd
close my mind toward those people. :-) 

Just keep in mind that Lincoln Stein has probably encountered and addressed
all the problems (and a LOT more) than anyone else has in the area of
parsing CGI variables, he knows his stuff. But that shouldn't prevent you
from exploring it yourself if you're interested in it.

Jamie



------------------------------

Date: Wed, 18 Feb 2004 22:34:24 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: more stripping
Message-Id: <c10p9g$ijt$1@wisteria.csv.warwick.ac.uk>


thumb_42@yahoo.com wrote:
> Michael Hill <hillmw@ram.lmtas.lmco.com> wrote:
> >> >
> >> > Can anyone talk to what security holes may be there?
> >> 
> >> Google may be very educational (hint: this topic has been discussed a few
> >> times before).
> >> 
> >> jue
> > 
> > I'm not asking for a comprehensive listing of security holes using cgi,
> > but rather inherent security holes because I am using *hand rolled* cgi
> > instead of the cgi module.
> 
> In general I don't see many *security problems* with rolling your own parsing.
> (except maybe someone giving you bogus data or posting way more data
> than they really ought to, or feeding you data that some how chokes up your
> regex's into doing things it shouldn't.)

err... and what are these if not security problems? And pretty serious
ones at that.

Ben

-- 
And if you wanna make sense / Whatcha looking at me for?          (Fiona Apple)
                            * ben@morrow.me.uk *


------------------------------

Date: Wed, 18 Feb 2004 17:58:01 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: more stripping
Message-Id: <-qWdnZvVVsJhcK7d4p2dnA@adelphia.com>

thumb_42@yahoo.com wrote:

> I should hope we've all tried it once
> or twice, just to see what it's like..

I've done it in C. Doing CGI in C is what got me started with Perl, thinking
"There's GOT to be a better f**king way to do this..." :-)

> I've ever had (and they really weren't that great
> of 'reasons') were times before CGI.pm was standard

My biggest beef with CGI.pm is that it isn't focused. It takes a "shotgun"
approach of providing everything that might be useful in the most common
case of input from and output to HTML forms. Thus, it includes a boatload
of HTML form-generation methods that have *nothing* to do with the Common
Gateway Interface.

As I understand it, those methods are autoloaded, so there's hardly any
penalty for them at run-time. My dislike of them is conceptual - a module
called "CGI.pm" should focus on CGI, while something that concerns itself
with a particular type of markup that can be generated and sent to a client
belongs in a separate module. And the HTML-related methods *do* clutter up
the documentation, even though they don't cause any performance penalty.

So, I prefer to use CGI::Lite when that's available.

sherm--


------------------------------

Date: Wed, 18 Feb 2004 23:48:26 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: more stripping
Message-Id: <c10qte$1d0gf0$1@ID-184292.news.uni-berlin.de>

Ben Morrow wrote:
> thumb_42@yahoo.com wrote:
>> In general I don't see many *security problems* with rolling your
>> own parsing. (except maybe someone giving you bogus data or
>> posting way more data than they really ought to, or feeding you
>> data that some how chokes up your regex's into doing things it
>> shouldn't.)
> 
> err... and what are these if not security problems? And pretty
> serious ones at that.

They are. But once again a thread in this group has degenerated into
giving the impression that you are automatically protected from such
problems if you use CGI.pm, which AFAIK is not true. Such issues
reasonably need to be addressed irrespective of the method for parsing
CGI data.

-- 
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl



------------------------------

Date: Wed, 18 Feb 2004 18:33:52 -0000
From: "gnari" <gnari@simnet.is>
Subject: Re: Posting Usenet News Messages
Message-Id: <c10b4r$4br$1@news.simnet.is>

"Camelback Jones" <ignoromnibus@cochon.fr> wrote in message
news:c105v92kpq@enews2.newsguy.com...
> Steve May wrote:
>
>
> That depends on what you mean by "blank", and on what perl interprets as
> "blank".
actually it depends mostly on what NNTP considers blank, and I can tell
you for sure that NNTP does not consider a line with space to be empty.

> However, that's not the point I was making there, which was: "lie" and
> "incorrect" are not the same thing. What I said was not a "lie", it was -
> in terms of what NNTP apparently wants - "incorrect".

look back at the original context:

a) the statement was followed by a smilie
b) the joke was that the text 'This is the body of this message'
ended up in the headers because of the extra space. so it
was a counterfactual selfreferencial sentence. in other words, a lie
of the most entertaining sort. thus the smilie

gnari






------------------------------

Date: Wed, 18 Feb 2004 15:01:31 -0500
From: Ron Parker <ron.parker@povray.org>
Subject: Re: Posting Usenet News Messages
Message-Id: <slrnc37h4p.d33.ron.parker@mail.parkrrrr.com>

On Wed, 18 Feb 2004 11:00:54 -0600, Camelback Jones wrote:
> This depends on how the NNTP server interprets it. Many pieces of software 
> do in fact interpret a line as "blank" if there are no "printable" 
> characters on it, and an ascii 32 is not considered "printable". 

[ron@mail ron]$ cat >foodle.c
int main() {printf("%s", isprint(' ')?"printable":"not printable");}
[ron@mail ron]$ gcc foodle.c -o foodle
[ron@mail ron]$ ./foodle
printable

That said, I think your real problem might be that Net::NNTP 'post' is 
morally equivalent to Net::Cmd 'datasend' and neither of them makes any 
assumptions about where you wanted newlines.  That is, just calling your 
array 'lines' doesn't make it actual lines; you should put a newline at 
the end of each line.

As evidence, here's a couple of lines from the top of Net::Cmd:

 my $arr = @_ == 1 && ref($_[0]) ? $_[0] : \@_;
 my $line = join("" ,@$arr);

The first line sets $arr equal to a reference to the array you passed, 
whether or not what you passed was a reference.  The next line joins the
whole array into one long scalar.  Note the lack of newlines in the first
parameter to join.

So, to make the smallest possible change to your program, try replacing
the not-really-blank lines with an empty string, and then replacing 
[@lines] with [join("\n", @lines)] in your call to nntp->post.

Alternatively, you can just put the necessary newlines at the end of every 
element in @lines.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}


------------------------------

Date: Wed, 18 Feb 2004 19:50:18 -0000
From: "gnari" <gnari@simnet.is>
Subject: Re: Posting Usenet News Messages
Message-Id: <c10fk4$4rr$1@news.simnet.is>

"Camelback Jones" <ignoromnibus@cochon.fr> wrote in message
news:c105uu0kpq@enews2.newsguy.com...
> Tad McClellan wrote:
>
> > Camelback Jones <ignoromnibus@cochon.fr> wrote:
> >> Tad McClellan wrote:
> >
> > Because then you will make the 3-char sequence "\n \n" when
> > you are supposed to be making the 2-char sequence "\n\n".
> >
> >
> >> The spec calls for a blank line. What DO you want there?
> >
> >
> > A blank line.
> >
> > A line with a space character on it is not blank,
> > it has a space character on it.
> >
>
> This depends on how the NNTP server interprets it. Many pieces of software
> do in fact interpret a line as "blank" if there are no "printable"
> characters on it, and an ascii 32 is not considered "printable". I don't
> know whether NNTP considers it to be a "blank" line if it has one or more
> spaces, but I do know that at least this particular part of it - so far -
> hasn't seemed to make the slightest difference whether it's accepted for
> posting or not.

listen, you have an attitude problem. Tad is trying to help you. he is
pointing
out that you should not have a space at that position, and you start
nitpicking
about it, without any knowledge, when Tad most definitively has.

the fact that his help was not enough for you to make your program work
is not good reason to slap him.

> Thank you for trying, anyway. I'll let you know when I do get this
working,
> and then you'll know, too.

we wait in anticipation

gnari






------------------------------

Date: Wed, 18 Feb 2004 21:02:56 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Posting Usenet News Messages
Message-Id: <c10ju0$f9l$1@wisteria.csv.warwick.ac.uk>


parkerr@fwi.com wrote:
> On Wed, 18 Feb 2004 11:00:54 -0600, Camelback Jones wrote:
>
> That said, I think your real problem might be that Net::NNTP 'post' is 
> morally equivalent to Net::Cmd 'datasend' and neither of them makes any 
> assumptions about where you wanted newlines.  That is, just calling your 
> array 'lines' doesn't make it actual lines; you should put a newline at 
> the end of each line.

Almost certainly a CRLF pair.

> So, to make the smallest possible change to your program, try replacing
> the not-really-blank lines with an empty string, and then replacing 
> [@lines] with [join("\n", @lines)] in your call to nntp->post.

or simply
    join "\015\012", @lines;

Ben

-- 
'Deserve [death]? I daresay he did. Many live that deserve death. And some die
that deserve life. Can you give it to them? Then do not be too eager to deal
out death in judgement. For even the very wise cannot see all ends.'
 :-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-: ben@morrow.me.uk


------------------------------

Date: Wed, 18 Feb 2004 13:28:20 -0800
From: Steve May <drumspoorly@reachone.net>
Subject: Re: Posting Usenet News Messages
Message-Id: <1037lu1al2tok51@corp.supernews.com>

Camelback Jones wrote:
> Steve May wrote:
> 
> 
>>Camelback Jones wrote:
>>
>>>Tad McClellan wrote:
>>>
>>>
>>>
>>>>Camelback Jones <ignoromnibus@cochon.fr> wrote:
>>>>
>>>
>>>I've gone back and forth, with and without one or more "blank" lines,
>>>and, as stated, with and without newlines as part of the line content.
>>>Doesn't seem to have made a diff so far.
>>>
>>
>>Tad told you this in the process of kindly giving you a few pointers
>>on other potential problems with your code.
>>
> 
> 
> Definitely, there are some pointers, I agree. "Kindly" is an assumption 
> that may or may not be valid: neither you nor I know his motive(s) and 
> "kindness" may or may not play a part. I certainly appreciate his attempts, 
> whatever his motives may be, at any rate. However, the fact remains that - 
> as helpful as they may be - they haven't resulted in the code functioning, 
> and I merely report that fact; I can't see any reason for you to take 
> exception to my statement.
> 
> 


<snip>

> 
> Tad didn't seem to have a working example of what I was trying to do - do 
> you? Or can you see something wrong with either the construction or the 
> approach? 
> 

What part of "a line with a space in it is not a blank line" is so hard to
grasp?

Sheesh! :-)

Now a cursory search on Google turned up this page:

http://freebooks.by.ru/view/RedHatLinux6Unleashed/rhl6u320.htm

and this sample (which I take no credit/blame for):

LISTING 31.8  Posting an Article to Usenet

#!/usr/bin/perl
open (POST, "post.file");
@post = <POST>;
close POST;
use Net::NNTP;
$NNTPhost = 'news';
$nntp = Net::NNTP->new($NNTPhost)
        or die "Cannot contact $NNTPhost: $!";
# $nntp->debug(1);
$nntp->post()
    or die "Could not post article: $!";
$nntp->datasend("Newsgroups: news.announce\n");
$nntp->datasend("Subject: FAQ - Frequently Asked Questions\n");
$nntp->datasend("From: ADMIN <root\@rcbowen.com>\n");
$nntp->datasend("\n\n");
for (@post)     {
      $nntp->datasend($_);
} #  End for
$nntp->quit;

*NOTE* the double new lines with no space between separating
the header and the body.

The above is not production quality, IMHO, as it is not
scoped, does not use warnings nor strict,
nor is it error trapped properly.

Bt it should get the point across....


s.



------------------------------

Date: Wed, 18 Feb 2004 17:08:52 -0500
From: Ron Parker <ron.parker@povray.org>
Subject: Re: Posting Usenet News Messages
Message-Id: <slrnc37ojk.dnv.ron.parker@mail.parkrrrr.com>

On Wed, 18 Feb 2004 21:02:56 +0000 (UTC), Ben Morrow wrote:
> parkerr@fwi.com wrote:
>> That said, I think your real problem might be that Net::NNTP 'post' is 
>> morally equivalent to Net::Cmd 'datasend' and neither of them makes any 
>> assumptions about where you wanted newlines.  That is, just calling your 
>> array 'lines' doesn't make it actual lines; you should put a newline at 
>> the end of each line.
> 
> Almost certainly a CRLF pair.

That'll work, but note that datasend changes bare newlines to CRLF.

>> So, to make the smallest possible change to your program, try replacing
>> the not-really-blank lines with an empty string, and then replacing 
>> [@lines] with [join("\n", @lines)] in your call to nntp->post.
> 
> or simply
>     join "\015\012", @lines;

I'm partial to \r and \n myself, not being overly fond of octal.  TMTOWTDI,
of course.  And you're right about not needing the reference; I don't know
what came over me.

-- 
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}


------------------------------

Date: Wed, 18 Feb 2004 23:03:57 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Posting Usenet News Messages
Message-Id: <c10r0t$jih$1@wisteria.csv.warwick.ac.uk>


parkerr@fwi.com wrote:
> On Wed, 18 Feb 2004 21:02:56 +0000 (UTC), Ben Morrow wrote:
> > parkerr@fwi.com wrote:
> > 
> > Almost certainly a CRLF pair.
> 
> That'll work, but note that datasend changes bare newlines to CRLF.

Ah right, DWIM... didn't know that. (yes, I (c|sh)ould have read the docs).

> > or simply
> >     join "\015\012", @lines;
> 
> I'm partial to \r and \n myself, not being overly fond of octal.  TMTOWTDI,
> of course.

 ...but, in this case, one is portable and the other isn't. Macs consider
\r to be \n and v.v. (as it were).

Ben

-- 
Like all men in Babylon I have been a proconsul; like all, a slave ... During
one lunar year, I have been declared invisible; I shrieked and was not heard,
I stole my bread and was not decapitated.
~ ben@morrow.me.uk ~                   Jorge Luis Borges, 'The Babylon Lottery'


------------------------------

Date: Wed, 18 Feb 2004 13:22:22 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Regular Expresions & pattern matching (mis)understanding
Message-Id: <slrnc37ere.6rg.tadmc@magna.augustmail.com>

Brian McCauley <nobull@mail.com> wrote:
> Ben Morrow <usenet@morrow.me.uk> writes:
>> Nils Petter Vaskinn <no@spam.for.me.invalid> wrote:
>> > 
>> > if ( /^(.*)<page>([0-9]+)<\/page>(.*)/ ) {
>> 
>> Bleech!
>> 
>> if ( m|^(.*)<page>(\d+)</page>(.*)| ) {


> In the case of
> a long regex I don't want to have to remeber that it's using some
> delimiter other than /.  Compared to the tiny effort of the extra
> keystoke to escape each / I don't think the small loss of readability
> is justified.


If I don't choose the paired type of delim, I at least choose
one that is not meta in regexes.

Then I just remind myself that this m// is using alternated 
delimiters by lining them up with m//x:

   if ( m!^(.*)<page>(\d+)</page>(.*)
         !x ) {

A perhaps homely style, but that's what I do nonetheless...


-- 
    Tad McClellan                          SGML consulting
    tadmc@augustmail.com                   Perl programming
    Fort Worth, Texas


------------------------------

Date: Wed, 18 Feb 2004 20:07:13 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Replacing unicode characters
Message-Id: <edh730p923m44skorc9rd45dm2tuedfgrt@4ax.com>

Tulan W. Hu wrote:

>you are right. I don't want the window only character set.
>I have no control on the input files because I got them from a vendor.
>I have to convert those utf8 files to latin1 for other programs.

Eh, Windows (cp 1252) is Latin-1 plus a few more printable characters
where Latin-1 has "control characters" (but actually nothing, it's a
"taboo zone").

>Is 'iso-8859-1' the same as 'latin1'?

Yes.

-- 
	Bart.


------------------------------

Date: Wed, 18 Feb 2004 20:14:39 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Replacing unicode characters
Message-Id: <ngh730ltk2bpv1tbt062777evb2pidu53m@4ax.com>

Alan J. Flavell wrote:

>By the way, don't forget that not all ISO repertoires are Latin. So,
>although they both start at 1, after a while, the numbering gets out
>of step: the encoding iso-8859-7 is for the Greek repertoire, not
>Latin-anything, and there are encodings for Cyrillic, Arabic,
>Hebrew; the iso encoding for the latin 9 repertoire is iso-8859-15,
>for example.

For more info on this, the best site I ever found is
<http://czyborra.com>, one (st the time) student's work. However, it's a
few years old, not really maintained, and worst of all, sometimes the
DNS doesn't even resolve -- which is a real shame. 

Google still has quite a lot of its pages in its cache, and perhaps
there are other websites that hold archive of old sites...

-- 
	Bart.


------------------------------

Date: Wed, 18 Feb 2004 16:11:06 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: suggestion for a best book
Message-Id: <slrnc37onq.70m.tadmc@magna.augustmail.com>

gabe <gabe@tyler.c0s.org> wrote:
> 
> consider this seconded
           ^^^^

What "this" is that?


-- 
    Tad McClellan                          SGML consulting
    tadmc@augustmail.com                   Perl programming
    Fort Worth, Texas


------------------------------

Date: 18 Feb 2004 14:41:58 -0800
From: gabe anzelini <usenet@c0s.org>
Subject: Re: suggestion for a best book
Message-Id: <86brnwko21.fsf@tyler.c0s.org>


sorry havent (still) gotten quoting working in gnus, i was seconding "mastering regular expressions"


------------------------------

Date: Wed, 18 Feb 2004 22:45:12 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: suggestion for a best book
Message-Id: <x7fzd8roqv.fsf@mail.sysarch.com>

>>>>> "ga" == gabe anzelini <usenet@c0s.org> writes:

  ga> sorry havent (still) gotten quoting working in gnus, i was
  ga> seconding "mastering regular expressions"

use supercite. makes it very easy. should be enabled with gnus/email

uri

-- 
Uri Guttman  ------  uri@stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org


------------------------------

Date: 18 Feb 2004 11:17:03 -0800
From: sudip@ureach.com (Sudip)
Subject: Sybperl - how to specify my own interfaces file
Message-Id: <6cf0b768.0402181117.21bcad3e@posting.google.com>

Hi,
I want to specify my own interfaces file - instead of the default
$SYBASE/interfaces - to my sybperl program ( I am using CTlib).
I am finding a place to mention additional parameters in a hash as
additional attributes.
But neither I am being able to find what exactly ( I mean - a list )
can be specified in there nor I am sure whether that is the place to
override default $SYBASE/interfaces.
I guess it has already been done many times by many people.

Can anybody pls. help me in this case.

Thanks in advance.

Sudip


------------------------------

Date: Wed, 18 Feb 2004 19:23:31 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Sybperl - how to specify my own interfaces file
Message-Id: <x74qtour7w.fsf@mail.sysarch.com>

>>>>> "S" == Sudip  <sudip@ureach.com> writes:

  S> I want to specify my own interfaces file - instead of the default
  S> $SYBASE/interfaces - to my sybperl program ( I am using CTlib).

are you really using sybperl? that is based on perl4 and way way way
obsolete and has security holes and all sorts of other problems.

upgrade to perl5 and DBI and you will save lots of trouble in other
areas as well.

and IIRC, you can set the SYBASE environment variable in the shell or in
%ENV in perl to set the path to interfaces.

but upgrade to perl5. no one uses sybperl anymore. we are talking 7+
years at least.

uri

-- 
Uri Guttman  ------  uri@stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org


------------------------------

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 6157
***************************************


home help back first fref pref prev next nref lref last post