From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
To: Filipp Gunbin <fgunbin@fastmail.fm>
Cc: 33050@debbugs.gnu.org
Subject: bug#33050: 27.0.50; [macOS] Problem with process input with process-connection-type nil
Date: Mon, 22 Oct 2018 21:53:00 -0400 [thread overview]
Message-ID: <m3d0s1h1j7.fsf@fitzsim.org> (raw)
In-Reply-To: <m2h8he3sfk.fsf@fgunbin.playteam.ru> (Filipp Gunbin's message of "Mon, 22 Oct 2018 18:35:43 +0300")
Filipp Gunbin <fgunbin@fastmail.fm> writes:
> On 20/10/2018 13:09 +0300, Eli Zaretskii wrote:
>
>>> From: Filipp Gunbin <fgunbin@fastmail.fm>
>>> 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.
The overall change was to send the password to ldapsearch -W via a pipe
instead of in the clear on the command line (which made it visible to
other users e.g., in ps output).
As for that specific line, I may have copied it from another part of
Emacs that reads a password via a pipe; when I look now at other places
that bind this variable to nil, I see comments like this one in
lisp/gnus/nntp.el:
;; A non-nil connection type results in mightily odd behavior where
;; (process-send-string proc "\^M") ends up sending a "\n" to the
;; ssh process. --Stef
;; Also a nil connection allow ssh-askpass to work under X11.
(let ((process-connection-type nil))
(apply 'start-process "nntpd" buffer command))
Today I tested my setup (x86_64 GNU/Linux, OpenLDAP ldapsearch 2.4.40)
without setting process-connection-type to nil, and it still works. The
documentation for that variable says that the fallback is to use a pipe
if all ptys are busy in which case I guess this would still fail for
you.
Your test case behaves the same way for me on x86_64 GNU/Linux.
Maybe our ldapsearch commands are behaving differently. What version of
ldapsearch are you using?
Thomas
next prev parent reply other threads:[~2018-10-23 1:53 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-15 19:03 bug#33050: 27.0.50; [macOS] Problem with process input with process-connection-type nil Filipp Gunbin
2018-10-20 10:09 ` Eli Zaretskii
2018-10-22 15:35 ` Filipp Gunbin
2018-10-23 1:53 ` Thomas Fitzsimmons [this message]
2018-10-23 22:41 ` Filipp Gunbin
2018-10-24 1:55 ` Thomas Fitzsimmons
2018-10-24 13:13 ` Filipp Gunbin
2018-10-24 14:05 ` Filipp Gunbin
2018-10-24 16:20 ` Thomas Fitzsimmons
2018-10-24 19:33 ` Filipp Gunbin
2018-10-24 19:46 ` Filipp Gunbin
2018-10-24 22:07 ` Thomas Fitzsimmons
2018-10-25 15:51 ` Filipp Gunbin
2018-10-25 16:24 ` Eli Zaretskii
2018-10-25 17:10 ` Filipp Gunbin
2018-10-25 17:29 ` Eli Zaretskii
2018-10-25 18:10 ` Filipp Gunbin
2018-10-25 18:20 ` Eli Zaretskii
2018-10-25 19:36 ` Filipp Gunbin
2018-10-25 19:40 ` Eli Zaretskii
2018-10-25 20:47 ` Filipp Gunbin
2018-10-26 6:29 ` Eli Zaretskii
2018-10-26 1:41 ` Thomas Fitzsimmons
2018-10-26 7:00 ` Eli Zaretskii
2018-10-26 15:41 ` Thomas Fitzsimmons
2018-10-26 17:20 ` Eli Zaretskii
2018-10-27 10:20 ` Eli Zaretskii
2018-10-27 13:42 ` Thomas Fitzsimmons
2018-10-27 14:53 ` Eli Zaretskii
2018-10-27 16:53 ` Thomas Fitzsimmons
2018-10-27 18:49 ` Eli Zaretskii
2018-10-26 23:12 ` Filipp Gunbin
2018-10-27 2:09 ` Thomas Fitzsimmons
2018-10-27 14:52 ` Filipp Gunbin
2018-10-30 0:49 ` Thomas Fitzsimmons
2018-10-30 19:11 ` Filipp Gunbin
2018-11-28 23:09 ` Filipp Gunbin
2018-11-29 7:21 ` Eli Zaretskii
2018-11-29 8:46 ` Filipp Gunbin
2018-11-29 9:19 ` Eli Zaretskii
2018-11-29 9:51 ` Filipp Gunbin
2018-11-29 10:41 ` Eli Zaretskii
2018-11-29 14:09 ` Filipp Gunbin
2018-12-03 14:17 ` Thomas Fitzsimmons
2018-12-04 12:37 ` Filipp Gunbin
2018-12-22 15:05 ` Thomas Fitzsimmons
2018-10-27 6:59 ` Eli Zaretskii
2018-10-27 14:37 ` Filipp Gunbin
2018-10-27 20:28 ` Charles A. Roelli
2018-10-28 16:00 ` Eli Zaretskii
2018-10-28 19:53 ` Charles A. Roelli
2018-10-25 16:41 ` Filipp Gunbin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3d0s1h1j7.fsf@fitzsim.org \
--to=fitzsim@fitzsim.org \
--cc=33050@debbugs.gnu.org \
--cc=fgunbin@fastmail.fm \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).