Re^2: Sharing STDIN after fork

It seems like you are trying to cram a great deal of functionality into a single piece of code

Yes...having slept on it, I have sort of come to the same conclusion!

I am definitely thinking that feeding the people that need an email into a database table is a better approach. That seems to give several advantages:

The list of emails to send doesn't get lost if there is some inturuption
People who are sent two different emails can have them automagically separated by a few hours
There's less for the sending script to contend with - it just picks the next address from the database and sends

Comment on Re^2: Sharing STDIN after fork

Replies are listed 'Best First'.
Re^3: Sharing STDIN after fork by talexb (Chancellor) on Feb 14, 2022 at 04:43 UTC
Great! This also follows the Unix philosophy, which is to have a variety of tools, each of which is excellent at doing one specific thing (with some obvious exceptions). Those tools can then be combined into a larger machine to complete a much more complicated task. Alex / talexb / Toronto Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013. Edit: Add the missing word 'complete' to the last sentence. Ugh.	[reply]
Re^4: Sharing STDIN after fork by Bod (Parson) on Feb 14, 2022 at 16:11 UTC
As it happens, today a new feature has been suggested that will necessitate holding the information in a database table - namely being able to schedule the email sending for some time in the future. So I will either be implementing it this way or perhaps using Minion as suggested by etj	[reply]