emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS: Win64 testers?


From: Eli Zaretskii
Subject: Re: MPS: Win64 testers?
Date: Fri, 09 Aug 2024 09:10:07 +0300

> Date: Fri, 09 Aug 2024 09:00:11 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org, pipcet@protonmail.com
> 
> > From: Quang Kien Nguyen <kien.n.quang@gmail.com>
> > Date: Thu, 8 Aug 2024 16:44:09 -0700
> > Cc: emacs-devel@gnu.org, pipcet@protonmail.com
> > 
> > > What ProcExp64 shows is a good sign, but I'd prefer to test also some
> > > redirection like above, with Emacs and the sub-process both writing to
> > > the same stdout/stderr stream, which would allow to verify positively
> > > that they write to different places.
> > 
> > Okay, I have tested with this lisp exp:
> >     (print 10 #'external-debugging-output)
> > 
> > 10 is printed in the stdout/stderr on the console.
> > 
> > Then try again with
> >     (start-process-shell-command "test" nil "emacs -Q --batch --eval
> > \"(print 123123 #'external-debugging-output)\"")
> > 
> > The child emacs process is spinned up but nothing is spewed to the
> > current console
> > output.  Does that correct and prove that they don't share the handle?
> 
> Not clearly enough.  Consoles are tricky on Windows.  It is better to
> start Emacs with stderr redirected to a file (I've shown how to do
> that in a previous message), and then see that what the child Emacs
> writes to external-debugging-output does not appear in that file.
> 
> Also, instead of start-process please use call-process.  That's
> because start-process redirects the stdout/stderr handles of the child
> process to the pipe from which the parent Emacs process reads, and
> that makes the experiment more complex and harder to reason about.

And one more thing: when using "emacs --batch", it is easier to use
'message' to write to stderr; no need to 'print' via
external-debugging-output.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]