There's no reason to be sorry, I think it's great that you noticed a problem and pointed it out. I can't speak for Corion, but I suspect I know what happened--there's a tendency for a new member to give a vague question, and then reply to the answers with things like "but that won't work because I need <insert new requirement here>!", which should have been stated as a requirement in the original question. Since my posts occasionally run overlong (especially when I'm on vacation! Yahoo!) the OP scrolled off the top of the screen, so he likely didn't have the OPs name on the screen, and your replies did kind of look like that sort of "new requirements" feel to it.
I can't think of a good segue between the section above, and the rest of this node (which I wrote earlier). Sorry for the 'speed bump' between sections.
Every monk has their own strategies for selecting questions to answer and the style of answer to offer. You'll find that a well-written question with a good attempt at a solution and sample data will frequently get a more specific answer than a quick question with little effort put into it. My answering style differs depending on (a) how bored I am, (b) how generous I'm feeling that day, (c) how interesting the question is, (d) the phase of the moon, and (e) the current price (yuan) of Oolong tea in China. 8^)
In this case it felt like it might be a homework problem. In general, I don't want to hand an answer to a homework problem over, as it doesn't teach the poster much. But when a half-dozen monks each provide various hints, the poster gets the opportunity to figure out how to put the hints together into an outline[3] and turn it into code--a great way for us to share experience and the poster to flex some programming muscles. So when a problem feels like it might be a homework problem, I tend to just give some hints and/or try to organize their thoughts with a few details thrown in.
Regarding your suggestion that using the presence of output.txt as a signal is dangerous[1]--that's true. But I'm surprised that you didn't offer a hint to one of the well-known solutions to that objection: create the file with a temporary name, and rename it to the final name after it's completely generated. There are, of course, solutions to your other objections (name clashes, etc.)
Finally, when you read a node, you choose (or create) a quick mental model of the person writing the question, and then write your answer for that person[2]. In this particular case, my model of the questioner was of a programmer who already has the code to generate the reports (because of the timings provided for the reports) and probably has related problems solved. Additionally, the question felt fairly specific (if a bit wide-ranging).
[1] Stated best in your reply to Corion.
[2] Which is why having multiple answers is so beneficial. No-one is going to have a complete/accurate mental model of the writer. So instead, you get better coverage with multiple answers.
[3] One of the reasons I didn't bother to give an example of fork, since Corion had already done so. (The other reason being that I've never used fork in perl.)
Update: Repaired misspelling of Corion's name ... I'm so sorry! (Thanks to kile for the catch!)
In reply to Re^5: Split process->check ->and run Parallel
by roboticus
in thread Split process->check ->and run Parallel
by Noame
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |