Re: Perl oddities

in reply to Perl oddities

The -M, -A, and -C file test operators return the file modification, access, and creation times in days since the start of the program. Why? Why why why? Does anyone actually use the values for anything other than to compare them to each other?

The relativity of the dates produced by -M, -C and -A are useful for things like "delete all *.tmp files more than 5 days old" etc.

For example, this lists all the .pl file in the current directory that have been modified in the last 24 hours.

perl -le "-M() < 1 and print  for map glob, @ARGV" *.pl
435230.pl
junk.pl
junk2.pl
junk3.pl
[download]

My least favorite oddity is the need to use /g option on a regex in order for pos to be set.

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Comment on Re: Perl oddities Download Code

Replies are listed 'Best First'.
Re^2: Perl oddities by rir (Vicar) on Mar 01, 2005 at 16:17 UTC
My vote for weirdest feature of Perl is `reset`. dates produced by -M, -C and -A are useful for things like "delete all .tmp files more than 5 days old" etc.* And for command line utilities you are making your decision at the time of invocation, $^T, so that is the important time. These op's must have been a grand convenience for `find2perl`. I agree these are a strange and odd convenience feature but given the early mission of Perl to be a better shell/awk/sed I don't find it weird. Be well, rir	[reply] [d/l] [select]
Re^3: Perl oddities by TimToady (Parson) on Mar 01, 2005 at 18:40 UTC
`reset` will be demoted to a method on a package or hash object. It will no longer be a keyword. We can't get rid of the functionality entirely if we want to be able to translate Perl 5 to Perl 6 though. But it can definitely stand to be de-Huffmanized, or more accurately, Huffmanized to be longer. Funny how we associate Huffman with making easy things easier but not harder things harder...	[reply] [d/l]
Re^2: Perl oddities by ysth (Canon) on Mar 01, 2005 at 13:43 UTC
and having it be relative to the start of the program (actually, $^T, which you can change to suit) saves having to call time() for each -M, -A, or -C (in addition to making the results equal for different files with the same timestamp).	[reply]
Re^3: Perl oddities by BrowserUk (Patriarch) on Mar 01, 2005 at 13:51 UTC
saves having to call time() for each -M, -A, or -C (in addition to making the results equal for different files with the same timestamp). I'm not quite sure I follow that. If they just returned the timestamp from the files as absolute values, you wouldn't have to call time() at all? And the results of different files with the same timestamps would be the same anyway? Examine what is said, not who speaks. Silence betokens consent. Love the truth but pardon error.	[reply] [d/l]
Re^4: Perl oddities by halley (Prior) on Mar 01, 2005 at 15:55 UTC
The relative versions allow you to express your problems in problem terms, not in implementation terms. Which is nice when you're writing a `perl -e` type solution. Think of all the other Perl shortcuts that are designed to let you express your solution in terms of the problem, not in terms of the opcodes. -- `[ e d @ h a l l e y . c c ]`	[reply] [d/l]
Re^4: Perl oddities by ysth (Canon) on Mar 02, 2005 at 01:11 UTC
Ah; I was thinking the complaint was that they do not provide instantaneous ages in days, not that they don't just give timestamps, so I was giving justifications for having the ages be reported in terms of a fixed timepoint rather than as of the moment -M, etc. is executed, even though it results in oddities such as negative ages for timestamps later than $^T. bonus points for pointing out missing or extra commas in the above ramble; commas are not my forte	[reply]

In Section Meditations