threads / patch / 30713

patchpager: drop "wait for output to run less" hack

Subject: [PATCH] pager: drop "wait for output to run less" hack

## tl;dr

8 messages between Jun 5, 2012 and Jun 5, 2012. Diffs are folded; open one to read it.

replies: 7people: 3as markdown or json

Jeff King· Jun 5, 2012, 08:56 UTC · lore
On Tue, Jun 05, 2012 at 02:56:28AM -0400, Jeff King wrote:
Show 15 quoted lines
> > +static int fd_to_close;
> > +void close_fd_prexec_cb(void)
> > +{
> > +	if(debug)
> > +		fprintf(stderr, "close_fd_prexec_cb closing %d\n", fd_to_close);
> > +	close(fd_to_close);
> > +}
> 
> Note that preexec_cb does not work at all on Windows, as it assumes a
> forking model (rather than a spawn, which leaves no room to execute
> arbitrary code in the child). If all you want to do is open an extra
> pipe, then probably run-command should be extended to handle this
> (though I have no idea how complex that would be for the Windows side of
> things, it is at least _possible_, as opposed to preexec_cb, which will
> never be possible).
I'm really tempted to do this:

-- >8 -- Commit 35ce862 (pager: Work around window resizing bug in 'less', 2007-01-24) causes git's pager sub-process to wait to receive input after forking but before exec-ing the pager. To handle this, run-command had to grow a "pre-exec callback" feature. Unfortunately, this feature does not work at all on Windows (where we do not fork), and interacts poorly with run-command's parent notification system. Its use should be discouraged.

The bug in less was fixed in version 406, which was released in June 2007. It is probably safe at this point to remove our workaround. That lets us rip out the preexec_cb feature entirely.

Signed-off-by: Jeff King <peff@peff.net>
---
I checked, and even RHEL5 is on less 436. So besides people on antique
"I installed less from source more than 5 years ago" systems, my only
concern would be that some other pager depends on this hack in a weird
way. But I have never heard of such a thing, so...
 pager.c       | 18 ------------------
 run-command.c | 10 ----------
 run-command.h |  1 -
 3 files changed, 29 deletions(-)
Show changes to 3 files +0 −29

pager.c, run-command.c, run-command.h

diff --git a/pager.c b/pager.c
index 4dcb08d..c0b4387 100644
--- a/pager.c
+++ b/pager.c
@@ -11,21 +11,6 @@
  * something different on Windows.
  */
 
-#ifndef WIN32
-static void pager_preexec(void)
-{
-	/*
-	 * Work around bug in "less" by not starting it until we
-	 * have real input
-	 */
-	fd_set in;
-
-	FD_ZERO(&in);
-	FD_SET(0, &in);
-	select(1, &in, NULL, &in, NULL);
-}
-#endif
-
 static const char *pager_argv[] = { NULL, NULL };
 static struct child_process pager_process;
 
@@ -93,9 +78,6 @@ void setup_pager(void)
 		static const char *env[] = { "LESS=FRSX", NULL };
 		pager_process.env = env;
 	}
-#ifndef WIN32
-	pager_process.preexec_cb = pager_preexec;
-#endif
 	if (start_command(&pager_process))
 		return;
 
diff --git a/run-command.c b/run-command.c
index 606791d..dff28a7 100644
--- a/run-command.c
+++ b/run-command.c
@@ -394,16 +394,6 @@ fail_pipe:
 					unsetenv(*cmd->env);
 			}
 		}
-		if (cmd->preexec_cb) {
-			/*
-			 * We cannot predict what the pre-exec callback does.
-			 * Forgo parent notification.
-			 */
-			close(child_notifier);
-			child_notifier = -1;
-
-			cmd->preexec_cb();
-		}
 		if (cmd->git_cmd) {
 			execv_git_cmd(cmd->argv);
 		} else if (cmd->use_shell) {
diff --git a/run-command.h b/run-command.h
index 44f7d2b..850c638 100644
--- a/run-command.h
+++ b/run-command.h
@@ -39,7 +39,6 @@ struct child_process {
 	unsigned stdout_to_stderr:1;
 	unsigned use_shell:1;
 	unsigned clean_on_exit:1;
-	void (*preexec_cb)(void);
 };
 
 int start_command(struct child_process *);
-- 
1.7.11.rc1.3.gf8b4f5c

Reply-To: 
In-Reply-To: <20120605065628.GA25809@sigill.intra.peff.net>
Junio C Hamano· Jun 5, 2012, 15:42 UTC · re: Jeff King · lore

Re: [PATCH] pager: drop "wait for output to run less" hack

Jeff King <peff@peff.net> writes:
Show 19 quoted lines
> On Tue, Jun 05, 2012 at 02:56:28AM -0400, Jeff King wrote:
>
>> > +static int fd_to_close;
>> > +void close_fd_prexec_cb(void)
>> > +{
>> > +	if(debug)
>> > +		fprintf(stderr, "close_fd_prexec_cb closing %d\n", fd_to_close);
>> > +	close(fd_to_close);
>> > +}
>> 
>> Note that preexec_cb does not work at all on Windows, as it assumes a
>> forking model (rather than a spawn, which leaves no room to execute
>> arbitrary code in the child). If all you want to do is open an extra
>> pipe, then probably run-command should be extended to handle this
>> (though I have no idea how complex that would be for the Windows side of
>> things, it is at least _possible_, as opposed to preexec_cb, which will
>> never be possible).
>
> I'm really tempted to do this:
Why (I am slower than my usual slow self today, so pardon me)?
Aren't these already protected with "ifndef WIN32"?
Show 15 quoted lines
>
> -- >8 --
> Commit 35ce862 (pager: Work around window resizing bug in
> 'less', 2007-01-24) causes git's pager sub-process to wait
> to receive input after forking but before exec-ing the
> pager. To handle this, run-command had to grow a "pre-exec
> callback" feature. Unfortunately, this feature does not work
> at all on Windows (where we do not fork), and interacts
> poorly with run-command's parent notification system. Its
> use should be discouraged.
>
> The bug in less was fixed in version 406, which was released
> in June 2007. It is probably safe at this point to remove
> our workaround. That lets us rip out the preexec_cb feature
> entirely.
Ah, OK.
Show 7 quoted lines
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I checked, and even RHEL5 is on less 436. So besides people on antique
> "I installed less from source more than 5 years ago" systems, my only
> concern would be that some other pager depends on this hack in a weird
> way. But I have never heard of such a thing, so...
Hrm...
Show 74 quoted lines
>  pager.c       | 18 ------------------
>  run-command.c | 10 ----------
>  run-command.h |  1 -
>  3 files changed, 29 deletions(-)
>
> diff --git a/pager.c b/pager.c
> index 4dcb08d..c0b4387 100644
> --- a/pager.c
> +++ b/pager.c
> @@ -11,21 +11,6 @@
>   * something different on Windows.
>   */
>  
> -#ifndef WIN32
> -static void pager_preexec(void)
> -{
> -	/*
> -	 * Work around bug in "less" by not starting it until we
> -	 * have real input
> -	 */
> -	fd_set in;
> -
> -	FD_ZERO(&in);
> -	FD_SET(0, &in);
> -	select(1, &in, NULL, &in, NULL);
> -}
> -#endif
> -
>  static const char *pager_argv[] = { NULL, NULL };
>  static struct child_process pager_process;
>  
> @@ -93,9 +78,6 @@ void setup_pager(void)
>  		static const char *env[] = { "LESS=FRSX", NULL };
>  		pager_process.env = env;
>  	}
> -#ifndef WIN32
> -	pager_process.preexec_cb = pager_preexec;
> -#endif
>  	if (start_command(&pager_process))
>  		return;
>  
> diff --git a/run-command.c b/run-command.c
> index 606791d..dff28a7 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -394,16 +394,6 @@ fail_pipe:
>  					unsetenv(*cmd->env);
>  			}
>  		}
> -		if (cmd->preexec_cb) {
> -			/*
> -			 * We cannot predict what the pre-exec callback does.
> -			 * Forgo parent notification.
> -			 */
> -			close(child_notifier);
> -			child_notifier = -1;
> -
> -			cmd->preexec_cb();
> -		}
>  		if (cmd->git_cmd) {
>  			execv_git_cmd(cmd->argv);
>  		} else if (cmd->use_shell) {
> diff --git a/run-command.h b/run-command.h
> index 44f7d2b..850c638 100644
> --- a/run-command.h
> +++ b/run-command.h
> @@ -39,7 +39,6 @@ struct child_process {
>  	unsigned stdout_to_stderr:1;
>  	unsigned use_shell:1;
>  	unsigned clean_on_exit:1;
> -	void (*preexec_cb)(void);
>  };
>  
>  int start_command(struct child_process *);
Jeff King· Jun 5, 2012, 15:50 UTC · re: Junio C Hamano · lore

Re: [PATCH] pager: drop "wait for output to run less" hack

On Tue, Jun 05, 2012 at 08:42:14AM -0700, Junio C Hamano wrote:
> > I'm really tempted to do this:
> 
> Why (I am slower than my usual slow self today, so pardon me)?

Purely to clean up the nasty preexec thing, which is a hack, and should never be used for new code due to portability issues.

> Aren't these already protected with "ifndef WIN32"?
Yes, but it means anything that uses it will not work on Windows.
Show 6 quoted lines
> > I checked, and even RHEL5 is on less 436. So besides people on antique
> > "I installed less from source more than 5 years ago" systems, my only
> > concern would be that some other pager depends on this hack in a weird
> > way. But I have never heard of such a thing, so...
> 
> Hrm...

Yeah. This is purely a cleanup thing. It's a cleanup I've wanted to do for a long time (ever since adding it), but it is not hurting anyone as-is. We can always just reject new uses of preexec_cb in review (which is more or less what I'm doing here).

-Peff
Erik Faye-Lund· Jun 5, 2012, 15:52 UTC · re: Jeff King · lore

Re: [PATCH] pager: drop "wait for output to run less" hack

On Tue, Jun 5, 2012 at 10:56 AM, Jeff King <peff@peff.net> wrote:
> I checked, and even RHEL5 is on less 436. So besides people on antique
> "I installed less from source more than 5 years ago" systems, my only
> concern would be that some other pager depends on this hack in a weird
> way. But I have never heard of such a thing, so...

On my RHEL5 box at work: $ less --version less 394 Copyright (C) 1984-2005 Mark Nudelman

Jeff King· Jun 5, 2012, 16:01 UTC · re: Erik Faye-Lund · lore

Re: [PATCH] pager: drop "wait for output to run less" hack

On Tue, Jun 05, 2012 at 05:52:24PM +0200, Erik Faye-Lund wrote:
Show 10 quoted lines
> On Tue, Jun 5, 2012 at 10:56 AM, Jeff King <peff@peff.net> wrote:
> > I checked, and even RHEL5 is on less 436. So besides people on antique
> > "I installed less from source more than 5 years ago" systems, my only
> > concern would be that some other pager depends on this hack in a weird
> > way. But I have never heard of such a thing, so...
> 
> On my RHEL5 box at work:
> $ less --version
> less 394
> Copyright (C) 1984-2005 Mark Nudelman

Then I think you are not following the bug-fix updates, as they've issued several updates based on 436:

  https://rhn.redhat.com/errata/RHBA-2010-0214.html
  https://rhn.redhat.com/errata/RHBA-2010-0805.html
  http://rhn.redhat.com/errata/RHBA-2011-1468.html
Looks like 394 was shipping as recently as 2009:
  https://rhn.redhat.com/errata/RHBA-2009-0413.html

Given that the buggy less is apparently still in the wild, and that the patch is a pure cleanup, I guess we should scrap it for now. <sigh>

-Peff
Junio C Hamano· Jun 5, 2012, 16:36 UTC · re: Jeff King · lore

Re: [PATCH] pager: drop "wait for output to run less" hack

Jeff King <peff@peff.net> writes:
> Given that the buggy less is apparently still in the wild, and that the
> patch is a pure cleanup, I guess we should scrap it for now. <sigh>

Let's keep it on hold for six more months and then re-evaluate the situation, perhaps?

Jeff King· Jun 5, 2012, 16:45 UTC · re: Junio C Hamano · lore

Re: [PATCH] pager: drop "wait for output to run less" hack

On Tue, Jun 05, 2012 at 09:36:36AM -0700, Junio C Hamano wrote:
Show 7 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > Given that the buggy less is apparently still in the wild, and that the
> > patch is a pure cleanup, I guess we should scrap it for now. <sigh>
> 
> Let's keep it on hold for six more months and then re-evaluate the
> situation, perhaps?
Sure. I'll carry it in my local tree for now.
-Peff
Erik Faye-Lund· Jun 5, 2012, 23:09 UTC · re: Jeff King · lore

Re: [PATCH] pager: drop "wait for output to run less" hack

On Tue, Jun 5, 2012 at 6:01 PM, Jeff King <peff@peff.net> wrote:
Show 16 quoted lines
> On Tue, Jun 05, 2012 at 05:52:24PM +0200, Erik Faye-Lund wrote:
>
>> On Tue, Jun 5, 2012 at 10:56 AM, Jeff King <peff@peff.net> wrote:
>> > I checked, and even RHEL5 is on less 436. So besides people on antique
>> > "I installed less from source more than 5 years ago" systems, my only
>> > concern would be that some other pager depends on this hack in a weird
>> > way. But I have never heard of such a thing, so...
>>
>> On my RHEL5 box at work:
>> $ less --version
>> less 394
>> Copyright (C) 1984-2005 Mark Nudelman
>
> Then I think you are not following the bug-fix updates, as they've
> issued several updates based on 436:
>

I don't know what exactly the setup is, other than that it's set up to match the RHEL5 setup of a major customer with a very conservative upgrade policy.

← back to recent threads