On Fri, 2008-08-22 at 01:49 +0200, [EMAIL PROTECTED] wrote:
> Hi,
>
> On Tue, Aug 19, 2008 at 11:29:28PM -0700, Thomas Bushnell BSG wrote:
> > On Fri, 2008-08-01 at 21:18 +0100, Samuel Thibault wrote:
>
> > > I'd agree on the principle to not leave a nul port for stdin/stdout,
> > > any other opi
> Well, I'm not sure I entirely understand what is being discussed here;
> so pardon me if this is a stupid notion: Is there some fundamental
> reason why (active) translators couldn't actually get real stdin/stdout
> from the settrans?...
For settrans -a, they do. It's great for active debugging
Hi,
On Tue, Aug 19, 2008 at 11:29:28PM -0700, Thomas Bushnell BSG wrote:
> On Fri, 2008-08-01 at 21:18 +0100, Samuel Thibault wrote:
> > I'd agree on the principle to not leave a nul port for stdin/stdout,
> > any other opinion on this?
>
> I disagree. Translators don't have such ports, and mak
On Fri, 2008-08-01 at 21:18 +0100, Samuel Thibault wrote:
> Hello,
>
> I'd agree on the principle to not leave a nul port for stdin/stdout,
> any other opinion on this?
I disagree. Translators don't have such ports, and making them null
encourages programs to write on them, possibly expecting th
> I'd agree on the principle to not leave a nul port for stdin/stdout,
> any other opinion on this?
I don't think this is good "on principle". If there is a principle, it's
that programs should be robust and not assume anything stupid like that fds
0,1 are already open if that's not part of the c
Hello,
I'd agree on the principle to not leave a nul port for stdin/stdout,
any other opinion on this?
Samuel
Hi,
This patches changes the available file descriptors when starting
translator processes. It keeps stdin and stdout open, both pointing to
/dev/null.
This patch has the side effect of fixing the strange behavior of CLISP
when starting Lisp translators (it goes into a stack overflow with
stdin an
