[8479] in Perl-Users-Digest
Perl-Users Digest, Issue: 2096 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Mar 14 01:07:23 1998
Date: Fri, 13 Mar 98 22:00:23 -0800
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 13 Mar 1998 Volume: 8 Number: 2096
Today's topics:
Re: $IFS variable eugene@vertical.net
Re: Can't find "from" and "subject" <rjk@coos.dartmouth.edu>
Re: closing files (sometimes not & effiency) <sp17@cornell.edu>
Re: Does anybody know how to do ftp in perl? (Devin L. Ganger)
Re: In the news .... <chasecreek.systemhouse@usa.net>
Re: Is there a "Newsgroup" for Newbies to Perl? rasta@spacestar.net
Re: Is there a "Newsgroup" for Newbies to Perl? (Devin L. Ganger)
learn <DOOKS@netcom.ca>
Re: newbie's 1st question <c..bojswbo@62.usenet.us.com>
Open format configuration (Was: Yet another packaging s (Huaiyu Zhu)
Re: Password protected <zero@sg-online.com>
Re: PGP / $PGPPASS <lutz@muc.de>
Re: Read one line of a file (Robert F. Harrison)
Re: User-interface Quandary (Robert F. Harrison)
Re: Using regex to initial cap a name (David Oswald)
Re: Way of testing whether a variable is blessed <rjk@coos.dartmouth.edu>
Re: Way of testing whether a variable is blessed <rjk@coos.dartmouth.edu>
Re: What is PERL? Learn JAVA instead? <lespin03@fiu.edu>
Re: Win32 Perl question <sp17@cornell.edu>
Re: Writing to a socket <chasecreek.systemhouse@usa.net>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 13 Mar 1998 22:48:45 -0600
From: eugene@vertical.net
Subject: Re: $IFS variable
Message-Id: <6ed24q$u6t$1@nnrp1.dejanews.com>
You recommend NOT using it?
I might be obtuse, but this is not clear. I wanted to know why perlsec
recommends this. man sh tells me what I already know about $IFS
and I still don't understand why unsetting it improves the security of a CGI
script (I've also never seen it used in CGI
scripts that otherwise go through all the security and untainting paces).
Thank you.
In article <6e6qr1$97a$1@cyprus.atlantic.net>,
chip@pobox.com wrote:
>
> According to eugene@vertical.net:
> >perlsec reccomends to set $IFS as follows:
> > $ENV{'IFS'} = '' if $ENV{'IFS'} ne '';
> >Can someone explain why this is necessary?
>
> Actually, I recommend C<delete $ENV{IFS}>. See the man page for
> the "sh" program for info.
> --
> Chip Salzenberg - a.k.a. - <chip@pobox.com>
> "I brought the atom bomb. I think it's a good time to use it." //MST3K
> -> Ask me about Perl training and consulting <-
> Like Perl? Want to help out? The Perl Institute: www.perl.org
>
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
------------------------------
Date: Sat, 14 Mar 1998 00:37:57 -0500
From: Ronald J Kimball <rjk@coos.dartmouth.edu>
To: Kenneth Vogt <kenvogt@sni.net>
Subject: Re: Can't find "from" and "subject"
Message-Id: <350A17B7.C28D53D2@coos.dartmouth.edu>
[posted and mailed]
Kenneth Vogt wrote:
>
> It dawned on me you might think that I am just failing to set $from and
> $subject correctly. What happens is the malfunctioning script produces a
> message BODY that looks like the following:
>
> To: kenvogt@sni.net
> From: test@modernshopping.com
>
> Subject: test subject
>
> test body
Seems obvious enough. You must have a blank line ("\n\n") before the To:
line, signifying the end of the message headers and the start of the message
body. Check your print statements and your values. Make sure you're
chomp()ing your variables.
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J. Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Fri, 13 Mar 1998 23:09:25 -0500
From: "Steve Pacenka" <sp17@cornell.edu>
Subject: Re: closing files (sometimes not & effiency)
Message-Id: <6ecvsn$m6n@newsstand.cit.cornell.edu>
dk smith wrote in message ...
>In the Blue Camel book on page 151, the text says that you do not have to
>explicitly close a FILEHANDLE if you are immediately going to do another
>open on it.
>
>What consititutes immediately?
>
>Does this also hold true for files that opened for writing/appending as
>well as for files that are opened for reading?
I agree 100% with your instincts.
Perl is a convenience language. Why not have the compiler or runtime
interpreter insert a close() that you forgot if that's the only reasonable
thing to do at that point? Better than giving an error message, when you're
only running the program once or twice.
There's no execution efficiency consideration involved in deferring closes
until the file handle is reused. Perl will close the file sooner or later.
-----------
The "Swiss Army Chainsaw" can cut your leg off. Perl has chainguards but
it lets you take risks.
If writing to a file or appending to it, and hardware or operating system
crashes, the last things a program wrote may not have actually reached the
physical disk because of buffering in memory within Perl and the operating
system. Everything is flushed out of Perl to the operating system when a
file is closed.
Suppose that a program is reading from a file that some other process needs
to write to. The longer it keeps that file open, the longer that other
process (and perhaps its interactive user) might have to wait. They might
even time-out.
>Seems like really bad form to me; to write a program that behaves this
>way. Is the imprvement in efficiency of not making an extra close() call
>worth the extra headache and maintenance required to mange code that is
>written this way? Whenever I see code like this it is usually not very
>strcutured and accompanied by sudden logic breaks and/or subroutines that
>have multiple return lines depending on various conditions, kinda
>goto-ish.
I wouldn't write code for others that way either.
Perl lets you write maintainable or unmaintainable code. I like having the
choice of
quick+dirty versus structured+designed both in the same package.
>Anybody else experience this? Or know waht would happen if this file open
>for appending is NOT closed many many times?
Again, there is some risk of losing data if there is a crash, or making the
file unavailable to someone else wanting to use it. If your hardware and
operating system are extremely reliable, and if your program is the only one
ever using the file, you can leave the file open for a long time.
In the most defensively written Perl or C code, there are calls to flush()
upon occasion. That's a subset of close() that pushes data out of Perl's
runtime memory buffers farther toward being written to a physical medium.
-- thanks for inspiring post, SP
------------------------------
Date: 13 Mar 98 21:53:08 GMT
From: devin@premier1.net (Devin L. Ganger)
Subject: Re: Does anybody know how to do ftp in perl?
Message-Id: <slrn6gjakb.3q2.devin@blacktower.premier1.net>
<flashy-thing!> Remember only that on Wed, 11 Mar 1998 21:31:34 -0700,
in comp.lang.perl.misc Steven L Reid wrote:
> Okay, Maybe I just like the hard road, but I just open a pipe to ftp and
> push it commands using print?! Too simple!
Aside from (possibly) not being portable (as you mentioned), there is at
least one other drawback to this method:
You don't have any control over any errors that may occur during the
process. For example, say your connection is broken in the middle of
the transfer -- using your method, you have no way of determining this.
Using the Net::FTP module will allow you to check for errors and correct
certain ones, as well as give you (should you desire to code it) some
capability of adjusting to changing file locations.
--
Devin L. Ganger <devin@premier1.net>
Chief Systems Administrator
Premier1 Internet Services
------------------------------
Date: Sat, 14 Mar 1998 04:20:32 GMT
From: Sneex <chasecreek.systemhouse@usa.net>
Subject: Re: In the news ....
Message-Id: <350A0448.442468EE@usa.net>
Didn't they miss that by a few years?
6 = 1 + 2 + 3;
6 = 1 + 2 + 3;
6 = 1 + 2 + 3;
Or - on 12/31/23 @ 1:23AM The Earth dies :)
My 2 Cents worth...
Sneex :)
PS - Just some humor, I am not serious (I hope...)
------------------------------
Date: Fri, 13 Mar 1998 22:37:48 -0600
From: rasta@spacestar.net
Subject: Re: Is there a "Newsgroup" for Newbies to Perl?
Message-Id: <6ed1ft$thk$1@nnrp1.dejanews.com>
> Nobody who reads and/or posts to this group (or any other
> newsgroup, for that matter) gets paid to do so -- to a woman
> [thanks, Abigail!], they do so because they want to, and for
> whatever reason, derive something out of helping others.
> Answering the same question over and over again is *really*
> wearying . Have you ever worked a helpdesk? The burnout level is
> as high as it is for good reason.
I have a great idea, if you see a question that tires you, why not ignore it
instead of flaming the questioner? Is that so hard? This is not a helpdesk....
it people discussing things...either contribute if you want or ignore the
question.
> A *lot* of work has gone into producing Perl's plethora of
> documentation. It may not be the most usable documentation set on
> the planet -- but you owe it both to yourself and to the USENET
> community to research your question before asking it of the world
> and expecting a stranger to interrupt his work to answer a
> qeustion, the answer to which is readily available in a number of
> different places. Remember, USENET only helps those who (A) help
> themselves and (B) help others.
Nope, USENET helps anybody who can glean some information from the discussion.
> From your paragraph above ("not very friendly", "answer...more
> confusing than the question", "all we get is syntax...very few
> examples"), it sounds as if you'd be happier with documentation
> presuming less pre-knowledge of the topic.
I would guess that anyone learning would say that's the case.
<snip>
> A newbie, having recently reached
> understanding, may well have a better grasp of *how* to explain a
> concept to another newbie than the originator of the topic,
> because the newbie has a better memory of groping blindly in the
> dark and what was mysterious and confusing.
Agreed...
> Join the Perl community and make the documentation better! When
> you've struggled through the documentation and reached [what you
> think is] understanding about a topic, take a moment.
>
> Try to figure out what made that concept hard to understand and
> how it could be better explained. Suggest any changes you think
> are useful to the author/maintainer for possible inclusion.
>
> > > ...and asking questions here isn't really going to help you
> > > to learn the language. You'll learn the answer to your
> > > question (maybe) but not how to think in Perl. You can only
> > > learn that through time-consuming study.
I study the answer the guy gave me, until I either understand what
it's doing, or do further research until I do understand. "Read the faq"
does nothing to help me...I've friggen done that before I posed my question.
If I don't understand the answer, another question is in order, and I would
expect not to get fricken snotty answer. If someone thinks the answer is
either covered somewhere or obvious, keep it to themselves....you are not
required to respond to every message.
> > Agreed... but when you're attempting something new, you want to
> > see results... I guess I'm a little impatient that way. After
> > all... isn't that why Perl was developed in the first place...
> > to get results quickly?
>
> Err...USENET would be a bad place to look for quick answers. I
> know I can find the answer to most of the things I want to know
> faster by looking in the online docs, the Llama or the Camel
> rather faster than I can expect an answer from the hive mind of
> USENET.
I disagree, when I'm stumped and have exhaused what I have in front of me
I do a search on Deja News.....if someone else had the same question and some
kind soul...( non rude person) has answered, I'm good to go and I learned
something too!
> > > >We need a good list of tutorials, our own Newsgroup, some
> > > >good books, and a few mentors who don't mind answering (and
> > > >explaining) our "Newbie" questions. Then we get out of your
> > > >bandwidth.
> > >
> > > A newbie newsgroup would indeed be a nightmare; a zillion
> > > questions (not unlike this group's current state of affairs)
> > > and a half zillion wrong answers. Go to the books; that's
> > > where you'll find the truth.
>
> Exercise: Why does USENET have [at best] few-to-no
> *.(newbie|beginner) newsgroups? Summarize in 25 word or less.
>
> Fundamentally, it's the same problem you'd face if *.guru
> newsgroups were created: they act as a magnet for J. Clueless.
> Newbie. The Signal/Noise ratio would rapidly approach zero.
> End result: the clueless leading the ignorant -- nobody with a
> clue would read the group. Too much dross, not enough gold.
People with some compassion would monitor a newbie group to help
out people who are having a hard time understanding...
Look, I don't support people who do NO research and fire off stupid
questions...but who the hell are you to say that this individual has not
searched through everything he can find and just doesen't get it.
>
> In summary, the FAQs and the documentation are the newbie's
> helpdesk. Instead posting the usual newbie-style FAQ:
>
> TO: comp.lang.perl.misc
> SUBJECT: !!!EMERGENCY!!! Newbie In trouble!
>
> how do I round a number to 3 decimal places in Perl?
Ignore his message or tell him the resources and answer tha god damn question.
> Take a look at the documentation: the Llama, the Camel, the
> [assorted] FAQs, the online documentation, www.perl.com. Struggle
> through it. Try something. Look at what happened and how that
> differs from the expected.
Unless of course I have a deadline and I just can't get the answer....I figure
the experts will help me and they turn out to be a bunch of pompus jerks...
(sorry, but that's the way some people come off on this NG)
> Back to the docs. Try to find an explanation for the discrepancy
> in behaviour. Make the changes suggested by the new reading of
> the docs. Repeat as necessary.
I've done it many times.......I could not get a file to print and I was going
nuts.....until I realized I had not closed the file I added the close and
BANG, it worked!
> When you've exhausted all the apparent explanations, *then* (and
> only then) pose a reasoned, specific question with a reasoned,
> appropriate SUBJECT: line to the group (eg, "I'm trying to
> accomplish X. I've tried Y: it doesn't do what I expected. I
> expected M and got N. I've studied the FAQs and the documentation
> and still don't understand what I'm doing wrong. Can somebody
> explain this to me?"
Why does one need the disclaimer...I read the faq blah blah blah....
to prove to you they read it? Give me a break....
>
> You're virtually guaranteed better results from this approach.
> And you'll have learned two things: (1) what you wanted to know
> in the first place, and (2) greater insight into the
> documentation. It's always been my experience that knowledge of
> how to find the information you need is worth at least as much as
> knowing it in the first place.
The docs are great but they don't always yield the answers I'm trying to get
>
> Cheers!
>
> N.
> --
>
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
------------------------------
Date: 14 Mar 98 01:32:48 GMT
From: devin@premier1.net (Devin L. Ganger)
Subject: Re: Is there a "Newsgroup" for Newbies to Perl?
Message-Id: <slrn6gjng8.4g5.devin@blacktower.premier1.net>
<flashy-thing!> Remember only that on 13 Mar 1998 12:12:34 -0500,
in comp.lang.perl.misc Myles Barrett Williams wrote:
> Jonathan Feinberg <jdf@pobox.com> writes:
> > Now, nobody here minds answering questions.
>
> I'd have to differ with you, Jonathan. There are *some* people
> subscribing to this newsgroup (no names) who hate answering questions.
> Yet for some strange reason they do it anyway, until it burns them
> out.
Disagree.
They mind answering the *same* questions over and over again.
They mind answering questions that, in many cases, have been answered
in several different places, all available with the standard Perl
distribution.
They mind answering questions that amount to, "I don't want to think
or learn. I just really want someone to do this *for* me."
I've found that the simple expedient of spending a few minutes looking
for my own answers, and *only* after not finding any, posting a
clearly-defined question that explains my lack of comprehension *and*
the steps I've already taken to fix it, will make even the grumpiest
of regulars on this group happy to answer my question and help me
learn whichever particular bit of perldom has me stumped this time.
But then again, I don't demand answers, and I'm perhaps a bit over-
eager when it comes to documenting my question.
YMMV.
--
Devin L. Ganger <devin@premier1.net>
Chief Systems Administrator
Premier1 Internet Services
------------------------------
Date: Fri, 13 Mar 1998 23:08:59 -0500
From: ROBERT DOOKS <DOOKS@netcom.ca>
Subject: learn
Message-Id: <350A02DB.35A5@netcom.ca>
Where can I go to learn Perl free on-line? Any websites that have free
tutorials etc?
Thanks
------------------------------
Date: 14 Mar 1998 04:31:25 GMT
From: Anirvan Chatterjee <c..bojswbo@62.usenet.us.com>
Subject: Re: newbie's 1st question
Message-Id: <6ed16t$t1h$1@samba.rahul.net>
John Hibscher <john@apte.com> wrote:
> Is there any recommended code to simulate a web page counter out there?
> I'm trying to use the counter to generate unique file names. I've been
> looking at the man pages for perl and it seems I may need to go buy a book
> to understand perl functions.
The FAQ is our friend; read it, live it, love it. Scan the following URL:
http://www.perl.com/CPAN-local/doc/FAQs/FAQ/PerlFAQ.html#I_stil_don_t_get_locking_I_jus
_____________________________________________________________________
Anirvan Chatterjee . anirvan @ chatterjee.net . PGP 2048/0xE2D13BA9
Fast & free new/used multi-bookstore searching @ http://www.mxbf.com/
------------------------------
Date: 14 Mar 1998 04:20:08 GMT
From: huaiyu@santafe.edu (Huaiyu Zhu)
Subject: Open format configuration (Was: Yet another packaging system?)
Message-Id: <6ed0ho$bdg$1@santaclara.santafe.edu>
[ Long post. Please be patient. Perl gurus, your help are also needed.]
In article <6dfteg$3o0$16@quasar.dimensional.com>,
Kenneth R. Kinder <Ken@_$spamless$_KenAndTed.com> writes:
> For those of you who don't know, there seems to be yet another packaging
> system: Stampede's (http://www.stampede.org/) - a new Linux distribution.
>
> This distrubs me. Why can't everyone just use RPM? It's got it all, but
> more importantly, WE COULD HAVE A STANDARD PACKAGING SYSTEM.
>
> Anyone have some thoughts on this?
>
Multiple packaging systems are not bad in themselves, but incompatible
formats to specify configuration is bad. An ideal world would have
many packaging systems with different look and feel but all compatible
to each other.
Proposal: Open Format Configuration System
--------------------------------
WHAT IT SHOULD BE
-----------------
* It does not need to tell how to package/compile/install. It only
need to tell what the end result should be like.
* It should be such that informations can be used by ALL the tools,
including make, imake, rpm, tar, shar, and many others. It should be
able to let various configuration techniques work together, .files,
aliase, PATH, command options, symbolic links, etc. Kernel and
devices configurations should be put in the same format.
* It should include the ability to check dependencies and
alternatives, as a good sysadmin would do. This can include
availability over Internet.
* It should make all the info, man, help, howto, faq work together.
It should have information about when and who installed a package,
with which source and which options. It should also list additional
packages not installed which might be of interest.
* It should definitely be in text files, and easily accessable to
various tools, perl in particular.
* A developer of a new package only need to add one entry (perhaps
automatically) about its purpose, function, dependencies, and some
comparison with alternatives (with specific versions), all the
information that is currently put in README, INSTALL, FAQ, HOWTO, man,
info, config, rpm, etc, but all a in machine-usable format.
* There should be a bunch of user configuration files for the whole
user environment that can be carried in one floppy to any unix system,
and if the user says "config", Hey presto, everything has exactly the
same look and feel, from window managers to how the mails are sorted.
THE FEASIBILITY
---------------
Is this desirable? It certainly is, because it takes nothing away
from manual configuration. It helps maintain consistency. It helps
maintain a compact and modular system. It helps newcomers to get
things right the first time. It helps applications work together,
accross unix platforms. It even helps to break the myth that "You
have to bundle the brower with the OS". :-)
Is this possible? Of course. None of these uses intuition that
cannot be written down. Many of these should be easily manageable by
machines. The kernel and XF86 configurators and rpm already do many
of these things, although each in their own format. There are
translators between man, info, html, tex, text, ... If you really
think about it, all the investment we put in configuring the system,
baring actual programing, can really go into a single floppy in text
format. We only need to design that magic format ...
But that's no problem either. If things are put in one machine-usable
format, they can also be easily translated to new formats. For a
starter, we only need to make XF86 and kernel configuration use the
same format, which already includes help texts. Then someone might
consder how the imake work. Then someone might consder combining dot
files, alias and PATH. ... If these formats can be combined together,
it is quite likely to be able to include any future configeration
information.
THE MOTIVATION
--------------
The problem with the current situation is that developer do either two
things: (1) They tell machine what to do, but users are not supposed
to change much of the makefiles, or (2) They write documentations for
the user, which is useless for the machine.
A user who wants to use something new is often left with only three
alternatives: (1) Take whatever default automatic behavior, (2) Read
the fine manuals and do programing himself, (3) Don't bother to use it.
The main idea of the Open Format Configuration proposal is:
Separate the effect of configuration from it implemetation.
In other words, write documentation for machines, instead of writing
instructions for machines and documentations for humans. Then there
can be various tools to change configurations in different ways, all
achieving the same effects. Many different tools to carry out the
configuration. Many tools to display help and documentation in
different ways.
Well, if you have read this far, here are some more possibilities: It
is possible for vendors to sell configurations. With all the power of
Linux, it's not hard to make it look and feel like any other OS, just
to show those people who say unix systems don't behave as *they*
expected. One can even make configurations that change with time to
help those brave new souls who crossed the species barriar to remember
"rm -i" instead of "del"... The possibility is countless.
What I cansider to be the most important unix philosophy is: use
common/convertible formats so that every program, alarge or small, can
work together. I hope it will work out here as well.
Any comments?
Huaiyu
--
Huaiyu Zhu Tel: 1 505 984 8800 ext 305
Santa Fe Institute Fax: 1 505 983 0751
1399 Hyde Park Road mailto:zhuh@santafe.edu
Santa Fe, NM 87501 http://www.santafe.edu/~zhuh/
USA ftp://ftp.santafe.edu/pub/zhuh/
------------------------------
Date: Sat, 14 Mar 1998 13:33:50 +0800
From: zero <zero@sg-online.com>
Subject: Re: Password protected
Message-Id: <350A16BE.E1471D7C@sg-online.com>
How can I create a password protected directory, Where different userID
(and password) will get them to view, upload, download files from
"their" own directory only?
------------------------------
Date: Fri, 13 Mar 1998 15:36:35 +0100
From: Lutz Albers <lutz@muc.de>
Subject: Re: PGP / $PGPPASS
Message-Id: <35094472.7708284F@muc.de>
kozo wrote:
> :> I am trying to execute pgp using 'system("pgp bla-bla-bla") '. Well, the
> :> problem is that I don't know how to setup $PGPPASS variable (within perl
> :> script), so pgp can use it!? If i use system("setenv...") it doesn't work.
> :> $ENV{'PGPPASS'} doesn't work either. Could someone help me, or "forward" to
> :> some doc which contains explanation about this?
>
> try use -z _PASSWORD_ options .. really ..
>
> pgp -z pass_phrase +batchmode +force blabla
... which is an EXTREMLY dangerous advice. Your passphrase will be part of your
command line and can therefore be sniffed. It's better to use PGPPASS ...
ciao
lutz
--
Lutz Albers, lutz@muc.de, pgp key available from <http://www.pgp.net>
Do not take life too seriously, you will never get out of it alive.
------------------------------
Date: 13 Mar 98 18:52:51 GMT
From: harrison@pixi.com (Robert F. Harrison)
Subject: Re: Read one line of a file
Message-Id: <slrn6gj02p.kdh.harrison@localhost.localdomain>
On Fri, 13 Mar 1998 11:24:01 -0600, Sadi Kose <kose@cae.wisc.edu> wrote:
> Jeffrey M. Cook wrote:
>
> > How do I read one line of a text file do something then the same to the
> > next line in the text file?
ARGH!!!! This simply can't go on much longer.
[NOTE: How I would read a line of a text file and do something to each
line in turn would be by reading the documentation that came with
whatever language I was trying to do it in first. Then I might not
need to ask questions like this.]
Sadi's solution:
> open(FIN,"somefile");
> while($line = <FIN>){
> #do something;
> }
> close(FIN);
Ah but he asked about text files. Your solution doesn't make sure
it's a text file and not a binary file. Also it might be good to
make sure it exists first. ;-)
And to make it complete I'd make sure to use the -w argument!
Perl Program: Overkill :-)
#!/path/to/perl -w
$somefile = "somefile";
-f $somefile or die "check $somefile: $!\n";
-T $somefile or die "$somefile isn't a text file\n";
open(FIN,$somefile) or die "Can't open $somefile: $!\n";
while (defined($line=<FIN>)) {
chomp $line;
# do something
}
close(FIN);
# Notes: File tests (-f -T) could be combined.
# Added 'die' statements for feedback on failure
# Added 'defined' to be proper and satisify -w
# Added chomp to remove newline - just in case :-)
Anything I missed? {Seriously}
--
rfh harrison@pixi.com
------------------------------
Date: 13 Mar 98 20:13:02 GMT
From: harrison@pixi.com (Robert F. Harrison)
Subject: Re: User-interface Quandary
Message-Id: <slrn6gj4p6.kdh.harrison@localhost.localdomain>
On 13 Mar 1998 18:01:58 GMT, Tom Christiansen <tchrist@mox.perl.com> wrote:
>
> Anywhere
> Whole Words Only
> Entire Field
Anywhere
Whole Words Only
Exclusively
My name is Fred
My name is Fred and this is Barney
Contains _My name is Fred_ Exclusively
That would be my best shot at it.
--
rfh harrison@pixi.com
------------------------------
Date: Sat, 14 Mar 1998 04:27:24 GMT
From: doswald@xmission.com (David Oswald)
Subject: Re: Using regex to initial cap a name
Message-Id: <350a0602.66620214@news.xmission.com>
On Sat, 14 Mar 1998 03:29:42 GMT, doswald@xmission.com (David Oswald)
wrote:
>On Mon, 09 Mar 1998 19:48:37 -0800, Franco Finstad <ffinstad@best.com>
>wrote:
>
>>I need to translate the string:
>>
>> lastname, firstname
>>
>>into:
>>
>> Lastname, Firstname
>>
>
>$string =~ s/(\b)(\w+)/$1\u\L$2/g;
>
>Here is my logic. I hope it's not flawed......
>
>Use the substitution operator, s///
>
>Match a word. Be sure that the word begins with a word boundry,
>capture the boundry, then capture the word.
I wanted to followup to my own post because I realize that I made a
mistake. According to MRE (The owls book) \b doesn't match a boundry
character, it matches a boundry position. That means that there is no
need to replace the matched boundry. The substitution operator should
look like this:
$string =~ s/\b(\w+)/\u\L$1/g;
and would probably even work like this:
$string =~s/\b\w+/\u\L$&/g;
Remember that $& contains the match. Since \b doesn't evaluate to a
character the string contained in $& will be only the word (the part
matching w+). Thus there is no need to capture the word with
parenthesis.
Dave
------------------------------
Date: Sat, 14 Mar 1998 00:44:40 -0500
From: Ronald J Kimball <rjk@coos.dartmouth.edu>
Subject: Re: Way of testing whether a variable is blessed
Message-Id: <350A194B.64294397@coos.dartmouth.edu>
Martin Vorlaender wrote:
>
> Allen Choy (achoy@us.oracle.com) wrote:
> : Is there a standard way of testing whether a variable is blessed or not?
>
> ref($var) !~ /^(?:REF|SCALAR|ARRAY|HASH|CODE|GLOB)$/;
>
> Or is there anything else ref() could return if $var isn't blessed
> into a package?
Whether or not there is now, there could conceivably be new built-in types
added in the future, in which case that code would no longer work.
> : The only way I can think of is testing whether a reference has an '='
> : sign.
>
> Where would that come from?!
DB<1> $var = {}
DB<2> bless $var, foo
DB<3> p $var
foo=HASH(0x100378a4)
^
Looks like it comes from right there. ;-)
print "Blessed.\n" if $var =~ /=/;
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J. Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Sat, 14 Mar 1998 00:47:48 -0500
From: Ronald J Kimball <rjk@coos.dartmouth.edu>
To: Allen Choy <achoy@us.oracle.com>
Subject: Re: Way of testing whether a variable is blessed
Message-Id: <350A1A06.F3DF9D61@coos.dartmouth.edu>
[posted and mailed]
Allen Choy wrote:
>
> Is there a standard way of testing whether a variable is blessed or not?
Don't know, but...
> The only way I can think of is testing whether a reference has an '='
> sign.
That sounds good to me.
print "Blessed.\n" if (ref $var and $var =~ /=/);
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J. Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Fri, 13 Mar 1998 22:57:55 -0500
From: Luis Espinal <lespin03@fiu.edu>
Subject: Re: What is PERL? Learn JAVA instead?
Message-Id: <350A0043.C8549908@fiu.edu>
Rahul Dhesi wrote:
>
> In <6dhrod$t0s$2@info.uah.edu> gbacon@cs.uah.edu (Greg Bacon) writes:
>
> >Using the sizes of Perl's and Java's respective user bases as a basis
> >for comparison, Perl seems to be much more useful for everything, not
> >just the simple task of crippling someone's machine with rogue code.
Uh? What? Como? Abort, retry, ignore...?
> And Perl is far more portable. Java's machine independence is a myth.
> Sun's Java development kit will only run on two software platforms
> (Solaris and Microsoft's windowing systems) on two hardware platforms
> (SPARC and Intel x86).
What about Linux?
> Rahul Dhesi <dhesi@spams.r.us.com>
Were the first implementations of Perl available in all
platforms available to it now? Don't think so. Unless
I'm wrong, Java runs not only on SPARC and Intel x86 but
also in the Mac, VMS and AS/400, and of course, Linux.
Portability is not much of a good ground for comparing
two languages unless portability is the main characteristic
being sought. In the same way Perl was ported to several
platforms, so does Java. The concept works; it just needs
to be implemented, and it is. And there is no tangible
proof that Java "Write once, run anywhere" paradigm cannot
be achieved. Perl also shares that paradigm. It was conceived,
and if it was conceived within reasonable ground, it can be
achieved.
These kind of comparisons, not only on Perl or Java, but
on all other languages, are useless. All they do is to
spread confusion and to spread "computer illiteracy" across
the realms of cyberspace:) It's like saying "this program
written in X language runs faster that an equivalent program
written in Y language." The burden in the compiler, damn it!
not in the language. The same applies for Perl and Java, just
that instead of the compiler, we talk about the interpreter
or VM or whathever we want to call it.
If you want to compare Java and Perl ( not Java against Perl, )
you need to define what tasks you want to compare. Is it
string handling, file handling, GUI, easier to write,
easier to read, easier to debug? I'm sure that there are
things which Perl do better than Java AND viceversa.
---------------------------------
What does not kill you
makes you stronger.
Nietzche.
L^3=Long Live Linux
---------------------------------
------------------------------
Date: Fri, 13 Mar 1998 23:16:54 -0500
From: "Steve Pacenka" <sp17@cornell.edu>
Subject: Re: Win32 Perl question
Message-Id: <6ed0bb$mbd@newsstand.cit.cornell.edu>
keydet89@yahoo.com wrote in message <6ebfr6$db4$1@nnrp1.dejanews.com>...
>I have written a couple of small scripts for accessing shares on remote
>computers using "net use". In some cases, I need to supply a username
>and password.
>
>Is there a way in Perl to set up a connection using a different username
>and password, without using something like "open(NET,"net use.....")"?
Looks like a NT or 95 user ...
Win32::NetResource looks promising. (Docs say nothing about Netware.)
Within:
AddConnection(\%NETRESOURCE,$Password,$UserName,$Connection)
Makes a connection to a network resource specified by %NETRESOURCE
-- SP
------------------------------
Date: Sat, 14 Mar 1998 04:15:20 GMT
From: Sneex <chasecreek.systemhouse@usa.net>
To: mmcm@swbell.net
Subject: Re: Writing to a socket
Message-Id: <350A0310.13598E7@usa.net>
Posted & Mailed:
Down and dirty -
socket(SOCKET, PF_INET, SOCK_STREAM, $proto) or die("Can't\n");
my($packFormat) = 'S n a4 x8'; # Win95?, (a or c) per SunOS 5.4+
(Solaris)
connect(SOCKET, pack($packFormat, AF_INET(), $port, $serverAddr)) or
die("Still can't\n");
send(SOCKET, $xPair, 0); # Send the data, and
recv(SOCKET, $buffer, 9, 0); # Get a response!?!
close(SOCKET);
Something to get your research started...
HTH,
Sneex :)
Mike McMillan wrote:
> Hi.
>
> I have inherited a socket app (written in C) where the client sends
> requests as byte streams. Some Java code that sends requests uses the
> writeBytes methods, as in:
>
> out.writeBytes("somestring");
>
> How can I implement something like the writeBytes method in Perl? I've
> tried syswrite, write, print and none of them work.
>
> Thanks.
>
> Mike McMillan
> T4 Systems, Inc.
> mmcm@swbell.net
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
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.
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 2096
**************************************
