bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17246: grep-2.19 planning


From: Eli Zaretskii
Subject: bug#17246: grep-2.19 planning
Date: Thu, 15 May 2014 22:33:32 +0300

> Date: Wed, 14 May 2014 11:34:34 -0700
> From: Paul Eggert <address@hidden>
> Cc: address@hidden
> 
> On 05/14/2014 10:44 AM, address@hidden wrote:
> 
> > Except on platforms that don't*have*  execlp...
> 
> Gnulib maintains a list of portability issues for many POSIX functions.  
> None of the issues currently listed for execvp etc. seem like they'd be 
> much of a problem for practical grep usage.  Please see:
> 
> http://www.gnu.org/software/gnulib/manual/html_node/execvp.html
> 
> If there are significant issues that Gnulib doesn't document, it'd be 
> nice to know what they are, as we should fix them in Gnulib and/or 
> describe them in the Gnulib documentation. This would benefit other GNU 
> applications.

Since I'm the source of the information Aharon tried to convey, I will
explain the issue.

I discovered this problem when testing the recently introduced Gawk
debugger facility, specifically the 'restart' command, whose
implementation in Gawk is just this:

  /* restart --- restart the debugger */

  static void
  restart(bool run)
  {
          /* save state in the environment after serialization */
          serialize(BREAK);
          serialize(WATCH);
          serialize(DISPLAY);
          serialize(HISTORY);
          serialize(OPTION);

          /* tell the new process to restore state from the environment */
          setenv("DGAWK_RESTART", (run ? "true" : "false"), 1);

          /* close all open files */
          close_all();

          /* start a new process replacing the current process */
          execvp(d_argv[0], d_argv);

          /* execvp failed !!! */
          fprintf(out_fp, _("Failed to restart debugger"));
          exit(EXIT_FAILURE);
  }

On Windows, when execvp was called, the result was strange: it looked
like the parent shell from which the original Gawk process was
invoked, and the restarted Gawk were competing for keyboard input: one
in every 2 input lines went to Gawk, the other one to the shell.

I then looked into the sources of the Microsoft C runtime library
(which are available as part of installing some of their gratis
packages), and found that the implementation of the exec* family did
the following: it started the process that runs the child program, and
then immediately exited without waiting for the child to finish.  What
that did was return control to the parent shell, which then tried to
read console input, and also leave behind a child process that was now
orphan, but still connected to the console input.  So they both tried
to read the same console input, stomping on each other.

The solution was to reimplement execvp in a way that didn't exit to
the shell until the child program finished.  See pc/gawkmisc.pc in the
Gawk distribution.

Since Grep doesn't (AFAIK) read from console, I think this problem
doesn't affect Grep.  But since I learned the above, I don't trust
exec* functions on Windows and try not to use them at all, ever.

HTH





reply via email to

[Prev in Thread] Current Thread [Next in Thread]