[Top][All Lists]

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

bug#33050: 27.0.50; [macOS] Problem with process input with process-conn

From: Filipp Gunbin
Subject: bug#33050: 27.0.50; [macOS] Problem with process input with process-connection-type nil
Date: Mon, 22 Oct 2018 18:35:43 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (darwin)

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

>> From: Filipp Gunbin <address@hidden>
>> 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 

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.


reply via email to

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