Re: readpipe patch again

[Akim Demaille]

| 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

Why not, indeed.

| The output of --trace is already pretty verbose, so it shouldn't hurt
| much to make it more verbose.  

At some point, having a means to tune the kind of traces wanted will
be needed.  There is already some items that are too big for real
grammars.


| 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.

There's another thing I'm afraid of: seeing mini forks of Bison.  But
I agree when should move forward and offer the possibility to DOS
users to provide an alternative that does not pollute the core code.


| 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.

Not yet ;)


| Given the problems discussed above, I'm inclined to not bother to
| support hosts that lack "fork".

Eek.

| 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.

You had me convinced.