Subject: Re: bug#33050: 27.0.50; [macOS] Problem with process input with process-connection-type nil

From: Filipp Gunbin <[email-masked]>
Date: Mon, 22 Oct 2018 18:35:43 +0300

On 20/10/2018 13:09 +0300, Eli Zaretskii wrote:

>> From: Filipp Gunbin <[email-masked]>
>> Date: Mon, 15 Oct 2018 22:03:19 +0300
>>
>> If I let-bind process-connection-type to t (use pty) in above code, then
>> it works normally:
>>
>> *Messages* :
>> proc status: run
>> found prompt
>> proc status: run
>> exited
>> "exited"
>>
>> Buffer "my-process-buf":
>> enter something:
>> Process my-process<2> finished
>>
>> But if I let-bind process-connection-type to nil (so does ldap.el), then
>> it hangs, and after a few seconds wait and C-g, *Messages* has only
>> this: "proc status: run [6 times]", and buffer my-process-buf is empty.
>
> The reason is almost certainly buffering: when the connection is via a
> pipe, the subprocess writes in buffered mode, so it might take quite a
> few characters of input before /usr/bin/read outputs something.  Try
> using the -n or -N options, and see if that helps.

Thanks for looking at this.
I tried wrapping read in stdbuf, but it didn't change anything:
(start-process "my-process" buf "stdbuf" "-o0" "/usr/bin/read" "-p" "enter something:")

read -n won't help either, because it can affect the number of chars
"read" reads - while in my example we are just waiting for prompt.

> Why does ldap.el set process-connection-type to nil?

I don't know, and it seems like it should not mingle with this setting
at all (why should it?)

I've CC'ed Thomas, who is the author of these lines (ldap.el line 649),
according to git blame.

Filipp