in reply to How can one open a filehandle in realtime or current log

avoid getting repeated emails until the hour changes.

To meet those requirements:

To avoid "getting repeat emails", you need to avoid asking for files that will include repeat emails.

And to do that, that is, to get nothing "until the hour changes", you would need to know what the last hour you processed was.

In order to do that you would need to store the hour that you last processed. There are several ways you might do that:

Update:Thinking about it, the latter won't work unless you can arrange for the next instantiation of the script to get the modified environment rather its predecessor's inherited environment; which probably isn't the case.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re: How can one open a filehandle in realtime or current log

Replies are listed 'Best First'.
Re^2: How can one open a filehandle in realtime or current log
by Laurent_R (Canon) on Mar 16, 2016 at 23:33 UTC
    It could also be stored in a database (which is in a way just another way of storing it in the file system). I sort of hate to say that, because I am often getting a bit angry when I see other monks suggesting a database approach for cases where I think it would not work properly (for example, database access is often 2 to 3 (or more) orders of magnitude slower than hashes, so that suggestion to use databases instead of hashes are often ill-advised IMHO), but, here, this is something completely different, it is just a matter of making one single piece of data available to a program.

    As for environment variables, yes, it would probably not work if the Perl program environment is abandoned, but there might be some ways of doing thing where you could keep the current environment, for example if the next instance of the script is launched by the last one (with a proper delay, sleep time, or some other way to control launch time).

    This may seem not very robust, but we are using something like that on a group of 7 VMS platforms. VMS does not have a cron tab, but has a queue system on which you can submit a job on a given future date. We have a crucial daily process to update our replicated databases with the production data every night. The process does the required update work and then submits the next execution for the next day, passing appropriate parameters. This actually works fairly well. We just need not to forget to update the whole shebang when we fiddle with the process or when a reboot occurs.

    Our use case is quite different from the OP's, but it might still be the idea of a possible solution.

      yes, it would probably not work if the Perl program environment is abandoned ...

      He did say: "It will be set to run in a cron job every minute.".

      It could also be stored in a database ...

      Agreed. (Though I did say "There are several ways" and mentioned 3, then dismissed one; not 'there are only 3 ways".)

      He might also (for example):

      • Create a shared memory segment;
      • Or a registry key;
      • Or a registry value;
      • Or any other persistent namespace that applies to whatever OS he is running under.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice.