in reply to using File::Find to find recently-installed modules
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: using File::Find to find recently-installed modules
by Aldebaran (Curate) on Jun 25, 2016 at 09:54 UTC | |
I plead guilty to whatever XY drift there is in the unrolling specification here, but a proper sailor in high seas will not abandon his complete mystification without reporting it as well as he can, for others with better perspective perchance to hear. It would seem files in the local::lib are not possessed of a,c, or mtime, whilst my crummy modules have all 3. My current best script follows with abridged output.
The times I'm looking for *in this context* are bounded below by when they become files in this locale. As further indication of XY shift, I would stipulate that it is sufficient to take the max of them, just in order to make useful time comparisons that will work for gilligan's island. I could just as well write a min function, compare it to the max, and have an interesting statistic about age, but first I'm trying to get squared away with the material in the exercises. I'm still *finding* modules, so I have to wonder how perl is interpreting the underlying windows platform. That neither a,c nor m time for the unix installed modules exists knocks my socks off and, along with the sea forward and backslashes, makes me believe that my logic is faulty. Again, thanks for your comment. | [reply] [d/l] [select] |
by Marshall (Canon) on Jun 25, 2016 at 14:13 UTC | |
That neither a,c nor m time for the unix installed modules exists knocks my socks off and, along with the sea forward and backslashes, makes me believe that my logic is faulty. The issue is that you have a relative path, the '.' File::Find does a cd as it navigates downwards. By the time you do the file test, you are not where you think you are and the file test fails. Since you are actually "in the directory", you can use the simple name of the file, eg. just "Timeout.pm". File::Basename can get that from $File::Find::name. The branch which started with an absolute path name works fine because it doesn't matter what directory that you are in when you do the stat. update: It is not necessary to use "\" on Windows. The "/" will work just fine. That is also true from the command line. The "\" is a hold over from DOS days and causes obvious problems due to its special meaning in Perl. Also worthy of note are side effects of this changing working directory business. If you code something that could "blow up" in Find, you will be left in some random part of the directory tree. Update: Here is some code to demo what I've said. I started in the ".." directory and used basename($File::Find::name) to do a simple file test on the basename.
| [reply] [d/l] |
by Aldebaran (Curate) on Jun 28, 2016 at 10:39 UTC | |
Thank you for this update: I was struggling with this syntax along with having a large reading burden to get into the whole pod scheme. I see now that it can be incremental, as pod is somehow syntactic perl. I had to wade through File::Find.pm just like they tell you to as well as WWW::Mechanize.pm, which I found astonishing under this view. I had never understood all this **clutter** in these modules that couldn't be perl, at least because it lacked semi-colons. So, yeah, light bulb, there. Maybe the castaways leave the coast when they get a pause account, define a local::lib, and declare their real intent to make a didactic effort at the material of gilligan's island. The castaways are logging their misadventures now:
This is how I figured out what has been happening since the 16 days I've had a local::lib :
Output for readmore tags. It's 300 lines of the Minnow being tossed: Read more... (9 kB)
| [reply] [d/l] [select] |
by Marshall (Canon) on Jun 28, 2016 at 23:44 UTC | |