[21720] in Perl-Users-Digest
Perl-Users Digest, Issue: 3924 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Oct 6 06:06:24 2002
Date: Sun, 6 Oct 2002 03:05:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 6 Oct 2002 Volume: 10 Number: 3924
Today's topics:
Re: date regex problem <dgardiner@houston.rr.com>
Re: Eliminating right-end whitespace (Malcolm Dew-Jones)
File upload form question. (mike)
Re: Installing Perl Modules: What actually happens? (david rayner)
Re: ithreads, perl 5.8 and shared objects <troc@netrus.net>
Re: ithreads, perl 5.8 and shared objects <uri@stemsystems.com>
Re: ithreads, perl 5.8 and shared objects <derek@wedgetail.com>
Re: ithreads, perl 5.8 and shared objects <derek@wedgetail.com>
Re: newbie question - perl vs ? <dave@dave.org.uk>
Re: newbie question - perl vs ? (Qiang)
Re: Reproduce Datafile <goldbb2@earthlink.net>
Re: Script to Change Filename <bart.lateur@pandora.be>
Re: What does [^\n] mean <No_Mail_Address@cox.net>
Re: What does [^\n] mean <No_Mail_Address@cox.net>
Re: What does [^\n] mean <Tassilo.Parseval@post.rwth-aachen.de>
Re: What does [^\n] mean <krahnj@acm.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 06 Oct 2002 06:28:52 GMT
From: "Doug" <dgardiner@houston.rr.com>
Subject: Re: date regex problem
Message-Id: <EKQn9.74234$Fw2.2287779@twister.austin.rr.com>
"Eric J. Roode" <REMOVEsdnCAPS@comcast.net> wrote in message
news:Xns929E70FE739CDsdn.comcast@216.166.71.239...
> -----BEGIN xxx SIGNED MESSAGE-----
> Hash: SHA1
>
> "Doug" <dgardiner@houston.rr.com> wrote in
> news:zEBn9.72022$Fw2.2109300@twister.austin.rr.com:
>
> > I have a field of text that displays a line starting with a date and a
> ^^^^^^^^^^^^^
> > time stamp, but cannot successful strip the timestamp out of it.
> ...
> > Here are some of the ways I've tried unsucessfully.
> >
> > $foo=~s/^\d+-\d+-\d /$1/;
>
> No colons in your pattern here.
>
> > $foo=~s/^\w+ /$1/;
>
> \w does not include colons.
>
> > $foo=~s/\d+:\d+:\d+$//;
>
> Why the $ there? That matches only at the end of a string.
>
> > $foo=~s/(\d+):(\d+):(\d+)$//;
>
> Ditto -- you said that the date and time was at the *start* of your
string.
>
The first reply from Tad solved the problem and thanks.
The reason for the anchors is because this line of code is checking all of
the fields, and the few that match have the date at the start with a space
btween the date and the time and then that is the end of the line. I had
tried(after the fallacy of the earlier attempts) to look for the whol
pattern and then parentheses around the 1st and 2nd patterns, then
substitute them for only the 1st portion of the match.
The first section had no colons, the time stamp did. I had tried various
things because and when I did get something other than just 1 digit as a
replacement string, it was empty.
This line of code is used through several lines of text, and I don't want an
unforseen side effect to crop up and figured being exact with the kinds of
characters I was dealing with would be the best course of action. I also
thought that maybe - would at various points be a meta character as in [a-f]
As someone who is new to programming and perl in general, I've found the
meta characters and their description in some of the documentation I found,
more confusing(far more) than their actual values.
------------------------------
Date: 5 Oct 2002 23:20:48 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: Eliminating right-end whitespace
Message-Id: <3d9fd640@news.victoria.tc.ca>
Warren Block (wblock@wonkity.com) wrote:
: Tassilo v. Parseval <Tassilo.Parseval@post.rwth-aachen.de> wrote:
: > It's not a Perl-builtin, but it's trivial with a regex and substitution:
: >
: > $string =~ s/ +$//;
: That just gets rid of spaces, though, not all whitespace characters,
: which would be
: $string =~ s/\s+$//;
be careful, cause \s matches a \n, so it removes the new line at the end
of a line.
You might want to use
s/\s+?$//;
------------------------------
Date: 6 Oct 2002 01:19:44 -0700
From: mike@swaylocks.com (mike)
Subject: File upload form question.
Message-Id: <5e1e1a55.0210060019.21cefd6f@posting.google.com>
Hi,
Working in Perl I have a form that allows people to modify their
database records if they choose. I'm having the file upload form field
prepopulated from a database as follows:
<input name="File1" type="FILE" value="<%File1%>"
Unfortunately when the form is submitted the value gets lost. The same
form, if populated with a new file using the browse feature, the value
gets passed just fine.
Anybody know why this is happening and if there is any way around it?
Many thanks.
------------------------------
Date: 6 Oct 2002 02:45:38 -0700
From: david@tvis.co.uk (david rayner)
Subject: Re: Installing Perl Modules: What actually happens?
Message-Id: <f677762.0210060145.2db09334@posting.google.com>
Bernard El-Hagin <bernard.el-hagin@DODGE_THISlido-tech.net> wrote in message news:<slrnapqq38.142.bernard.el-hagin@gdndev25.lido-tech>...
> In article <f677762.0210040205.7ccec0e6@posting.google.com>, david rayner wrote:
> > Obviously it's easiest when PPM does a install for you.
> > Occasionally however you are asked to do the following
> >
> >>perl makefile.pl
> >>make
> >>make test
> >>make install
> >
> > But my real question is what is actually happenning, what is being
> > compiled/installed etc?
>
>
> Look in the makefile. It's all in there.
Just did, sorry it's double dutch. What I'd like to is the principles
------------------------------
Date: Sun, 06 Oct 2002 07:08:18 -0000
From: Rocco Caputo <troc@netrus.net>
Subject: Re: ithreads, perl 5.8 and shared objects
Message-Id: <slrnapvo65.8ma.troc@eyrie.homenet>
On Sun, 06 Oct 2002 00:19:58 +1000, Derek Thomson wrote:
>
> Uri Guttman wrote:
>> nope. you can use proxy processes to handle blocking events. gui events
>> are not blocking and already have event loops. POE has the ability to
>> use any of them and stem will too (when i steal the poe code :).
[...]
Derek Thomson again:
> (BTW it doesn't matter if GUI events are blocking or not, you need a
> hook in your event loop so that "select" returns when a GUI event
> *happens*!)
I must disagree with you here. A properly designed events library
will integrate itself with other event loops without the need for
strange select() hacks. As Uri mentioned, POE includes such a
library.
POE's library presents an abstract interface to events. It supports a
number of concrete event loops through the use of bridge classes [1].
These bridges replace POE's default select() code entirely with other
event loops, making select() hacks moot.
Modules that use POE are therefore portable across every GUI and event
loop it supports [2]. They are also forward compatible to new event
loops as bridges for them are implemented [3].
This extreme level of portability has helped earn POE the respect and
support of many people and companies. Even Uri covets it, and he
knows a good thing when he steals it. :)
Good luck with your project.
-- Rocco Caputo / troc@pobox.com / poe.perl.org / poe.sf.net
[1] Currently Event.pm, Gtk, IO::Poll, select(), and Tk.
[2] http://search.cpan.org/search?mode=module&query=poe::component
[3] People needing new bridges should contact me.
------------------------------
Date: Sun, 06 Oct 2002 07:20:39 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: ithreads, perl 5.8 and shared objects
Message-Id: <x7vg4g3uex.fsf@mail.sysarch.com>
>>>>> "RC" == Rocco Caputo <troc@netrus.net> writes:
RC> This extreme level of portability has helped earn POE the respect
RC> and support of many people and companies. Even Uri covets it, and
RC> he knows a good thing when he steals it. :)
even when/if i steal that code i will have to rewrite it to stem's event
api. but that should be fairly easy. and my coveting is out of the
laziness attribute of perl. :) and also demand for stem on winblows.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Sun, 06 Oct 2002 18:33:29 +1000
From: Derek Thomson <derek@wedgetail.com>
Subject: Re: ithreads, perl 5.8 and shared objects
Message-Id: <3d9ff578$0$23171$afc38c87@news.optusnet.com.au>
Rocco Caputo wrote:
> On Sun, 06 Oct 2002 00:19:58 +1000, Derek Thomson wrote:
>
>>Uri Guttman wrote:
>>
>>>nope. you can use proxy processes to handle blocking events. gui events
>>>are not blocking and already have event loops. POE has the ability to
>>>use any of them and stem will too (when i steal the poe code :).
>>
>
> [...]
>
> Derek Thomson again:
>
>>(BTW it doesn't matter if GUI events are blocking or not, you need a
>>hook in your event loop so that "select" returns when a GUI event
>>*happens*!)
>
>
> I must disagree with you here. A properly designed events library
> will integrate itself with other event loops without the need for
> strange select() hacks. As Uri mentioned, POE includes such a
> library.
But with a well-constructed infrastructure, the long-suffering user
doesn't have to concern herself with all this "event loop" stuff in
order to achieve basic scalability. And then there's reliability ...
>
> POE's library presents an abstract interface to events. It supports a
> number of concrete event loops through the use of bridge classes [1].
> These bridges replace POE's default select() code entirely with other
> event loops, making select() hacks moot.
If you don't have threads, you *have* to use select if you don't want to
block, unless you shove stuff into yet another heavyweight process, and
that's not really very scalable or efficient, is it?
>
> Modules that use POE are therefore portable across every GUI and event
> loop it supports [2]. They are also forward compatible to new event
> loops as bridges for them are implemented [3].
It's portable across everything is supports? This statement contains no
information :(
I'm also interested in interoperability - if it can't talk to CORBA/J2EE
object, I'm unlikely to be interested. I also need reliability, and
"messaging" ie throwing your requests into a black hole, can't provide
that by definition, unless you "hack" something equivalent to a response
on top of that, in which case you're better off admitting you need
responses up front.
> Good luck with your project.
Thanks!
--
Derek Thomson.
------------------------------
Date: Sun, 06 Oct 2002 19:20:48 +1000
From: Derek Thomson <derek@wedgetail.com>
Subject: Re: ithreads, perl 5.8 and shared objects
Message-Id: <3da0008f$0$23171$afc38c87@news.optusnet.com.au>
Uri Guttman wrote:
>>>>>>"DT" == Derek Thomson <derek@wedgetail.com> writes:
>>>>>
>
> >> nope. you can use proxy processes to handle blocking events. gui
> >> events are not blocking and already have event loops. POE has the
> >> ability to use any of them and stem will too (when i steal the poe
> >> code :).
>
> DT> I can use proxy processes to handle blocking events? The problem
> DT> here is that now I'm corrupting the user's design with
> DT> infrastructure details. What if they don't *want* yet another
> DT> object in yet another process with methods that deal with this? I
> DT> think this can and should be handled cleanly and invisibly.
>
> but the coder never sees the difference. and he has to write NO new code
> to support this. in stem it is purely done via configuration files which
> are not coding. you really should play with stem's demos to see how
> simple this is. splitting an application from 1 into 2 processes
> requires ZERO new code, and only minor changes to the config files.
This is not really a big deal. I can migrate CORBA objects anywhere I
like with zero effort as well. And they don't have to be Perl ...
>
> DT> (BTW it doesn't matter if GUI events are blocking or not, you need
> DT> a hook in your event loop so that "select" returns when a GUI
> DT> event *happens*!)
>
> nope. you USE the event loop of the gui itself. this is simple to
> do. then it handles all of the GUI events as well as your own.
But you need to integrate your infrastructure's select loop with the GUI
event loop. Otherwise select won't return when a GUI event occurs!
Unless of course, you put the GUI in another process.
>
> DT> I'm not really interested in asynchronous message passing, for
> DT> various reasons. Most systems I've designed need RPC of some kind,
> DT> which you *can* build on top of your system by returning a
> DT> "completed" message which contains any results, or errors. Even if
> DT> you don't have any results to return, you need to at least know
> DT> that the operation completed, otherwise your system is unreliable
> DT> ie you can never really know if anything is actually happening, or
> DT> not.
>
> you can trivially emulate RPC with message passing. the opposite is not
> true. any object that sends a message can easily timeout while waiting
> for a response message. no issues with remote 'completion'.
Really? I've got any number of powerful message passing services
available for CORBA/J2EE.
>
> DT> Once you add that "completed" message, you have the deadlock
> DT> situation I described, and there's no way to avoid it, without
> DT> threads or a "reactive" event handler that allows other events to
> DT> be processed while waiting for others (I assume stem does this?)
>
> nope. because the objects are not blocked, they can handle a local
> timeout or any incoming message. you can't have the classic deadlock
> without all sides being blocked.
Sigh. Read what I said again. You can deadlock, if you are waiting for a
response, unless you allow other messages to be received and handled in
the meantime. The traditional way to do this without threads is with select.
>
> DT> The trivial (direct) case is when A.foo calls A.fubar
> >> directly, but
> DT> that can be avoided by having the ORB (or whatever infrastructure)
> DT> skip the message dispatch by detecting that it's a local
> DT> call. That's impossible, however, in the indirect case described
> DT> above.
> >> again with good message passing that is trivial.
>
> DT> Unless you're waiting for the response message, and then it isn't.
>
> timeouts again to the rescue. it is trivial.
Timeouts are not really good enough - and what exactly happens when a
timeout occurs? Is a message sent back to the originator? What if it
*doesn't" occur. Does the originator wait forever, or what?
> you just don't fully grok message
> passing, events and async behavior. you are bringing up all the issues
> that you think are real but they are not.
Yes, I do, and yes, they're real, basic computer science issues. Threads
of control (be they processes or "threads"). Shared resources. Race
conditions. They won't go away by magic.
>
> DT> I'll take a look, but I think this is a bit further up the
> DT> protocol stack than an ORB ie. you could implement something like
> DT> this to work around the lack of threads in Perl on top of the Perl
> DT> ORB, but once again, that's not within the scope of my project. I
> DT> can't ask people to add lots of methods to their objects to give
> DT> them what they get in Java for free!
>
> nope. this is so simple that you can't see it. take a look at some of
> the demos. remote objects interact in the exact same way as do local
> ones. the message passing paradigm is the key to it. no need to
> predeclare RPC params and methods, no need to know if some object is
> local or remote. you just use it the same way and send the exact same
> message.
I'll look, but this doesn't really address the issue. I could build all
this into the Perl ORB if I had a mind to, but I don't. If Perl doesn't
have threads, I *can't* ask them to use some ad-hoc model to make up for
that lack. They'll just use Java. See?
>
> >> if you need blocking either use threads (events and threads can
> >> coexist and i have done that), or multiple processes. the key is a
> >> good IPC that makes life easy.
>
> DT> A good IPC mechanism? I already have that, don't need another one
> DT> ;)
>
> rpc is not as powerful as message passing. as i said before, you can
> easily emulate rpc with message passing. not the other way around.
Not true.
>
> DT> Yes, but in CORBA, every RPC call looks like a "normal" method
> DT> call, so I don't even have to worry about "messaging". This may or
> DT> may not be a feature, but it seems to work with OO practices
> DT> pretty well. Messaging will always have the "result" message
> DT> problem that is encapsulated by RPC, unless you don't care if
> DT> no-one actually receives these messages, but I can't imagine a
> DT> robust design that wouldn't want an acknowledgement.
>
> oh, plenty of robust designs don't need ack on every message.
Like what? How do you know if anything happened at all? Do I just *hope*
that all my database updates went through with no errors? Or does
someone look at a log at the end of the day, and go, "Jesus H. Christ,
nothing actually went through!"
> you can
> always deal with that using stem's gather module which is used to track
> async responses and effectively synchronize them for you.
So, you've effectively added the response back in?
>
> DT> No, that's not true. If two *processes*, or threads, are writing
> DT> to a file (for example), there must be some form of locking to
> DT> avoid race conditions. You can't avoid it.
>
> nope. if they share a file object (in a remote proxy process) then file
> access could be single threaded.
So, you've serialized it! What do you think locking is? Having a single
threaded process that serializes access is a lock by another name.
>
> DT> Imagine one process is adding a record to a file. Halfway through,
> DT> another process is scheduled, which starts writing to that same
> DT> file. That process completes writing its record, then the first
> DT> process gets to complete its write. Now you've got half a message,
> DT> then a complete message, then the rest of the message ie a
> DT> complete mess. You need locks to ensure mutual exclusion.
>
> nope. you just deal with file proxies to serialize access.
So, you've serialized it, using a "proxy" to control access ie a lock.
>
> DT> Your remote file module will inevitable have to add a lock, or
> DT> transactions, of *some* kind.
>
> nope.
Please, you just admitted as much. How do you avoid the race condition
otherwise? You need to ensure mutual exclusion.
>
> DT> I'll put this as gently as I can - why would I want any of that,
> DT> when I *already* have CORBA/J2EE? What problem does all this stuff
> DT> solve, except the vendor's need for customer lock-in on their
> DT> ill-conceived proprietary junk written by god-knows who?
>
> it is much faster to develop message passing systems than comparable rpc
> based ones. check out all the MOM systems out there.
Like what? I tried thinking of something I could build with messages
that have no acknowledgement, and couldn't. How do you know when
something failed? And right away ... not when some admin notices that
things have gone pear-shaped.
And why are they "faster to develop". Is there any evidence of this? I'm
pretty fast, too, you know ;)
> also stem is open
> source, pure perl and aimed at the admin and network developer
> markets. i doubt any of those will ever use corba/j2ee in their lives.
The vast majority of network developers will never use CORBA/J2EE?
Sounds unlikely. Scanned the job listings, lately?
>
> DT> I already have perfectly good messaging services that are
> DT> well-defined, and designed by sensible people via a public
> DT> process, that run on top of CORBA/J2EE, if messaging is *really*
> DT> what I want (ie my problem is inherently so loosely coupled that I
> DT> don't need to know if anyone actually receives any of these
> DT> messages. I'm not sure what that would be, though. MP3 swapping?)
>
> rpc can't do true message passing. tell me how you do this:
>
> take a single complex user request, break it up into multiple parallel
> requests to the same DB (and even other servers) and wait until all of
> them are completed, then send the combined results back to the
> user. with threads you are forced to serialize all the requests or spend
> half your code synchronizing them. with stem this is trivial as parallel
> access is built in to message passing and the gather module will
> synchronize the results coming back.
With an event service? This provides everything you could ever want. You
can register publishers and subscribers, and the rest is as you describe.
>
> DT> Again, I don't see how you magically make the need to avoid race
> DT> conditions on shared resources just go away, and I think this
> DT> "scale as needed" statement is a non-sequitor once again, as it
> DT> implies that other designs don't, which is not true.
>
> tell me how to run threads on a farm of boxes. it just can't be done.
Straw man. You presume I was proposing "threads" as the "other design".
My first answer would be an OO design. Then I'd just migrate my CORBA
objects transparently, to wherever I like. Done!
Of course, if my system was built around a CORBA event service,
everything you say about "message services" also applies. But like I
said, I've never used such things as I need more reliability than that
implies.
>
> look, this is getting nowhere.
Yes, you're bashing away at a straw man to no avail! Stop repeating
whatever past arguments you've had with other people, it's annoying!
> i done many years of work in events and
> message passing have never had a race condition or blocking problems.
Presumably you actually locked shared resources by using these "proxies"
which serialized access to them. So you have used "locking", or "mutual
exclusion", you're just not thinking in the standard multi-processing
terminology ie threads of control, shared resources and mutual exclusion.
If you're talking to a database, then you get another form of
serialization - transactions, so once again, you can't avoid the issues.
> i
> have also used threads. you are and always will be a thread person. you
> are the type i mentioned who (at the moment) can't understand how to
> architect a message passing system so it doesn't have race conditions
> and blocking problems.
Straw man. I actually understand parallelism and it's problems and
benefits at the abstract level, having studied as part of my
post-graduate work.
You *must* arrange for shared resources to be altered coherently.
Usually these days by serializing with locks - but having another
process that only allows one alteration at a time *is* a kind of a lock.
See?
> threads have their place as i said but in complex
> distributed applications they fall down IMNSHO.
Why? You've got exactly the same set of problems, solving them in
similar ways. Of course, you can always make systems perform better by
making them less reliable ie loosely coupled, but sometimes you don't
get to take that road due to reliability and consistency constraints.
--
Derek Thomson.
------------------------------
Date: Sun, 06 Oct 2002 08:37:29 +0100
From: Dave Cross <dave@dave.org.uk>
Subject: Re: newbie question - perl vs ?
Message-Id: <pan.2002.10.06.07.37.28.276164.8394@dave.org.uk>
On Sat, 05 Oct 2002 22:02:28 +0100, Ken wrote:
[ Please don't top-post]
> The best way to learn perl is to program in Perl. Studying other
> people's code is also very helpful. Download some perl scripts and try
> making some changes to them. Learning Perl by simply reading books
> without doing any actual coding is going to be difficult at best. Just
> try writing or editing code with your Perl books in front of you. The
> more you program the less you'll find yourself flipping through your
> references.
This is true.
> A great place to find scripts is at
> http://cgi.resourceindex.com/Programs_and_Scripts/Perl/
But the problem with this approach is that most of these "script
repository" sites simlpy list all of the programs they can find. As the
majority of Perl programs available on the internet are badly written
you're likely to end up picking up some very bad habits from reading
random Perl programs that you find on the internet.
For example of good Perl code try Perlmonks <http://perlmonks.org/>.
Dave...
--
Drugs are just bad m'kay
------------------------------
Date: 6 Oct 2002 01:33:29 -0700
From: shijialee@hotmail.com (Qiang)
Subject: Re: newbie question - perl vs ?
Message-Id: <b1f13455.0210060033.4a8afab0@posting.google.com>
mjd@plover.com (Mark Jason Dominus) wrote in message news:<anmv50$bsn$1@plover.com>...
> In article <omttpu46q8fto14mml32e7qnqtf8cg1j46@4ax.com>,
> Tim B. <tim@ironwork.com> wrote:
> >Having read and reread "Learning Perl", I'm starting to get into the
> >book, "Programming Perl" and am having a tough time of it. Perl is so
> >idiomatic that learning it is like learning English as an adult. One
> >is faced with mountains of context issues, stylistic variations, all
> >of which can be used to do the same thing, and a plethora of symbols,
> >many of which are to be understood differently when used in different
> >ways. Although similar variations exist in other languages, the
> >extent of this situation is much greater in Perl than in any other
> >language I have ever seen.
> >
> >On the other hand, I am commited to working in a Linux/Open source
> >environment and need the extensive capabilities that I have been told
> >Perl offers. I'm just afraid I'll be old and crippled (mentally), by
> >the time I get proficient enough with Perl to use it productively.
I myself was like that when i started learning perl. instead starting
out with LP, i read couple of perl books from school library breifly.
then i jumped on to "Programming Perl". It's a book like the online
doc. I actually forced me to read the chapters one by one. and the
syntax just fit my taste and it made the reading fun.
I finished the book long time ago. although i read all of them,but
some are just slight impression to me since i never used the parts or
haven't used it for long time. So i have to go back to the book from
time to time. just today, i forgot lookahead completely... :( i found
i don't use much advanced pattern matching in perl and that makes me
feel miss out something.
but Mark has the good word. start small and grow big. if you don't
know something, that's okay. you will when you need it. don't look too
far away, do it now.
I actually forgot why i chose to learn perl. but i am glad i chose
perl.
> I don't know if you read the preface of your camel book, but there's a
> paragraph I especially like on pages xvii-xviii:
>
> Most important, you don't have to know everything there is to
> know about Perl before yu can write useful programs. You can
> learn Perl "small end first". You can program in Perl
> Baby-Talk, and we promise not to laugh....Any level of
> language proficiency is acceptable in Perl culture. We won't
> send the language police after you. A Perl script is
> "correct" if it gets the job done before your boss fires you.
>
hey, i never read this.. now they can be my programming perl motto :)
> >Are there any viable language options to Perl?
>
> In my honest opinion, no. I was a professional unix system
> administrator at the time Perl was rising to prominence, and before
> Perl I did most of my work in a combination of Bourne shell, awk, and
> C. I switched to Perl for a reason: It was a vastly superior
> solution.
I think python is a good language to get started. It's easier as a lot
ppl said. but do your own research. stick with one and don't bother
what other ppl say. otherwise you will be busy switching and
hesitating, and learn nothing.
hope it help.
James.Q.L
------------------------------
Date: Sun, 06 Oct 2002 00:46:31 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Reproduce Datafile
Message-Id: <3D9FC027.276B9630@earthlink.net>
Andre Norman wrote:
[snip]
> I want to read each record and create a new file with all the records
> that dont have a D in the 7th position. I would also like to have the
> eight 0's converted to 20020101
[snip]
> What I do know is that D will always be in 98th position and the eight
> 0s will always be in the 600th position. Again I won't know how many
> characters follow the 0s.
perl -ln \
-e 'next if substr($_, 98, 1) ne "D";' \
-e 'substr($_, 600, 8) = "20020101";' \
-e 'print' DATA.TMP > NEWDATA.TMP
--
my $n = 2; print +(split //, 'e,4c3H r ktulrnsJ2tPaeh'
."\n1oa! er")[map $n = ($n * 24 + 30) % 31, (42) x 26]
------------------------------
Date: Sun, 06 Oct 2002 08:09:09 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Script to Change Filename
Message-Id: <skrvpu827isdj3t6vmufp95ci06kek9em0@4ax.com>
Walter Roberson wrote:
>Provided that you are already in the right directory...
>
>($newfilename = $oldfilename) =~ s/(^\d+)([a-f])\.bat/$1-$2.bat/;
>rename $oldfilename, $newfilename if $newfilename ne $oldfilename;
They were ".dat" files. But, for the rest: put this in the callback code
block for File::Find, use $_ instead of oldfilename, anchor with '$' at
the end of the regex, and you have your code. Well, instead of testing
if the old and the new name are the same, you can test if the s///
worked.
use File::Find;
find sub {
if(-f and (my $newfilename = $_) =~
s/(^\d+)([a-f])\.dat$/$1-$2.dat/) {
rename $_, $newfilename;
}
}, $startdir;
--
Bart.
------------------------------
Date: Sun, 06 Oct 2002 05:07:48 GMT
From: Fred <No_Mail_Address@cox.net>
Subject: Re: What does [^\n] mean
Message-Id: <3D9FC542.69F04CC2@cox.net>
Tad McClellan wrote:
>
> Fred <No_Mail_Address@cox.net> wrote:
>
> > Also I thought that with $/ = undef;
> > all \n are removed.
>
> What made you think that?
>
> Did you read it somewhere?
>
> --
> Tad McClellan
When I run the following code, the resulting file is one single line,
with one single line break at the very end...:
open(IN, '<C:\aa\inbox') or die "Cannot open IN: $! \n";
open(OUT, '>C:\aa\RawList.txt') or die "Cannot open OUT: $! \n";
$/ = undef;
while(<IN>){
s/\s+/ /g ;
print OUT $_, "\n";
}
close(OUT) or die "could not close OUT: $!";
close(IN) or die "could not close IN: $!";
--
Fred
------------------------------
Date: Sun, 06 Oct 2002 05:38:47 GMT
From: Fred <No_Mail_Address@cox.net>
Subject: Re: What does [^\n] mean
Message-Id: <3D9FCC85.4E00F2EA@cox.net>
"John W. Krahn" wrote:
>
> Fred wrote:
> >
> > The following code is from a script for cleaning mailfiles, it removes
> > the (multiline) "Received:" sections:
> >
> > ....
> > $/ = undef;
> > while (<INPUT>) {
> > s/^(Received:\s[^\n]+\n)(\s+[^\n]+\n)*//mg;
> > print OUTPUT $_,"\n";
> > }
> > .....
> >
> > My problem is that I cannot understand how it works. I made searches
> > for [^\n] and ^\n in the CSPAN-manual and in Perl book CD-ROM's but
> > could not find anything useful. Also I thought that with $/ = undef;
> > all \n are removed.
>
> [^\n]+ means to match one or more characters that is not a newline
> character which is the same as .+ when the /s option is not used. The
> substitution operator appears to be removing Received lines from e-mail
> headers which can span more than one physical line. The capturing
> parentheses aren't required if that is all it is doing.
>
> s/^Received:\s.+\n(?:\s+.+\n)*//mg;
> --
> John
>
Yes, the result is exactly the same with your much shorter code. What
I dont understand is the role of the (?: - the CSPAN manual calls it
"non-backreffing grouping paren" - but what does that actually mean?
--
Fred
------------------------------
Date: 6 Oct 2002 06:13:24 GMT
From: "Tassilo v. Parseval" <Tassilo.Parseval@post.rwth-aachen.de>
Subject: Re: What does [^\n] mean
Message-Id: <anoka4$ila$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Fred:
> "John W. Krahn" wrote:
>> [^\n]+ means to match one or more characters that is not a newline
>> character which is the same as .+ when the /s option is not used. The
>> substitution operator appears to be removing Received lines from e-mail
>> headers which can span more than one physical line. The capturing
>> parentheses aren't required if that is all it is doing.
>>
>> s/^Received:\s.+\n(?:\s+.+\n)*//mg;
>>
> Yes, the result is exactly the same with your much shorter code. What
> I dont understand is the role of the (?: - the CSPAN manual calls it
> "non-backreffing grouping paren" - but what does that actually mean?
Round parens store anything they matched for later use in the variables
$1, $2, etc. $1 holds what the first pair of parens captured, $2 store
the match of the second pair of parens etc. When being inside a regex,
there is the non-variable equivalent \1, \2, ... that can be used to
match something previously matched again:
"abcdab" =~ /(..).*\1/
matches, because the parens match 'ab', any sequence of characters and
then they find another occurance of the first match 'ab'.
Yet, if you use ?: the parens are only used for grouping, that is,
nothing is stored in $1 or \1 respectively. The above received-pattern
works just as fine with capturing-parens but since it is of no interest
what those matches were, you can tell Perl to use non-backreffing
parens. This will save a few bytes of memory and copying the match into
a variable. Hence, your regex will be more performant.
Tassilo
--
$_=q!",}])(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
------------------------------
Date: Sun, 06 Oct 2002 09:23:13 GMT
From: "John W. Krahn" <krahnj@acm.org>
Subject: Re: What does [^\n] mean
Message-Id: <3DA000F4.42E99BA7@acm.org>
Fred wrote:
>
> Tad McClellan wrote:
> >
> > Fred <No_Mail_Address@cox.net> wrote:
> >
> > > Also I thought that with $/ = undef;
> > > all \n are removed.
> >
> > What made you think that?
> >
> > Did you read it somewhere?
>
> When I run the following code, the resulting file is one single line,
> with one single line break at the very end...:
That is because _your_ code removes the newlines (and carriage returns
and form feeds and tabs.)
> open(IN, '<C:\aa\inbox') or die "Cannot open IN: $! \n";
> open(OUT, '>C:\aa\RawList.txt') or die "Cannot open OUT: $! \n";
>
> $/ = undef;
>
> while(<IN>){
The file is read into the $_ variable with each line ending with \n.
> s/\s+/ /g ;
The \s+ regular expression matches all " ", "\t", "\n", "\r" and "\f"
characters and replaces them with a " " character.
> print OUT $_, "\n";
> }
>
> close(OUT) or die "could not close OUT: $!";
> close(IN) or die "could not close IN: $!";
John
--
use Perl;
program
fulfillment
------------------------------
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.
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 3924
***************************************
