Re: [Bug-gnulib] addition: pipe.h, pipe-in.c, pipe-out.c, pipe-bidi.c

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> The point of gnulib as a portability library is to make it work on systems
> which don't have the POSIX primitives.

I'd say that the main point of gnulib is more to provide commonly used
and needed functionality.  Portability to non-POSIX systems is nice if
it's very easy to add, but it's not a main goal.

I think part of my problem with the proposed 'pipe' module is
basically that it takes the Windows model, since that can be
implemented efficiently on both Windows and POSIX.  I'd rather not
have to worry about the Windows model.  (That's why I'm not using the
'execute' module either.)  If porting to Windows is any real work then
I don't want any part of it: it's not the goal of the GNU project and
I don't want to distract myself with irrelevancies.

Gnulib code is code that I regularly have to look at while
maintaining.  I realize that some people want to work on Windows ports
and nothing else, but I'd rather have any such Windows-specific code
be maintained "somewhere else", where I don't have to look at it.
That's how I do it with diffutils, for example: the Windows stuff is
almost all in a 'pc' subdirectory, which others can deal with.


Now, Bison does this:

  int fd[2];
  pid_t pid = create_subpipe (argv, fd);
  ... write everything to fd[0] ...
  ... read everything from fd[1] ...
  reap_subpipe (pid, argv[0]);

create_subpipe is about 50 lines of code, and reap_subpipe is about 20
lines, and they're pretty easy to follow.  I don't see the need to
replace them with something more complicated.

Not that I'm saying that the Bison pipe code is perfect for everybody!
It's fine for Bison but I don't know of any other code that needs it.
That's why I haven't proposed that code for gnulib, even though it's
stable, been used for some time, etc.


> > So (as they say in business :-) who's the customer, other than gettext
> > itself?
> 
> Anything else that needs to run a subprocess and communicate with it.

How about if we wait for two different maintainers to use the pipe
module first, before putting it into gnulib?  I don't much see the
point of having this module in gnulib if only one maintainer is likely
to use it.