On Fri, Jan 27, 2012 at 9:48 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: >> If this was pretty much >> going to be /dev/null'ed from the beginning, I'd rather have heard it >> after my first patches. > > Almost always when a developer has an itch, it is _possible_ to > massage a patch that scratches it into something acceptable to others. > And whether it is worth the trouble in terms of time is something that > only that developer can decide. Hannes' reaction and Junio's to his didn't give me the impression they even saw a possibility. > So no, I would not say these patches were not doomed from the > beginning. However, I certainly agree that in their current form they > are more complicated than the use case justifies. Good. That's something we can work on. > There is a tension between requirements that leaves me oddly > uncomfortable with the series: > > a. on one hand, it would be nice to preserve all the current features > of execvp(), which makes the approach of only doing post-mortem > analysis after a failed execvp appealing; > > b. on the other hand, it would be nice [*] to avoid launching a pager > only in order to call execvp for a command that does not exist when > the fallback might be to an alias to a command that does not want a > pager. That would require figuring out in advance that execvp > would fail with ENOENT and missing out on possible system extensions > that allow execvp to run shell built-in commands not existing on > the filesystem. Just for my understanding: before a command is executed, a pager (less/more or so) is started? We want to avoid starting the pager if we won't be able to execute the command? > I want to like (b), but the downside seems unacceptable. The downside being: having to figure out what execvp is going to do? That would be tantamount to writing your own execvp. > I honestly > don't know if something like (a) would be a good idea if well > executed, so I was happy to have the opportunity to try to help > massage these patches into a form that would make the answer more > obvious. Given the above information, I'm happy to work on this to see if we can mould it into something usable. Since the impact seems to go beyond figuring out why execvp failed, I'm probably going to need some help. For now, I'll go through your suggestions and see what it produces. We'll go from there. Thanks for the heads-up. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html