Re: Problems with call-process (= identifying run-python issues)

[Eli Zaretskii <eliz@gnu.org>]

> From: Juan José García-Ripoll
>  <juanjose.garciaripoll@gmail.com>
> Date: Wed, 19 Aug 2020 10:59:39 +0200
> 
> Ok, let me please explain the problem: I want to run a process that gets
> its input from a file, while Emacs collects its output. This is standard
> working in many programming modes. For instance, it is the way
> run-python calls python to find out the prompt.
> 
> I am finding that when I launch Emacs from the windowing environment
> (e.g. shortcuts, Start menu, Windows key + R, explorer), Emacs does not
> redirect the input of the subprocess properly. If I launch the Emacs
> from the command line, the subprocess works as expected. 
> 
> To reproduce this I have created a minimal example:
> 
> - A bogus input file (foo), that is going to be the redirected input of our
> program
> 
> - A script, chain.cmd that copies all input to its output, line by
> line. This is going to be the subprocess. Unfortunately, Windows does
> not have a 'cat' command, which is why I did it this way.
> 
> - An elisp file (test.el) that launches the process with the redirected
> input and collects the output
> 
> This example can be ran in three different ways:
> 
> - Invoking runemacs.exe -Q --load test.el from the command line
> - Running the same command with Windows key + R
> - Creating a shortcut that does the same.
> 
> All ingredients are needed, because we need a reproducible program, an
> input file and some sophisticated commands that use Emacs'
> call-process. However, it is *not* complicated at all and everything is
> pretty standard.

OK, thanks.

I have now tried this on 2 different Windows systems, one of them
Windows 10, and I cannot reproduce what you describe.   No matter how
I invoke Emacs, I get the expected output in the buffer: the contents
of the file passed as standard input to the subprocess.

So I think either this is due to some local configuration issue on
your system, or there's some part of the reproduction recipe that you
omitted.

> One consequence of this problem is that run-python does not work as
> expected (Emacs fails to find the prompt), but as I try to show, this is
> not due to Python.

Working with Python on Windows has its quirks, because you need to
make sure Python uses unbuffered writes to its standard output.  That
is why I wanted to be sure Python is not involved here.