Re: Redirecting standard output

[Lars Magne Ingebrigtsen]

I've started reading the code, and it doesn't look too harrowing to
do -- there's a possibility it might make the code simpler, because we'd
basically be able to factor out stdout/stderr handling into one helper
function instead of special-casing the stdout/stderr handling.  I think.

But looking at the code, I remembered `start-process', which doesn't
allow separating stderr at all, so I took a look at that function, too.
It's much simpler and cleaner than `call-process'.  `call-process' has a
fair bit of #ifdef for DOS and NT and Windows, while `start-process'
doesn't.  And even stranger is that if you give a 0 as the value for
`call-process', you get asynchronous behaviour, which is very much like
the behaviour that `start-process' provides.  (But without the
possibility of adding filters.)

So here's my question: What's the reason that `call-process' isn't just
a shim around `start-process'?

Hm...  oh!  process.c isn't compiled at all on MS-DOS?  Hm.  Shame.  It
would have been nice if those two (very similar functionality-wise)
functions could have been merged somehow...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/