[32352] in Perl-Users-Digest
Perl-Users Digest, Issue: 3619 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 22 16:09:29 2012
Date: Wed, 22 Feb 2012 13:09:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 22 Feb 2012 Volume: 11 Number: 3619
Today's topics:
Re: [OT] addresses and interfaces (was Re: Can't connec <ben@morrow.me.uk>
Re: [OT] addresses and interfaces <rweikusat@mssgmbh.com>
Re: [OT] addresses and interfaces <rweikusat@mssgmbh.com>
Re: a question about efficiency <ben@morrow.me.uk>
Re: a question about efficiency <ben@morrow.me.uk>
Re: a question about efficiency (Tim McDaniel)
Re: a question about efficiency (Seymour J.)
Re: a question about efficiency <kiuhnm03.4t.yahoo.it>
Re: a question about efficiency <kiuhnm03.4t.yahoo.it>
Re: a question about efficiency (Tim McDaniel)
Re: Can't connect to 'localhost' in IO::Socket <mvdwege@mail.com>
Re: Can't connect to 'localhost' in IO::Socket (Tim McDaniel)
Re: Can't connect to 'localhost' in IO::Socket <rweikusat@mssgmbh.com>
Re: Can't connect to 'localhost' in IO::Socket <m@rtij.nl.invlalid>
Re: Perl search string <rvtol+usenet@xs4all.nl>
Re: use file::find to find files modified in last 5 day <ben@morrow.me.uk>
Re: use file::find to find files modified in last 5 day <justin.1201@purestblue.com>
Re: use file::find to find files modified in last 5 day (Tim McDaniel)
Re: use file::find to find files modified in last 5 day <ben@morrow.me.uk>
Re: use file::find to find files modified in last 5 day <jimsgibson@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 22 Feb 2012 14:12:46 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [OT] addresses and interfaces (was Re: Can't connect to 'localhost' in IO::Socket)
Message-Id: <un9f19-rvk.ln1@anubis.morrow.me.uk>
Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
> On Wed, 22 Feb 2012 12:16:34 +0000, Ben Morrow wrote:
>
> > Rainer was (implicitly) talking about using a specific socket binding as
> > a means of filtering connections by *source* address. He is quite
> > correct this isn't possible on a weak ES; it's also just as stupid and
> > dangerous as any other form of filtering by IP that isn't backed up by
> > some more secure form of authentication.
>
> Actually he wasn't. What he was pointing out (which had nothing to do
> with the OPs question, I agree) is that a WES accepts connection on any
> address on any interface. Not just on the interface the address is
> configured on.
Yes, but why do you care unless you're treating connections on one
interface as more privileged than connections on another?
> > bindings for this reason: for instance, a server that uses SSL or
> > Kerberos that thought it was serving on address A will fail to
> > authenticate connections where the client was trying to connect to
> > address B.
>
> I don't know about Kerberos, but this is not true for SSL.
Suppose I have a machine with two names and two addresses, 'foo' =>
10.0.0.1 and 'bar' => 10.0.0.2, and an SSL webserver listening on the
wildcard address with a certificate for 'foo'. If a client connects to
https://bar/, it will see an invalid certificate. This is likely to
result in a more confusing error than 'connection refused'.
There are various ways around this, the most obvious being to serve a
different certificate based on the incoming destination address
(assuming you have one), but they all require being aware of the fact
you are listening on multiple addresses. It's often easier to manage
this if you have separate sockets listening on the individual addresses
than with a wildcard.
None of this is specifix to HTTP, of course, that's just a convenient
example. In general clients tend, or at least *should* tend, to treat
a successful connection with an invalid certificate as a more serious
problem than a refused connection.
> > In any case, Unix systems can generally be configured as strong ESs now,
> > at least as far as requirement (A) (rejecting packets coming in on the
> > wrong interface) goes. Most firewall packages have some sort of
> > 'antispoof' mechanism that does this.
>
> Ah, no. You are confusing anti-spoofing with strong end systems
> requirements. One deals with source addresses, the other with destination
> addresses. If you want strong end behavior, you have to put that into
> firewall rules yourself.
You're right, I am. I was thinking of e.g. FreeBSD's net.inet.ip.
check_interface sysctl, which does implement (A) (but not (B)).
Ben
------------------------------
Date: Wed, 22 Feb 2012 15:58:54 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [OT] addresses and interfaces
Message-Id: <87pqd62729.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Martijn Lievaart <m@rtij.nl.invlalid>:
[...]
>> I don't know about Kerberos, but this is not true for SSL.
>
> Suppose I have a machine with two names and two addresses, 'foo' =>
> 10.0.0.1 and 'bar' => 10.0.0.2, and an SSL webserver listening on the
> wildcard address with a certificate for 'foo'.
Suppose I've intentionally configured a DNS server and a web server
such that the DNS information is inconsistent with the web server
configuration ...
> If a client connects to https://bar/, it will see an invalid certificate.
... it is then conceivable that this inconsistent configuration breaks
transparent HTTPS access to this server! How this relates to the
original problem seems somewhat unclear to me. The solution to this
contrived problem is to fix the DNS configuration: Provided that
clients can legitmately access the same HTTPS server using either
address, the A records for both need to associate the same name to
each address.
BTW, at least for Apache, your example doesn't exactly make sense
because the HTTP server usually listens on the wildcard address and
matches incoming requests to virtual SSL servers by looking for a
virtual server configuration matching the destination address of the
request and using the certificate etc configured for this virtual
server.
------------------------------
Date: Wed, 22 Feb 2012 16:15:38 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: [OT] addresses and interfaces
Message-Id: <874nui26ad.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> There are various ways around this, the most obvious being to serve a
> different certificate based on the incoming destination address
> (assuming you have one), but they all require being aware of the fact
> you are listening on multiple addresses. It's often easier to manage
> this if you have separate sockets listening on the individual addresses
> than with a wildcard.
There's no need to 'manage this' by writing (or downloading :->)
application code which maintains a userspace database of socket <->
address bound to this socket mappings, the kernel already does that.
[rw@sapphire]~ $perldoc -f getsockname
getsockname SOCKET
Returns the packed sockaddr address of this end of the
SOCKET connection, in case you don't know the address because
you have several different IPs that the connection might have
come in on.
use Socket;
$mysockaddr = getsockname(SOCK);
($port, $myaddr) = sockaddr_in($mysockaddr);
printf "Connect to %s [%s]\n",
scalar gethostbyaddr($myaddr, AF_INET),
inet_ntoa($myaddr);
[formatting changed]
------------------------------
Date: Wed, 22 Feb 2012 14:26:07 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: a question about efficiency
Message-Id: <vgaf19-rvk.ln1@anubis.morrow.me.uk>
Quoth Justin C <justin.1201@purestblue.com>:
> On 2012-02-21, Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> > In <4f43d60b$0$1387$4fafbaef@reader2.news.tin.it>, on 02/21/2012
> > at 06:36 PM, Kiuhnm <kiuhnm03.4t.yahoo.it> said:
> >
> >>"Learning Perl" won't give me too many details until my fragile mind
> >>is ready to assimilate them :)
> >
> > I found that it was easier to learn from "Programming Perl" than from
> > "Learning Perl".
>
> From my non-programming background I found Learning Perl to be
> excellent, and *very* accessible. I find PP to be rather dense and,
> because of it's size, daunting - I did, though, learn about complex data
> structures from that and it blew my mind, I've not picked it up since, I
> really should.
The usual recommendation is that people who can already program (in some
other language) should start with PP, and people who can't should start
with LP. AIUI (I haven't read it: Perl was not my first language, so I
started with PP :) ) LP takes you through a lot of basic programming
concepts that will be invaluable to someone who hasn't met them before
but just get in the way for someone who has.
Ben
------------------------------
Date: Wed, 22 Feb 2012 14:22:29 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: a question about efficiency
Message-Id: <5aaf19-rvk.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <ji22it$79h$1@reader1.panix.com>, on 02/22/2012
> at 06:39 AM, tmcd@panix.com (Tim McDaniel) said:
>
> >Unfortunately, too often I've been stuck on servers where I am not
> >a sysadmin or otherwise dare not touch Perl. I can do modules for
> >myself, but that doesn't help with code for others.
>
> Aren't you more likely to find Perl already installed than Python or
> Ruby? If you're not allowed to download and install a CPAN module than
> I doubt that you'd be allowed to install a new language processor.
More importantly, *if* you can't touch the system perl but you could
install ruby, you probably can install your own build of perl in its own
directory and use that for your own work. You don't need root to do
this: you can perfectly well build and install perl in a private
directory as an unprivileged user, you just have to make sure you adjust
your #! lines as appropriate.
Of course, you probably did ought to think about questions like 'if my
perl install is owned by the same user that is running my application,
is this a security hole?' (answer: yes). But that applies to the script
files your application is stored in, as well.
Ben
------------------------------
Date: Wed, 22 Feb 2012 16:30:21 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: a question about efficiency
Message-Id: <ji356t$os4$1@reader1.panix.com>
In article <ji22it$79h$1@reader1.panix.com>,
Tim McDaniel <tmcd@panix.com> wrote:
>In article <4f443df2$4$fuzhry+tra$mr2ice@news.patriot.net>,
>Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>>In <ji1621$4i3$1@reader1.panix.com>, on 02/21/2012
>> at 10:32 PM, tmcd@panix.com (Tim McDaniel) said:
>>
>>>I don't know how much power it has,
>>
>>Just the core language? One of the things that makes Perl attractive
>>is CPAN.
>
>Unfortunately, too often I've been stuck on servers where I am not a
>sysadmin or otherwise dare not touch Perl. I can do modules for
>myself, but that doesn't help with code for others.
Another reply had:
> Aren't you more likely to find Perl already installed than Python or
> Ruby? If you're not allowed to download and install a CPAN module
> than I doubt that you'd be allowed to install a new language
> processor.
Sorry -- I went off on a tangent. You're right that I'm stuck in the
same way when it comes to choosing Perl versus Python versus Ruby -- I
can't install any of them in a system area if I want to share code.
I was addressing the tangental point "One of the things that makes
Perl attractive is CPAN". As it happens, Perl code I write is
executed by others, so I'd have to convince support to install and
support a useful module. Or I could usually copy its source, and then
I ought to go back every so often to integrate changes.
But we know the drawbacks of the reverse, building things into the
language ...
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 22 Feb 2012 12:36:33 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: a question about efficiency
Message-Id: <4f4527a1$12$fuzhry+tra$mr2ice@news.patriot.net>
In <vgaf19-rvk.ln1@anubis.morrow.me.uk>, on 02/22/2012
at 02:26 PM, Ben Morrow <ben@morrow.me.uk> said:
>The usual recommendation is that people who can already program (in
>some other language) should start with PP, and people who can't
>should start with LP.
That aligns with my experience.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Wed, 22 Feb 2012 20:38:29 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: a question about efficiency
Message-Id: <4f454435$0$1382$4fafbaef@reader1.news.tin.it>
On 2/21/2012 23:32, Tim McDaniel wrote:
>>> If you think curly braces are "hideous", you might prefer using
>>> some other language instead.
>>
>> How drastic!
>
> I think cashews and pecans and peanuts are great. If you're allergic
> to them, why can't I suggest you try other things?
>
> If curly braces are going to make you grit your teeth and detest the
> language whenever you deal with them, why not save yourself the pain?
I'm just a little surprised that I need braces to enclose single statements.
I'm learning Perl because I'm interested in security (vulnerabilities,
malware, rootkits, etc...) and many scripts are written in Perl. Python
is also on my list.
> I've heard good things about Ruby.
I read its documentation a few years ago. Nothing new, but very well
designed.
Kiuhnm
------------------------------
Date: Wed, 22 Feb 2012 20:51:56 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: a question about efficiency
Message-Id: <4f45475c$0$1382$4fafbaef@reader1.news.tin.it>
On 2/21/2012 22:34, Shmuel (Seymour J.) Metz wrote:
> In<4f43d60b$0$1387$4fafbaef@reader2.news.tin.it>, on 02/21/2012
> at 06:36 PM, Kiuhnm<kiuhnm03.4t.yahoo.it> said:
>
>> Of course. What strikes me is that strange "for".
>
> See statement modifiers in perlsyn.
>
>> "Learning Perl" won't give me too many details until my fragile mind
>> is ready to assimilate them :)
>
> I found that it was easier to learn from "Programming Perl" than from
> "Learning Perl".
Thanks for the tip. My idea was to read
Learning Perl,
Intermediate Perl and
Mastering Perl,
but I'll have a look at PP. It seems that the latest edition covers Perl
5.14 as well.
Kiuhnm
------------------------------
Date: Wed, 22 Feb 2012 19:53:33 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: a question about efficiency
Message-Id: <ji3h3t$3cu$1@reader1.panix.com>
In article <4f454435$0$1382$4fafbaef@reader1.news.tin.it>,
Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> I'm just a little surprised that I need braces to enclose single
> statements.
There are reasons. It's easy to forget curly braces and not realize
that the indentation and control flow are not as you expected:
if (-x "$path/$basename")
$name = "$path/$basename";
last;
or the "dangling else" problem:
if (this)
if (that)
stuff;
else
other_stuff;
(Note that in neither case does the indentation match the control
flow, and neither is valid Perl without adding curly braces.)
I think more languages are tending towards viewing Pascal, C, and
C++'s use of optional grouping as a mistake, and tend to require
delimiters.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 22 Feb 2012 17:04:03 +0100
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Can't connect to 'localhost' in IO::Socket
Message-Id: <86y5ru6ej0.fsf@gaheris.avalon.lan>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Tue, 21 Feb 2012 08:29:24 +0100, Mart van de Wege wrote:
>
>> Wolfram Humann <w.c.humann@arcor.de> writes:
>>
>>> On 20 Feb., 14:55, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>>>> It is usually more sensible to bind to the wildcard address,
>>>> especially considering that IP addresses are usually per-host and not
>>>> per-interface, meaning, by default, any address that's configured on
>>>> any public interface of some computer will reachable via all other
>>>> public interfaces (so-called 'weak end-system').
>>>
>>> So I would simply say Transports => ['TCP:Port=1700,Host=']
>>>
>>> with the corresponding netstat (thanks for the -l / -a tip!) reply:
>>>
>>> tcp 0 0 *:1700
>>> *:* LISTEN
>>>
>>> Is that what you meant? Does this wildcard create any security issues
>>> (exceeding those potentially present before by providing *any* TCP-
>>> accessible service)?
>>>
>> Do note that Rainer is wrong there. IP addresses are bound to an
>> interface, always. DNS may not care about that and give you just an IP
>> address if you know the hostname, but if you're trying to connect,
>> especially on a LAN or on a local machine, it is *important* that you
>> known which interface is being listened on.
>
> Sorry but Rainer is absolutely correct and you are absolutely wrong. It's
> an important concept, so I suggest you Google it.
>
Martijn,
On what interface will a host answer ARP queries?
That's the interface the IP is bound to. In general deployments, more is
not needed, if that means the host answers on *all* interfaces.
Yes, I know there are specialist tricks that work around this. For
ordinary server programming bringing that up is needless pedantry.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Wed, 22 Feb 2012 16:38:04 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Can't connect to 'localhost' in IO::Socket
Message-Id: <ji35lc$os4$2@reader1.panix.com>
In article <86y5ru6ej0.fsf@gaheris.avalon.lan>,
Mart van de Wege <mvdwege@mail.com> wrote:
>bringing that up is needless pedantry.
"Needless" and "pedantry" don't fit together.
I can explain at greater length.
--
Tim (I cannot write too much in praise of brevity) McDaniel,
tmcd@panix.com
------------------------------
Date: Wed, 22 Feb 2012 17:14:34 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Can't connect to 'localhost' in IO::Socket
Message-Id: <87r4xmzt6t.fsf@sapphire.mobileactivedefense.com>
Mart van de Wege <mvdwege@mail.com> writes:
> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>
>> On Tue, 21 Feb 2012 08:29:24 +0100, Mart van de Wege wrote:
>>
>>> Wolfram Humann <w.c.humann@arcor.de> writes:
>>>
>>>> On 20 Feb., 14:55, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>>>>> It is usually more sensible to bind to the wildcard address,
>>>>> especially considering that IP addresses are usually per-host and not
>>>>> per-interface, meaning, by default, any address that's configured on
>>>>> any public interface of some computer will reachable via all other
>>>>> public interfaces (so-called 'weak end-system').
>>>>
>>>> So I would simply say Transports => ['TCP:Port=1700,Host=']
>>>>
>>>> with the corresponding netstat (thanks for the -l / -a tip!) reply:
>>>>
>>>> tcp 0 0 *:1700
>>>> *:* LISTEN
>>>>
>>>> Is that what you meant? Does this wildcard create any security issues
>>>> (exceeding those potentially present before by providing *any* TCP-
>>>> accessible service)?
>>>>
>>> Do note that Rainer is wrong there. IP addresses are bound to an
>>> interface, always. DNS may not care about that and give you just an IP
>>> address if you know the hostname, but if you're trying to connect,
>>> especially on a LAN or on a local machine, it is *important* that you
>>> known which interface is being listened on.
>>
>> Sorry but Rainer is absolutely correct and you are absolutely wrong. It's
>> an important concept, so I suggest you Google it.
>>
> Martijn,
>
> On what interface will a host answer ARP queries?
>
> That's the interface the IP is bound to.
arp_filter - BOOLEAN
[...]
0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not by
particular interfaces.
http://www.linuxfoundation.org/collaborate/workgroups/networking/ip-sysctl
-----------------
Description
Determine whether a packet arriving on a non-forwarding interface
can be accepted for an IP address that is not explicitly
configured on that interface. If ip_forwarding is enabled, or
xxx:ip_forwarding for the appropriate interfaces is enabled, then
this parameter is ignored, because the packet is actually
forwarded.
Refer to RFC 1122 3.3.2.4.
Default
0 (loose multihoming)
-------------------
http://docs.oracle.com/cd/E19683-01/806-7009/chapter4-29/index.html
I'm presently not in the mood to hunt down information about the
default configuration of more operating systems.
[...]
> For ordinary server programming bringing that up is needless pedantry.
There was a question regarding 'security implications' of binding a
TCP socket to the wildcard address and this was part of the answer.
------------------------------
Date: Wed, 22 Feb 2012 19:30:16 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Can't connect to 'localhost' in IO::Socket
Message-Id: <oqof19-a6s.ln1@news.rtij.nl>
On Wed, 22 Feb 2012 17:04:03 +0100, Mart van de Wege wrote:
> On what interface will a host answer ARP queries?
Most OSses, all interfaces, for all IP addresses.
> That's the interface the IP is bound to. In general deployments, more is
No, it's not.
> not needed, if that means the host answers on *all* interfaces.
This doesn't make sense to me. Are you saying all IP addresses are bound
to all interfaces?
> Yes, I know there are specialist tricks that work around this. For
> ordinary server programming bringing that up is needless pedantry.
No specialist tricks, just how common OSses work out of the box.
Martijn
------------------------------
Date: Wed, 22 Feb 2012 19:37:03 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Perl search string
Message-Id: <4f4535cf$0$6972$e4fe514c@news2.news.xs4all.nl>
On 2012-02-21 15:29, Claudio Palmeri wrote:
> I'm newbie to Perl, and if it possible i'm searching for a simple
> program that reads strings from one file and search it into another
> and if it's found it will be write into a third one.
See also grep(1), that mentions -f FILE.
--
Ruud
------------------------------
Date: Wed, 22 Feb 2012 14:14:09 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: use file::find to find files modified in last 5 days
Message-Id: <hq9f19-rvk.ln1@anubis.morrow.me.uk>
Quoth Justin C <justin.1201@purestblue.com>:
> On 2012-02-22, STD <mikesolomon40@googlemail.com> wrote:
> > I have written a script to find files
> >
> > I now want to be able to pass it a days parameter and only show files
> > modified in the last x days
>
> Have a look at the 'stat' and 'localtime' functions, they should give
> you a clue at to your next step.
...or you could do it the hard way :).
(See my reply xthread.)
Ben
------------------------------
Date: Wed, 22 Feb 2012 15:29:32 +0000
From: Justin C <justin.1201@purestblue.com>
Subject: Re: use file::find to find files modified in last 5 days
Message-Id: <s7ef19-lks.ln1@zem.masonsmusic.co.uk>
On 2012-02-22, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth Justin C <justin.1201@purestblue.com>:
>> On 2012-02-22, STD <mikesolomon40@googlemail.com> wrote:
>> > I have written a script to find files
>> >
>> > I now want to be able to pass it a days parameter and only show files
>> > modified in the last x days
>>
>> Have a look at the 'stat' and 'localtime' functions, they should give
>> you a clue at to your next step.
>
> ...or you could do it the hard way :).
>
> (See my reply xthread.)
I did and I just don't know how people remember all of those.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 22 Feb 2012 16:42:43 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: use file::find to find files modified in last 5 days
Message-Id: <ji35u3$os4$3@reader1.panix.com>
In article <s7ef19-lks.ln1@zem.masonsmusic.co.uk>,
Justin C <justin.1201@purestblue.com> wrote:
>I just don't know how people remember all of those.
There's a lot I don't remember about Perl. I try to remember that
there's a way to do such-and-so and a vague idea of where to look it
up. For "-M", I tried "man perlop", but it's not there -- it's in
"man perlfunc", which makes more sense come to think of it.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 22 Feb 2012 17:44:33 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: use file::find to find files modified in last 5 days
Message-Id: <15mf19-1kn.ln1@anubis.morrow.me.uk>
Quoth Justin C <justin.1201@purestblue.com>:
> On 2012-02-22, Ben Morrow <ben@morrow.me.uk> wrote:
> >
> > Quoth Justin C <justin.1201@purestblue.com>:
> >>
> >> Have a look at the 'stat' and 'localtime' functions, they should give
> >> you a clue at to your next step.
> >
> > ...or you could do it the hard way :).
> >
> > (See my reply xthread.)
> >
[ -M ]
>
> I did and I just don't know how people remember all of those.
I have the sort of brain that lets me read something once and then,
while I don't remember the details, I do retain a sort of 'index' that
reminds me there was something there that has just become relevant. Then
I have to go and look it up to see what it was.
More generally, if you're trying to do something obviously sysadminish,
it's likely Perl has a convenient way to do it.
Ben
------------------------------
Date: Wed, 22 Feb 2012 09:50:25 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: use file::find to find files modified in last 5 days
Message-Id: <220220120950257728%jimsgibson@gmail.com>
In article <ji35u3$os4$3@reader1.panix.com>, Tim McDaniel
<tmcd@panix.com> wrote:
> In article <s7ef19-lks.ln1@zem.masonsmusic.co.uk>,
> Justin C <justin.1201@purestblue.com> wrote:
> >I just don't know how people remember all of those.
>
> There's a lot I don't remember about Perl. I try to remember that
> there's a way to do such-and-so and a vague idea of where to look it
> up. For "-M", I tried "man perlop", but it's not there -- it's in
> "man perlfunc", which makes more sense come to think of it.
'perldoc -f -x' lists all of the file test operators. That is what I
can remember.
--
Jim Gibson
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 3619
***************************************
