> 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 
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 
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 
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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to