From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Thomas Fitzsimmons Newsgroups: gmane.emacs.bugs 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 Message-ID: References: <83a7n9udxv.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1540259229 32080 195.159.176.226 (23 Oct 2018 01:47:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Oct 2018 01:47:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 33050@debbugs.gnu.org To: Filipp Gunbin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 23 03:47:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gElmi-0008FE-St for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Oct 2018 03:47:05 +0200 Original-Received: from localhost ([::1]:37631 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gElop-00049m-05 for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Oct 2018 21:49:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEloh-00047t-Sm for bug-gnu-emacs@gnu.org; Mon, 22 Oct 2018 21:49:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gEloc-0000FU-Jp for bug-gnu-emacs@gnu.org; Mon, 22 Oct 2018 21:49:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60581) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gEloc-0000FG-DW for bug-gnu-emacs@gnu.org; Mon, 22 Oct 2018 21:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gEloc-0003yY-AB for bug-gnu-emacs@gnu.org; Mon, 22 Oct 2018 21:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Thomas Fitzsimmons Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Oct 2018 01:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33050 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33050-submit@debbugs.gnu.org id=B33050.154025933415254 (code B ref 33050); Tue, 23 Oct 2018 01:49:02 +0000 Original-Received: (at 33050) by debbugs.gnu.org; 23 Oct 2018 01:48:54 +0000 Original-Received: from localhost ([127.0.0.1]:36603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEloU-0003xy-Dj for submit@debbugs.gnu.org; Mon, 22 Oct 2018 21:48:54 -0400 Original-Received: from mail-io1-f46.google.com ([209.85.166.46]:42899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEloS-0003xb-Hi for 33050@debbugs.gnu.org; Mon, 22 Oct 2018 21:48:52 -0400 Original-Received: by mail-io1-f46.google.com with SMTP id n18-v6so28276679ioa.9 for <33050@debbugs.gnu.org>; Mon, 22 Oct 2018 18:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fitzsim-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=+7/X1zonYOYJsWwJISdRTRGl+YmqCtJKyLgxV+wBdZA=; b=AnUZY+6N9E8OCwnRS6/br7H356dxURcLUxhtB3vMKBfQAVSc7rNh0l8Bj/blBb4Gx7 Sb2CFd7M2fws3YMuvRXFgc+pQ10HNafnRiE1eoFYIwVI1kapX5gvwARZa3UZsktuonUU 4mdwUA+7JPbi92/XE/oFb1B/u4xdTR7qALG7qyfhW2uGpvZFNvYNwpa7tPJmO6GRQiTx K2Jnj65Pbyw5mtMRQCQwAYpnrrcK2hWFYFv5Nw3ADHuWGnMxBe1gv4PmdPH9osvLKLXH bG+4GE6bGppwkVCGPXH5Lm3z+dn0Gcj+nTUJp4q2Xp2TnotwqrqsdffUVhdjy4xmgLab Holw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=+7/X1zonYOYJsWwJISdRTRGl+YmqCtJKyLgxV+wBdZA=; b=bdUd1qsMrO6YaEgp+UjEmY3ZP+Zw/hqqVkJem8g0DMzj/+jewZUcTs9Yp4GHRtUCIs nJsqTv4V1kE7bdVHjCZZuKNO4azKLOeWuEtKltpiKKZf6AxDYKg2QDpF7ClG95l1o6Yw 8BlsMpgEBMBN/heifa9Cfiqkv3XZsyH8afSLkFXPbSjWB3rzyn81qe4M1c3RJSP0zGZS Cni1Mt+EsNYa4yzHX1CKEeezVuqRV3iwlqN5Sv8Gp01VcPlpKKiJsi8r1C8cojiB5+Os FJ7r/6L6Xp1UWSL+P9x87rQ5CouaRZl20tJ9xc8ULFl9cGYGu0oHjfHSkTuujDbSm4F3 zRPg== X-Gm-Message-State: AGRZ1gK3HcmjodbB/+wCwLDAyeCmNWqxbQRUAkiCih/L6o3M8X3uLzSh ZpyDr6ilBR3xBirC8YfRZVZiQZUnyss= X-Google-Smtp-Source: AJdET5dDo0LOoXHQ4hLiutPr5UzkOq0By2uRuWWT43ezbJKCV630T7UD5ncW5CNzEFJ9i38CsoLI4A== X-Received: by 2002:a6b:18c5:: with SMTP id 188-v6mr10273256ioy.211.1540259326829; Mon, 22 Oct 2018 18:48:46 -0700 (PDT) Original-Received: from localhost.localdomain (69-165-165-189.dsl.teksavvy.com. [69.165.165.189]) by smtp.gmail.com with ESMTPSA id a136-v6sm21004ita.6.2018.10.22.18.48.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Oct 2018 18:48:46 -0700 (PDT) In-Reply-To: (Filipp Gunbin's message of "Mon, 22 Oct 2018 18:35:43 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:151511 Archived-At: Filipp Gunbin writes: > On 20/10/2018 13:09 +0300, Eli Zaretskii wrote: > >>> From: Filipp Gunbin >>> 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