(+cc: Jeff because mentioning a pagination side-issue [*]) Frans Klaver 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. 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. 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. I want to like (b), but the downside seems unacceptable. 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. -- 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