[12165] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 5765 Volume: 8

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon May 24 16:27:33 1999

Date: Mon, 24 May 99 12:00:19 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Mon, 24 May 1999     Volume: 8 Number: 5765

Today's topics:
        color map allocation <mtg82814@melsud.res.ray.com>
    Re: FAQ 4.16: Does Perl have a year 2000 problem? Is Pe (John Klassa)
    Re: FAQ 4.16: Does Perl have a year 2000 problem? Is Pe (Ilya Zakharevich)
    Re: Getting Column headers from DB (Dave Cross)
    Re: How to check for ASCII? <rp5280@email.sps.mot.com>
    Re: Mac-specific Perl help requested - The Answer (yet  (Chris Nandor)
    Re: Mac-specific Perl help requested - The Answer (yet  <neeri@iis.ee.ethz.ch>
    Re: Mac-specific Perl help requested - The Answer (yet  <josh@bitwell.net>
    Re: Mac-specific Perl help requested - The Answer <josh@bitwell.net>
        need relational database (anonymous)
    Re: Perl "constructors" <jeromeo@atrieva.com>
    Re: Perl compiler...If or when (Greg Bacon)
    Re: Perl in the News: _Cryptonomicon (Marko R. Riedel)
    Re: Perl in the News: _Cryptonomicon <tchrist@mox.perl.com>
        regexp question <b-camp@students.uiuc.edu>
        Resolving variables in text files <jzahn@softdisk.com>
    Re: Resolving variables in text files <tchrist@mox.perl.com>
    Re: Resolving variables in text files <tchrist@mox.perl.com>
    Re: Retrieving web pages (Dave Cross)
        Saving and retrieving file..Help <portboy@home.com>
    Re: system info <bill@fccj.org>
    Re: the user or 'require' vs. 'use' when using constant <abey@cs.ucr.edu>
        Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)

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

Date: Mon, 24 May 1999 12:34:34 -0400
From: Mike Godfrey <mtg82814@melsud.res.ray.com>
Subject: color map allocation
Message-Id: <37497F99.7B779DF6@melsud.res.ray.com>

this really isn't a perl question, but this group seems the most
computer knowledgable.  i'm using a sparcstation 20,  at times when i
bring up a color x term or some application that uses a few basic
colors, the program cannot allocate the colrs because the color map is
all full.  usually this is because i have netscape running or some other
graphic intensive application.  is there a way to allocate some colors
when i log in, maybe in the .cshrc file or something like that.  i know
with netscape that I can just run it with it's own color map, but it's
not really netscape i have problems with.

thanks.

-mike



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

Date: 24 May 1999 17:32:14 GMT
From: klassa@aur.alcatel.com (John Klassa)
Subject: Re: FAQ 4.16: Does Perl have a year 2000 problem? Is Perl Y2K compliant?
Message-Id: <7ic2eu$scq$1@aurwww.aur.alcatel.com>

On 24 May 1999 16:37:55 GMT, Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
  > understandable: *all* the existing versions of Perl have the result of
  > 
  >    $a = $b + $c;
  > 
  > *undefined*!  You need one of my latest jumbo patches to make $a
  > depend on *values* of $b and $c (and, of course, active pragmas) only,
  > and not on the *history of access* to the values of $b and $c.

Would you mind explaining this a bit further...?

-- 
John Klassa / Alcatel USA / Raleigh, NC, USA


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

Date: 24 May 1999 18:44:55 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: FAQ 4.16: Does Perl have a year 2000 problem? Is Perl Y2K compliant?
Message-Id: <7ic6n7$slk$1@mathserv.mps.ohio-state.edu>

[A complimentary Cc of this posting was sent to John Klassa
<klassa@aur.alcatel.com>],
who wrote in article <7ic2eu$scq$1@aurwww.aur.alcatel.com>:
>   > understandable: *all* the existing versions of Perl have the result of
>   > 
>   >    $a = $b + $c;
>   > 
>   > *undefined*!  You need one of my latest jumbo patches to make $a
>   > depend on *values* of $b and $c (and, of course, active pragmas) only,
>   > and not on the *history of access* to the values of $b and $c.
> 
> Would you mind explaining this a bit further...?

> perl -wle '$a=shift; $b = shift; $d = substr $a,$a if shift;  $c = $a  + $b; print $c' 5555555555 1
Name "main::d" used only once: possible typo at -e line 1.
5555555556

> perl -wle '$a=shift; $b = shift; $d = substr $a,$a if shift; $c = $a + $b; print $c' 5555555555 1 1
Name "main::d" used only once: possible typo at -e line 1.
substr outside of string at -e line 1.
1260588260

(differ only by the third ARGV term)

Hope this helps (?!),
Ilya


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

Date: Mon, 24 May 1999 17:27:42 GMT
From: dave@mag-sol.com (Dave Cross)
Subject: Re: Getting Column headers from DB
Message-Id: <37498b70.3948065@news.demon.co.uk>

On Fri, 21 May 1999 14:26:43 -0400, Umashankar Kotturu
<adityauma@hotmail.com> wrote:

>hi,
>
>I am accessing MS-access from Perl using dbi drivers.
>
>When I make a query to the database I get the data. How can I get the
>header also into the program variables ?

If you have a DBI statement handle ($sth) you can get a reference to
an array of column names from

my $names = $sth->{NAME};

You can then get the individual column names from

my $col = $names->[0];
etc...

Dave...

Dave Cross <dave@dave.org.uk>
<http://www.dave.org.uk>


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

Date: Mon, 24 May 1999 11:28:31 -0700
From: Mike Garcia <rp5280@email.sps.mot.com>
To: Larry Rosler <lr@hpl.hp.com>
Subject: Re: How to check for ASCII?
Message-Id: <37499A49.CAC42EB7@email.sps.mot.com>

Hey Larry,

Thanks for the info, but I thought you were a bit rude in calling my v-card
"crap"!
That is something that is required by my work and I didn't know it would be
posted to the news group.

Mike



Larry Rosler wrote:

> [Posted and a courtesy copy mailed.]
>
> In article <3745E915.28518DD3@email.sps.mot.com> on Fri, 21 May 1999
> 16:15:55 -0700, Mike Garcia <rp5280@email.sps.mot.com> says...
> > I'm developing a program and there is a check I need to do for a non
> > numeric value on a variable.  Is there an easy way to do this in Perl 5?
>
> Your question isn't quite clear in view of your Subject.  Perhaps the
> answer is found in perlfaq4:  "How do I determine whether a scalar is a
> number/whole/integer/float?"
>
> > Please email me at rp5280@email.sps.mot.com
>
> Sure, as you didn't munge your e-mail address.
>
> > Mike
> > begin:          vcard
> > ...
>
> But please don't pollute your posts with this crap in the future.
>
> --
> (Just Another Larry) Rosler
> Hewlett-Packard Company
> http://www.hpl.hp.com/personal/Larry_Rosler/
> lr@hpl.hp.com





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

Date: Mon, 24 May 1999 17:09:29 GMT
From: pudge@pobox.com (Chris Nandor)
Subject: Re: Mac-specific Perl help requested - The Answer (yet another followup)
Message-Id: <pudge-2405991309300001@192.168.0.77>

In article <3749854A.57F6@bitwell.net>, josh@bitwell.net wrote:

# Chris Nandor wrote:
# > 
# > In article <3748E22A.60BF@bitwell.net>, josh@bitwell.net wrote:
# > 
# > # Henry, \n is not an operating system definition; it's a Perl definition.
# > # On UNIX, it corresponds to ASCII 10 (\f?). On Mac, ASCII 13 (\r). The
# > # mapping of \n is not immutable.
# > 
# > You're wrong.  Perl depends on the C compiler's definition of \n, it does
# > not supply its own.
# 
# The behavior can be controlled and modified.

So?  You said it was a Perl definition.  It isn't.  That is my point.


# > # Insulting me serves no useful purpose.
# > 
# > Yet insulting Matthias serves a purpose?
# 
# I would appreciate if you would quote the passage from any post I've
# made which attacks or insults Matthias. Upon review, I'm confident
# you'll find none.

Well, you said this reflects poorly on him.  If you don't mean he looks
poorly in your eyes, then whose eyes are you referring to?  You also said
he had a lack of respect for compatibility issues and that he shirked some
responsibility.  You insinuated very clearly that he skimped on
documentation for personal gain.  Those all look like insults to me.


# >It was also where you asserted that MacPerl does things improperly,
which is incorrect.
# 
# MacPerl's behavior deviates from Perl's.

No, it doesn't.  \n, in Perl, is the platform-specific newline.  It is not
LF, it is not CRLF, it is not CR, and it is not "best guess".  You are
wrong.


# Upon doing this, please explain to me how you can say this variance
# doesn't exist. If you come to agree that the variance does in fact
# exist, please explain to me why you and others are so off-put by the
# notion that the variance should be documented, and that the
# responsibility for primary documentation lies with the developer.

First, it was documented.  You even quoted it.

""\n" on a Mac means ASCII 13, as opposed to Unix, where it means ASCII
10. If you want ASCII 10, write "\012"."

I don't know how much more clear it can be.  You keep saying this behavior
is undocumented, but you know that isn't true.

Second, as I have established, the behavior is not incorrect or deviant. 
Behavior is defined to be variant, so variant behavior is not deviant. 
That's like saying MacPerl is deviant because $^O returns "MacOS".  It is
supposed to.

-- 
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])


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

Date: 24 May 1999 20:25:33 +0200
From: Matthias Neeracher <neeri@iis.ee.ethz.ch>
Subject: Re: Mac-specific Perl help requested - The Answer (yet another followup)
Message-Id: <86aeuucoki.fsf@zinal.ee.ethz.ch>

In article <3749854A.57F6@bitwell.net>, Josh Pointer <josh@bitwell.net> writes:
> Chris Nandor wrote:
>> In article <3748E22A.60BF@bitwell.net>, josh@bitwell.net wrote:
>> 
>> # Henry, \n is not an operating system definition; it's a Perl definition.
>> # On UNIX, it corresponds to ASCII 10 (\f?). On Mac, ASCII 13 (\r). The
>> # mapping of \n is not immutable.
>> 
>> You're wrong.  Perl depends on the C compiler's definition of \n, it does
>> not supply its own.

> The behavior can be controlled and modified.

You have not come up with a compelling reason to do so.

>> # Insulting me serves no useful purpose.
>> 
>> Yet insulting Matthias serves a purpose?

> I would appreciate if you would quote the passage from any post I've
> made which attacks or insults Matthias. Upon review, I'm confident
> you'll find none.

<3748867C.7A5B@bitwell.net>:
# quoted above the MacPerl documentation's full treatment of this matter. It's
# insufficient at best, and it reflects poorly on the developer.
# [...]
# PTF is to be commended for doing what they can to make up for the
# developer's shortcomings.
# [...]
# Skimping on software (particularly Open Source) documentation in the hopes
# of selling add ons is a losing proposition.

Maybe it's just me, but I'd consider those statements attacks, and I find the
insinuation in the third passage that I skimped on documentation in the hope of
selling add ons highly insulting.

>> It was also where you asserted that MacPerl does things improperly, which is incorrect.

> MacPerl's behavior deviates from Perl's. Period. The method for dealing
> with a given text file in a given situation varies.

The files that you wanted MacPerl to handle are not "text" files in the MacOS
definition. 

> That behavior is not documented.

You quoted the sentence in the documentation which documents it. A word to the
wise is enough, and you'll have to forgive me for identifying the wise as my
primary target market.

> [..] please explain to me why you and others are so off-put by the
> notion that the variance should be documented, and that the
> responsibility for primary documentation lies with the developer.

I suppose they are just old fashioned, clinging to the antiquated belief that
it is my prerogative to decide how I spend my time and everyone else's right to
modify the MacPerl distribution (which is open source, after all) as they see
fit. You, on the other hand, have clearly grasped the modern school of open
software thinking, where the users pontificate about the developer's
obligations to them.

Matthias

-- 
Matthias Neeracher   <neeri@iis.ee.ethz.ch>   http://www.iis.ee.ethz.ch/~neeri
  "When someone says ``I want a programming language in which I need only say
   what I wish done,'' give him a lollipop" -- Alan J. Perlis
   


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

Date: Mon, 24 May 1999 18:46:55 GMT
From: Josh Pointer <josh@bitwell.net>
Subject: Re: Mac-specific Perl help requested - The Answer (yet another followup)
Message-Id: <37499F78.50EA@bitwell.net>

>Chris Nandor wrote:
> #
> # The behavior can be controlled and modified.
> 
> So?  You said it was a Perl definition.  It isn't.  That is my point.

And I gave a definition of default, which says that the original and
primary platform's behaviors should be considered defaults. Perl treats
\012 as newline. That should be considered default. Any variance from
that default should be properly documented.

> # > Yet insulting Matthias serves a purpose?
> #
> # I would appreciate if you would quote the passage from any post I've
> # made which attacks or insults Matthias. Upon review, I'm confident
> # you'll find none.
> 
> Well, you said this reflects poorly on him. 

a. It does reflect poorly on him. He should care about these things.
That's a criticism, not a personal attack.

> If you don't mean he looks poorly in your eyes, then whose eyes are you referring to? 

b. Those are, in fact, my eyes I'm referring to.

> You also said
> he had a lack of respect for compatibility issues 

c. Yes, I believe a failure to properly document non-standard behavior
(using my definition of default) does a disservice to users,
particularly with respect to a port of a language which holds
portability as one of its fundamental tenets.

> and that he shirked some responsibility.  

d. Yes, I believe documentation is the developer's responsibility.

> You insinuated very clearly that he skimped on
> documentation for personal gain.  

e. I intended no such insinuation. If anyone else here professes in good
faith to have inferred the same slur in that passage, I'll assume I
failed to clearly communicate my point and apologize at once to Matthias
for such an ugly misunderstanding. Barring that, I can only fault you
with ascribing meaning to that passage irresponsibly.

>Those all look like insults to me.

Then our definitions of "insult" diverge greatly, to say the least.
Points a-d were criticisms, valid in my judgement. Criticism != insult.
Criticism is rational, grounded, and intended to acheive a result.
Insult is emotional, destructive, and intended to cause pain.

If your interpretation of e. is a common one, then that is an insult,
and a greivous one. It was not intended as such and if I find your
interpretation to be widely shared, I will respond appropriately, as
would, I hope, anyone in this forum who engages in meaningless and
reckless personal attacks.

> # >It was also where you asserted that MacPerl does things improperly,
> which is incorrect.
> #
> # MacPerl's behavior deviates from Perl's.
> 
> No, it doesn't.  \n, in Perl, is the platform-specific newline.  It is not
> LF, it is not CRLF, it is not CR, and it is not "best guess".  You are
> wrong.

Chris, Perl does one thing, MacPerl does the same thing in a different
way.

> # Upon doing this, please explain to me how you can say this variance
> # doesn't exist. If you come to agree that the variance does in fact
> # exist, please explain to me why you and others are so off-put by the
> # notion that the variance should be documented, and that the
> # responsibility for primary documentation lies with the developer.
> 
> First, it was documented.  You even quoted it.
> 
> ""\n" on a Mac means ASCII 13, as opposed to Unix, where it means ASCII
> 10. If you want ASCII 10, write "\012"."
> 
> I don't know how much more clear it can be. 

I do. Read my revision.

> You keep saying this behavior is undocumented, but you know that isn't true.

That's not what I keep saying. What I've said with regard to the MacPerl
docuentation's treatment of this matter is as follows:

a. properly document Sun, 23 May 1999 22:48:05 GMT
b. the MacPerl documentation failed Sun, 23 May 1999 22:48:05 GMT
c. to adequately address this issue, Sun, 23 May 1999 03:31:21 GMT
d. the MacPerl documentation failed to adequately address this issue
Sun, 23 May 1999 13:57:48 GMT
e. developer's responsibility to properly document publicly released
software Sun, 23 May 1999 22:48:05 GMT
f. It's insufficient at best Sun, 23 May 1999 22:48:05 GMT
g. differences should be clearly and meaningfully documented (in
documentation accompanying the
distribution) Sun, 23 May 1999 22:48:05 GMT
h. the responsibility of properly documenting his work Sun, 23 May 1999
22:48:05 GMT
i. The documentation should have addressed the issue. Mon, 24 May 1999
05:19:14 GMT
j. to properly document his project's behavior  Mon, 24 May 1999
05:19:14 GMT
k. That behavior should be documented   Mon, 24 May 1999 05:19:14 GMT
l. That behavior is not documented.   Mon, 24 May 1999 05:19:14 GMT
m. That behavior is not documented. Mon, 24 May 1999 16:55:13 GMT
n. the variance should be documented Mon, 24 May 1999 16:55:13 GMT

If you'll review those passages in my posts, you'll see I was very
precise with my language well into this discussion and liberal in my use
of modifiers. I didn't say the behavior was undocumented, I said it was
insufficiently documented. You'll notice I become less precise in my
language at k. This was well into the thread and I assumed you and other
were familiar with my point by then. I know you were involved by then
and must have been well aware of the spirit of the language even when it
became less precise, so your representation of my comments is incorrect
and unfair. I most certainly do not keep repeating something which I
know to be untrue.
 
> Second, as I have established, the behavior is not incorrect or deviant.
> Behavior is defined to be variant, so variant behavior is not deviant.
> That's like saying MacPerl is deviant because $^O returns "MacOS".  It is
> supposed to.

Deviant as in "deviates from the norm," Chris, again referring to my
definition of default. If it will facilitate the resolution of this
matter, substitute "different" for "deviant."

> --
> Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
> %PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

Still wondering,

Josh Pointer
josh@bitwell.net


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

Date: Mon, 24 May 1999 17:34:50 GMT
From: Josh Pointer <josh@bitwell.net>
Subject: Re: Mac-specific Perl help requested - The Answer
Message-Id: <37498E94.705C@bitwell.net>

Bart Lateur wrote:
> 
> >I don't understand what the lesson is.
> 
> That they should put chairs in bookshops?
> 
>         Bart.

Precisely. Do you have any idea how uncomfortable that stack of Visual
Basic doorstops was (colorful covers notwithstanding)?

Regards,

Josh Pointer
josh@bitwell.net


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

Date: Mon, 24 May 1999 18:49:43 GMT
From: quikscor@ix.netcom.com (anonymous)
Subject: need relational database
Message-Id: <37499e5a.100722162@nntp.ix.netcom.com>

I'm in the beginning stages of designing a website.  It looks like I'm
going to need a relational database.  How do you hook up with such a
resource in Perl?  I've only used FoxPro and have never used databases
with the other languages I'm familiar with, C++ and Java.

- j


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

Date: Mon, 24 May 1999 10:38:29 -0700
From: Jerome O'Neil <jeromeo@atrieva.com>
To: John Porter <jdporter@min.net>
Subject: Re: Perl "constructors"
Message-Id: <37498E95.2A2ABC24@atrieva.com>

John Porter wrote:

> I'm one of the rare Perl advocates who claims that Perl is really
> crummy as a first, or even second language.

While I take the opposite view (I think perl is a great first language),
I have always thought my opinion was in the minority.


-- 
Jerome O'Neil, Operations and Information Services
Atrieva Corporation, 600 University St., Ste. 911, Seattle, WA 98101
jeromeo@atrieva.com - Voice:206/749-2947 
The Atrieva Service: Safe and Easy Online Backup  http://www.atrieva.com


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

Date: 24 May 1999 17:56:45 GMT
From: gbacon@itsc.uah.edu (Greg Bacon)
Subject: Re: Perl compiler...If or when
Message-Id: <7ic3st$ba9$1@info2.uah.edu>

In article <7i3tcb$uit$1@nnrp1.deja.com>,
	Corus <corus@my-dejanews.com> writes:
: I don't hide my *personal* reason for wanting a compiler. (One without
: the decompiler)

The "decompiler" already exists!  I imagine people will be much more
motivated to work on the decompiler than the compiler if, for nothing
else, to thwart the efforts of evil source hoarders.

: It is to hide my code from evil eyes. Or at least make it considerably
: harder to get at.

The problem of someone depriving you of your rights to your intellectual
property is a social one, not a technical one.  There are copyright laws
to protect you from this.  I suggest you put them to use.

: If someone has the skills to succesfully de-compile code that wasn't
: intended to be "decompileable", then they probably would equally have
: the skill to not have resort to doing it.
: (In the majority of circumstances)

You're forgetting about the time factor.  It takes time to develop a
large piece of software.

: Perl developers will call me a disgrace to open source software but they
: would be doing that from the safety secured for them by their in-depth
: knowledge of Perl.

Do you mean Perl or perl?  There is a difference, and your statement's
meaning swings widely depending on whether that one bit is set or clear.

: Knowledge that is untouchable by 99.999% of the Perl user community even
: if Perl's code is out there for everyone to see and change at their
: whim.

Here I assume you mean perl.  Don't you know that it's perfectly legal
and acceptable for someone to change perl in some way, rename it, and
redistribute (possibly sell) it?  Larry's giving away something of such
tremendous value as perl is a fine example for us all.

: A language's or OS's strength lies its popularity. Obviously popularity
: is a factor of marketing as well as value that the end-user will attain
: from its use.

I don't care how popular MS Exchange is, it still sucks.  People who
know aren't influenced by marketing.  I would be much more likely to
purchase or use a product that was upfront and forthcoming about both
its technical merits and downfalls.  Glitz is for PHMs.

: The same does not apply to a script or application developer mainly due
: to the fact that his/her work is usually considerably, to say the least,
: less complex as well as much smaller in size, and hence easier to
: replicate in either its original form or otherwise.
: Irrespective of how well he has tried to legaly safeguard his efforts.

I guess you haven't read _The Tao of Programming_:

    There was once a programmer who was attached to the court of the
    warlord of Wu.  The warlord asked the programmer: "Which is easier
    to design: an accounting package or an operating system?" 

    "An operating system," replied the programmer. 

    The warlord uttered an exclamation of disbelief. "Surely an
    accounting package is trivial next to the complexity of an operating
    system," he said. 

    "Not so," said the programmer, "when designing an accounting
    package, the programmer operates as a mediator between people having
    different ideas: how it must operate, how its reports must appear,
    and how it must conform to the tax laws. By contrast, an operating
    system is not limited by outside appearances.  When designing an
    operating system, the programmer seeks the simplest harmony between
    machine and ideas. This is why an operating system is easier to
    design." 

    The warlord of Wu nodded and smiled. "That is all good and well, but
    which is easier to debug?" 

    The programmer made no reply. 

: A couple of days ago I saw a guy flamed in a thread in which he had made
: enquiries about the "byte code saver" (I'll call it a compiler as I've
: come to associate the word with something that sucks source and spits
: binary)

So does gcc fail to be a compiler (standards issues aside) when I invoke
it as

    % gcc -o /dev/null hello.c

: in the hope that it would safeguard his employer from illicit
: copying of proprietary software.

To believe that this is possible is to believe in a lie.

: I suppose some of you think of it as being insignificant for a company
: trying to make a break in a market as competitive as the net, and
: spending thousands of currency units (just being politically correct)
: *paying* people like *us* to do work for them, only to find out that the
: product of theirs and our efforts was tarred onto a floppy and sold to
: their competitor next door by an employee that doesn't know the
: difference between a scalar and his socks. (the ones you wear on your
: feet no the otherones)

Well... that employee would be liable as well as the competitor.  Why
not take them to court rather than punish legitimate users?

: People hard done by Perl in such a way will inevitably seek refuge in a
: language whose binaries are a bit more secure.

Why must Perl help people who won't help themselves?  The people in
your scenario had legal recourse.  Still, I wonder why they would
hire people they couldn't trust.

: I, personally will pay $5000 for a Perl compiler that will do its best
: to make its binaries as hard as "compilably" possible to decompile. And
: I'm willing to pay half of it the minute a timeframe for its delivery
: has been established.

So then would you let the rest of the world benefit from this work, or
would you hoard that too?  How many times do we have to tell you that
there's already a "decompiler"?

: The compiler once complete can be sold as an add-on to the standard Perl
: distribution for say $100 a piece with the initial "stake holders"
: financially sharing in its success.

If only I had an Anti Bad Idea gun, I'd shoot that down quicker than
a Cessna pulling an "Allah sucks!" banner over Baghdad.

Greg
-- 
Script kiddies can skate Cobol.
    -- Tom Christiansen


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

Date: 24 May 1999 20:27:22 +0200
From: mriedel@neuearbeit.de (Marko R. Riedel)
Subject: Re: Perl in the News: _Cryptonomicon
Message-Id: <lzbtfa2uid.fsf@linux_sexi.neuearbeit.de>

Tom Christiansen <tchrist@mox.perl.com> writes:

> If you haven't checked out the crypto Perl program
> in Neal Stephenson's newest novel, _Cryptonomicon_,
> you can see it explained at 
> 
>     http://www.counterpane.com/solitaire.html
> 
> Source is there, too.
> 
> --tom
> -- 
> "I'd explain it to you, but your head would blow up." 
> 				- Steven Wright 

I've implemented the algorithm for small size decks. (Parameterize
according to the size of the deck. The cards with the two highest
values are the two jokers.) Assume that my implementation is correct
and that we can generalize from small decks to large ones. It seems
that solitaire generates a poor keystream. The output included with
this message lists the cycles of the permutation graphs associated to
decks of size 6, 7 and 8 (node of origin, distance to cycle, length of
cycle).

[SOLITAIRE] > solcheck.pl 6
constructing graph ...... done.
[2 1 6 5 3 4] 45 55
[1 2 6 5 3 4] 8 10
[SOLITAIRE] > solcheck.pl 7
constructing graph ....... done.
[6 3 7 2 1 5 4] 207 5
[4 2 7 6 1 3 5] 21 4
[5 1 4 2 7 6 3] 8 19
[3 1 2 7 6 5 4] 30 37
[SOLITAIRE] > solcheck.pl 8
constructing graph ........ done.
[1 7 6 8 2 5 3 4] 134 104
[6 4 5 2 1 8 7 3] 54 287
[8 7 6 5 4 2 3 1] 1 144
[3 5 4 7 6 8 1 2] 246 11
[8 6 7 1 4 5 2 3] 1 5
[SNIP]


E.g. for a set of 5040 size 7 decks the maximum cycle obtained has
length 37 (!); there exists a key (8 6 7 1 4 5 2 3) for size 8 decks
whose keystream repeats after just five iterations, etc. These data
suggest that it may be worthwhile to investigate how bad keys might
be constructed.

Marko R. Riedel



#! /usr/bin/perl -w
#


sub generate {
  my ($data, $vflags, $vlist, $onfind)=@_;

  if($#$data>$#$vlist){
    for(my $ind=0; $ind<=$#$vflags; $ind++){
      if(!$vflags->[$ind]){
	$vflags->[$ind]=1; push @$vlist, $data->[$ind];
	generate($data, $vflags, $vlist, $onfind);
	pop @$vlist; $vflags->[$ind]=0;
      }
    }
  }
  else{
    &$onfind($vlist);
  }
}


sub nextperm {
  my ($aref) = @_;
  my ($apos, $bpos, $perm)=@$aref;
  my ($temp, $min, $max, $count);

  if($apos<$#$perm){
    $tmp=$$perm[$apos];
    $$perm[$apos]=$$perm[$apos+1];
    $$perm[$apos+1]=$tmp;

    $apos++;
    $bpos-- if $apos==$bpos;
  }
  else{
    $tmp=$$perm[$apos];
    @$perm[2..$#$perm]=@$perm[1..$#$perm-1];
    $$perm[1]=$tmp;

    $apos=1;
    $bpos++ if $bpos>0;
  }

  if($bpos<$#$perm-1){
    $tmp=$$perm[$bpos];
    $$perm[$bpos]=$$perm[$bpos+2];
    $$perm[$bpos+2]=$tmp;

    $tmp=$$perm[$bpos];
    $$perm[$bpos]=$$perm[$bpos+1];
    $$perm[$bpos+1]=$tmp;

    $bpos+=2;
    $apos-- if $apos==$bpos || $apos==$bpos-1;
  }
  elsif($bpos==$#$perm-1){
    $tmp=$$perm[$bpos];
    @$perm[2..$#$perm-1]=@$perm[1..$#$perm-2];
    $$perm[1]=$tmp;

    $apos= ($apos==0 || $apos==$#$perm ? 
	    $apos : $apos==1 ? $bpos : $apos+1);
    $bpos=1;
  }
  else{
    $tmp=$$perm[$bpos];
    @$perm[3..$#$perm]=@$perm[2..$#$perm-1];
    $$perm[2]=$tmp;

    $apos= ($apos==0 || $apos==1 ? 
	    $apos : $apos==2 ? $bpos : $apos+1);
    $bpos=2;
  }

  if($apos<$bpos){
    $min=$apos; $max=$bpos;
    $apos=$#$perm-$max; $bpos=$#$perm-$min;
  }
  else{
    $min=$bpos; $max=$apos;
    $apos=$#$perm-$min; $bpos=$#$perm-$max;
  }
  @$perm=(@$perm[$max+1..$#$perm], @$perm[$min..$max], @$perm[0..$min-1]);

  $count=$$perm[$#$perm]; $count-- if $count==$#$perm+1;
  @$perm=(@$perm[$count..$#$perm-1], @$perm[0..$count-1], $$perm[$#$perm]);
  $apos=($apos==$#$perm ? $apos :
	 0<=$apos && $apos<=$count-1 ? $apos+$#$perm-$count : $apos-$count);
  $bpos=($bpos==$#$perm ? $bpos :
	 0<=$bpos && $bpos<=$count-1 ? $bpos+$#$perm-$count : $bpos-$count);
  
  $aref[0]=$apos; $aref[1]=$bpos;
  
  return [$apos, $bpos, $perm];
}
  
MAIN:{
  my ($size)=@ARGV;
  my (@items)=(1..$size);
  my (%graph)=();

  $|=1;

  my $progress=-1; print "constructing graph ";
  generate(\@items, [(0) x $size], [],
	   sub 
	   { my $vlist=shift; my (@copy)=(@$vlist);
	     my (@deck)=(0, 0, \@copy);
  
	     for(my $i=0; $i<=$#copy; $i++){
	       $deck[0]=$i if $copy[$i]==$#copy;
	       $deck[1]=$i if $copy[$i]==$#copy+1;
	     }

	     if($copy[0]!=$progress){
	       print '.';
	       $progress=$copy[0];
	     }

	     nextperm(\@deck);
	     $graph{join(' ', @$vlist)}=join(' ', @copy);
	   });
  print " done.\n";

  my %dest=();

  foreach (keys %graph){
    my $node=$_;
    my $steps=1;
    my %walk=();

    while(not (defined($walk{$node}) || 
	       defined($dest{$node}))){
      $walk{$node}=$steps++;
      $node=$graph{$node};
    }

    print "[$node] $walk{$node} ", $steps-$walk{$node}-1, "\n"
      if not defined($dest{$node});

    while(my $key=each %walk){
      $dest{$key}=1;
    }
  }

  1;
}



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

Date: 24 May 1999 12:36:47 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Perl in the News: _Cryptonomicon
Message-Id: <37499c3f@cs.colorado.edu>

     [courtesy cc of this posting mailed to cited author]

In comp.lang.perl.misc, mriedel@neuearbeit.de (Marko R. Riedel) writes:
:It seems that solitaire generates a poor keystream. The output included
:with this message lists the cycles of the permutation graphs associated
:to decks of size 6, 7 and 8 (node of origin, distance to cycle, length
:of cycle).

Decks are 54 cards, not a half-dozen.  Or do I misunderstand you?

--tom
-- 


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

Date: Mon, 24 May 1999 12:54:05 -0500
From: Bryan Camp <b-camp@students.uiuc.edu>
Subject: regexp question
Message-Id: <Pine.SOL.3.96.990524112911.19586A-100000@ux9.cso.uiuc.edu>


Hello,

I'm having problems getting a regexp to work.

I'm reading in a data file with the following format:

999-999 RES SRC1=A120C65000000_CR08|NAME1 SRC2=A120C65000001_CR08|NAME2
999-998 RES SRC1=A120C65000002_CCC1|NAME3
999-997 CAP SRC1=A120C65000009_FAL4|NAME4 SRC2=_CRTY|NAME5

What I want to do is get rid of everything between
the = sign and the underscore sign, which can occur
multiple times in the same line:

999-999 RES SRC1=_CR08|NAME1 SRC2=_CR08|NAME2
999-998 RES SRC1=_CCC1|NAME3
999-997 CAP SRC1=_FAL4|NAME4 SRC2=_CRTY|NAME5

Here is what I have so far:

#!usr/bin/perl -w
open (FH, "+< $file");
while(<FH>){
  $sub =~ ( s/(/\b=\+_\b/)/g )
}
close (FH);

Can someone tell me what I'm doing wrong?

Thank you very much.

Bryan     



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

Date: Mon, 24 May 1999 13:21:38 -0500
From: "Jason Zahn" <jzahn@softdisk.com>
Subject: Resolving variables in text files
Message-Id: <7ic64u$so2$1@server4.softdisk.com>

I am trying to figure out how to resolve variable names that may be
contained in a text file. For instance if this is a text file:

<start of file>
Hi my name is $name
<end of file>

I would like to be able to open the file and print it line by line resolving
any variables that might be contained in the text. What needs to be added to
the following code to achive this.

open (INFILE, filename);

while <INFILE>
{
    print "$_"
}

close (INFILE);

This code would print "Hi my name is $name" when I want to evaluate $name
and have that print in place of the variable name.

Any help would be appreciated,

Thank you,
Jason Zahn
jzahn@softdisk.com




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

Date: 24 May 1999 12:39:02 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Resolving variables in text files
Message-Id: <37499cc6@cs.colorado.edu>

     [courtesy cc of this posting mailed to cited author]

In comp.lang.perl.misc, "Jason Zahn" <jzahn@softdisk.com> writes:
:I am trying to figure out how to resolve variable names that may be
:contained in a text file. For instance if this is a text file:
:
:<start of file>
:Hi my name is $name
:<end of file>

That's the wrong way to do it: you're conflating internal and external
name accessibility.  Please read this.

I wish I knew why people thought they should do this.  Sheesh.
I've never seen a C programmer make such a horrible design glitch.
Must be BASIC's fault.

--tom

=head2 How can I use a variable as a variable name?

Beginners often think they want to have a variable contain the name
of a variable.

    $fred    = 23;
    $varname = "fred";
    ++$$varname;         # $fred now 24

This works I<sometimes>, but it is a very bad idea for two reasons.

The first reason is that they I<only work on global variables>.
That means above that if $fred is a lexical variable created with my(),
that the code won't work at all: you'll accidentally access the global
and skip right over the private lexical altogether.  Global variables
are bad because they can easily collide accidentally and in general make
for non-scalable and confusing code.

Symbolic references are forbidden under the C<use strict> pragma.
They are not true references and consequently are not reference counted
or garbage collected.

The other reason why using a variable to hold the name of another
variable a bad idea is that the question often stems from a lack of
understanding of Perl data structures, particularly hashes.  By using
symbolic references, you are just using the package's symbol-table hash
(like C<%main::>) instead of a user-defined hash.  The solution is to
use your own hash or a real reference instead.

    $fred    = 23;
    $varname = "fred";
    $USER_VARS{$varname}++;  # not $$varname++

There we're using the %USER_VARS hash instead of symbolic references.
Sometimes this comes up in reading strings from the user with variable
references and wanting to expand them to the values of your perl
program's variables.  This is also a bad idea because it conflates the
program-addressable namespace and the user-addressable one.  Instead of
reading a string and expanding it to the actual contents of your program's
own variables:

    $str = 'this has a $fred and $barney in it';
    $str =~ s/(\$\w+)/$1/eeg;		  # need double eval

Instead, it would be better to keep a hash around like %USER_VARS and have
variable references actually refer to entries in that hash:

    $str =~ s/\$(\w+)/$USER_VARS{$1}/g;   # no /e here at all

That's faster, cleaner, and safer than the previous approach.  Of course,
you don't need to use a dollar sign.  You could use your own scheme to
make it less confusing, like bracketed percent symbols, etc.

    $str = 'this has a %fred% and %barney% in it';
    $str =~ s/%(\w+)%/$USER_VARS{$1}/g;   # no /e here at all

Another reason that folks sometimes think they want a variable to contain
the name of a variable is because they don't know how to build proper
data structures using hashes.  For example, let's say they wanted two
hashes in their program: %fred and %barney, and to use another scalar
variable to refer to those by name.

    $name = "fred";
    $$name{WIFE} = "wilma";     # set %fred

    $name = "barney";           
    $$name{WIFE} = "betty";	# set %barney

This is still a symbolic reference, and is still saddled with the
problems enumerated above.  It would be far better to write:

    $folks{"fred"}{WIFE}   = "wilma";
    $folks{"barney"}{WIFE} = "betty";

And just use a multilevel hash to start with.

The only times that you absolutely I<must> use symbolic references are
when you really must refer to the symbol table.  This may be because it's
something that can't take a real reference to, such as a format name.
Doing so may also be important for method calls, since these always go
through the symbol table for resolution.

In those cases, you would turn off C<strict 'refs'> temporarily so you
can play around with the symbol table.  For example:

    @colors = qw(red blue green yellow orange purple violet);
    for my $name (@colors) {
        no strict 'refs';  # renege for the block
        *$name = sub { "<FONT COLOR='$name'>@_</FONT>" };
    } 

All those functions (red(), blue(), green(), etc.) appear to be separate,
but the real code in the closure actually was compiled only once.

So, sometimes you might want to use symbolic references to directly
manipulate the symbol table.  This doesn't matter for formats, handles, and
subroutines, because they are always global -- you can't use my() on them.
But for scalars, arrays, and hashes -- and usually for subroutines --
you probably want to use hard references only.
-- 
"The reason you subscribe to a mailing list is you don't get all 
 the crap you get on netnews. "
	    --Dennis Ritchie


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

Date: 24 May 1999 12:39:41 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Resolving variables in text files
Message-Id: <37499ced@cs.colorado.edu>

     [courtesy cc of this posting mailed to cited author]

In comp.lang.perl.misc, "Jason Zahn" <jzahn@softdisk.com> writes:
:    print "$_"

Why are you quoting the variable?  What purpose does building
a new string serve?

--tom
-- 
And don't tell me there isn't one bit of difference between null and space,
because that's exactly how much difference there is.  :-)
        --Larry Wall in <10209@jpl-devvax.JPL.NASA.GOV>


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

Date: Mon, 24 May 1999 17:42:43 GMT
From: dave@dave.org.uk (Dave Cross)
Subject: Re: Retrieving web pages
Message-Id: <374a8dcd.4553431@news.demon.co.uk>

On Mon, 24 May 1999 15:37:24 +0100, "TwoSheds" <kevin.porter@fast.no>
wrote:

>Hi,
>could someone tell me how to use Perl to connect to interact with a web
>server.
>
>I have tried the following code (taken from the Camel book), but when I run
>it with the command
>
>perl test1.cgi www.somedomainname.com 80
>
>the program just seems to hang. The print commands don't even seem to
>produce any output, even though the prints that appear before anything
>hang-able.
>
>Comments for this quitenewbie?
>
>Here's the code I've been trying:

[snip]

For a simpler method to retrieve web pages you should get the LWP
module from CPAN
<http://www.cpan.org/modules/by-module/LWP/libwww-perl-5.43.tar.gz>.

To solve the problem with your prints not printing, add the line

$|++;

near the start of your script. To find out why that works, read the
article at

<http://www.plover.com/~mjd/perl/FAQs/Buffering.html>

hth,

dave...

Dave Cross <dave@dave.org.uk>
<http://www.dave.org.uk>


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

Date: Mon, 24 May 1999 17:36:55 GMT
From: Mitch <portboy@home.com>
Subject: Saving and retrieving file..Help
Message-Id: <37491E6F.73D86FDF@home.com>

I'm working on a script where the user is connected to the serial
console.  At the scripts command line, I'd like them to be able to use
the standard RZ and SZ commands from the ZModem protocol.  The reason
for using Zmodem, is the that box the user will be on, will not have
FTP, NFS, etc access to it.  The nic in the box is (and will remain that
way) in promiscuous mode.  Therefore, the box has no IP.

My question(s):

Is there an implementation of ZModem in perl that I can get my hands?
Where can I find some source (no matter the language) on Zmodem?

Thanks, Mitch



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

Date: Mon, 24 May 1999 14:31:25 -0400
From: "Bill Jones" <bill@fccj.org>
Subject: Re: system info
Message-Id: <37499ac1.0@usenet.fccj.cc.fl.us>

In article <7ibrjv$43c$1@nnrp1.deja.com>, cnsxxx9@my-dejanews.com wrote:


> pity I don't have ftp acces...firewall and all that
>
> :-(
>
>> Not exactly, but do research this at reference.perl.com,
>> via DejaNews, and get the OverCR script 9writtin in perl)
>> at
>>
>>     ftp://jaxlug.jaxcan.org/pub/overcr/overcr-1.49.02.tar.gz
>>
>> HTH,
>> -Sneex-  :]


Yes, that is a pity - there are so many programs, s/freely/Only/ig
available, by this method.

-Sneex-  :]
______________________________________________________________________
Bill Jones  Data Security Specialist  http://www.fccj.org/cgi/mail?dss
______________________________________________________________________
  We are the CLPM... Lower your standards and surrender your code...
  We will add your biological and technological distinctiveness to
  our own... Your thoughts will adapt to service us...
  ...Resistance is futile...

         Jacksonville Perl Mongers
         http://jacksonville.pm.org
         jax@jacksonville.pm.org


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

Date: Mon, 24 May 1999 11:11:51 -0700
From: Abraham Grief <abey@cs.ucr.edu>
To: John Hilgedick <jhilgedi@indiana.edu>
Subject: Re: the user or 'require' vs. 'use' when using constant module
Message-Id: <Pine.LNX.4.05.9905241101440.15578-100000@hill.cs.ucr.edu>


On Mon, 24 May 1999, John Hilgedick wrote:

> I ran into some odd behavior today and wanted to bounce it off the group.  I
> have a module I created in which I declare several constants.  I want to use
> those constants in a number of other cgi scripts.  If I "include" the module
> in the cgi script with 'require', the constants don't seem to be defined (I
> just get "0";s) but if I change 'require' to 'use', I get the proper values.
> 
> After reading up more on the differences between 'use' and 'require', it
> looks like 'require' doesn't "compile" your module until you actually
> 'reference a symbol in it'.  Now... since the constant module is really just
> a pragma that directs that constant declarations should be 'converted' into
> subroutines, perhaps these guys DON'T EXIST if you just refer to a constant
> in the module BEFORE you invoke any subroutines in that module.
> 
> Any thoughts?
> 
> -john

I think it's more likely that the reasons the constants don't exist is
that your module's import() function is not being called.  Use calls this
function, require doesn't, and it is usually the function that is
responsible for exporting symbols.  For instance, consider the following
script:

#!/usr/bin/perl -w
require 'Socket.pm';
my $a = &Socket::AF_INET;
my $b = AF_INET;
print "$a $b\n";

$b will not get the correct value for the AF_INET constant even though a
routine in Socket.pm has explicitly been called.  If you change the
"require 'Socket.pm';" to "use Socket;" however, the correct value for
AF_INET will be obtained.  This is because the symbol has been explicitly
exported to our package by the import function.





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

Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>


Administrivia:

Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing. 

]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body.  Majordomo will then send you instructions on how to confirm your
]subscription.  This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.

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.  

To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.

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.

The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.

The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.

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 V8 Issue 5765
**************************************

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