> One thing I was trying to make clear is that my analysis was largely > *mechanical*, using known tools to extract the information that would > direct me to the correct part of the code. It's a collection of > well-known tricks, and since I described them clearly, you can learn > them immediately. >
Hm.. well I definitely did learn a lot from this, and of course you are right it is a straightforward logical process. The main reason I say I wouldn't have got there is down to my intrinsic belief that I was to blame for the error (which I am used to being the case!) For example I did post a couple of related questions on the Perl monks website, but the rather thin suggestions there have been to imply I must be doing something wrong/have my environment set up incorrectly etc. which only served to cement that view - and I think your approach has been very different. Had I looked through the source and seen those routines I would have assumed the coders knew what they were doing, that it was well written, that the lack of comments were only due to the code being 'obvious' to anyone proficient. (It would probably help if I had more familiarity with C - when I get a moment I think I'll try writing some C programs). So the stumbling block I think was more belief system than anything else. If you can arrange for "</dev/null" to be inserted into the command > line that is executed, then fd 0 will be open, and the problem should > be avoided. > Thanks! I will try this. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
