Re: readpipe patch again

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 06 May 2002 16:27:21 +0200
> 
> It must remain possible, at least for debugging, to bison to save
> this file.

I was thinking of changing bison --trace.  Instead of outputting
something like this:

   running: /opt/sfw/bin/gm4 -I /usr/local/share/bison m4sugar/m4sugar.m4 
/tmp/bsnfdaicA bison.simple

and leaving behind a file /tmp/bsnfdaicA, it could output this instead:

   running the following shell command:
   /opt/sfw/bin/gm4 -I /usr/local/share/bison m4sugar/m4sugar.m4 - bison.simple 
<<'m4_EOF'
   [copy of m4 input goes here]
   m4_EOF

The output of --trace is already pretty verbose, so it shouldn't hurt
much to make it more verbose.  It would add about 25% to the size of
the trace output for Bash's parse.y, for example.


> From: Florian Krohm <address@hidden>
> Date: Mon, 6 May 2002 10:08:04 -0400
> 
> Unless someone objects here, I will change the patch to do what you 
> described on systems that have a working fork.

But this won't fix the problem on systems that lack 'fork'.  The only
fix that I can see is a relatively complicated one involving the
introduction of signal handling.  I'm not sure it's worth the
aggravation of maintaining this different method for hosts that lack
fork.

> I adopted what I saw in diffutils (diff3.c) assuming that what I saw
> there was The Right Thing.

diff3.c doesn't need to create any temporary files, so a better model
is sdiff.c, which communicates temp files to an interactive editor;
that is why sdiff.c is more complicated here.  If Bison needed to
communicate with an editor, it would probably have to do something
like what sdiff.c does.  But I don't think Bison needs to.

> is this something that should be brought up with the 
> people who write the GNU coding standards?

It's already addressed there, in the node "Portability between System Types":

   As for systems that are not like Unix, such as MSDOS, Windows, the
   Macintosh, VMS, and MVS, supporting them is often a lot of work.  When
   that is the case, it is better to spend your time adding features that
   will be useful on GNU and GNU/Linux, rather than on supporting other
   incompatible systems.

Given the problems discussed above, I'm inclined to not bother to
support hosts that lack "fork".  If someone volunteers to write
support for it, and if that support doesn't clutter up the mainline
code, then we can add it.  That is what happened with diffutils, a
long time ago.  In the case of sdiff.c it didn't clutter things up too
much since sdiff already needed to mess with signals.  But Bison
doesn't need to worry about signals so the tradeoffs are different
here.