From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#33050: 27.0.50; [macOS] Problem with process input with process-connection-type nil Date: Fri, 26 Oct 2018 10:00:31 +0300 Message-ID: <83sh0tp4z4.fsf@gnu.org> References: <83a7n9udxv.fsf@gnu.org> <83ftwuq9ii.fsf@gnu.org> <83a7n2q6jb.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1540537285 932 195.159.176.226 (26 Oct 2018 07:01:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 Oct 2018 07:01:25 +0000 (UTC) Cc: 33050@debbugs.gnu.org, fgunbin@fastmail.fm, alan@idiocy.org To: Thomas Fitzsimmons Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 26 09:01:21 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 1gFw7U-000083-TQ for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Oct 2018 09:01:21 +0200 Original-Received: from localhost ([::1]:58434 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFw9b-0007fx-8p for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Oct 2018 03:03:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFw8D-0005pz-4b for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 03:02:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFw89-0004gH-Tj for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 03:02:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38866) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gFw89-0004gA-PH for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 03:02:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gFw89-0007jd-Ly for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 03:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Oct 2018 07:02:01 +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.154053729029678 (code B ref 33050); Fri, 26 Oct 2018 07:02:01 +0000 Original-Received: (at 33050) by debbugs.gnu.org; 26 Oct 2018 07:01:30 +0000 Original-Received: from localhost ([127.0.0.1]:43124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFw7e-0007ib-1m for submit@debbugs.gnu.org; Fri, 26 Oct 2018 03:01:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFw7b-0007iJ-Uf for 33050@debbugs.gnu.org; Fri, 26 Oct 2018 03:01:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFw7R-0004Br-LY for 33050@debbugs.gnu.org; Fri, 26 Oct 2018 03:01:20 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFw6h-0003pY-Lv; Fri, 26 Oct 2018 03:00:31 -0400 Original-Received: from [176.228.60.248] (port=2738 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gFw6h-0005wZ-7m; Fri, 26 Oct 2018 03:00:31 -0400 In-reply-to: (message from Thomas Fitzsimmons on Thu, 25 Oct 2018 21:41:34 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:151633 Archived-At: > From: Thomas Fitzsimmons > Cc: Filipp Gunbin , 33050@debbugs.gnu.org, alan@idiocy.org > Date: Thu, 25 Oct 2018 21:41:34 -0400 > > > I don't understand why: using nil process-connection-type for programs > > that prompt the user is a bug anyway. > > I'm interested to know why you think this is a bug (or even not > preferable) in the specific case of ldap.el. When ldap.el calls > ldapsearch, ldapsearch doesn't prompt the user for the password > directly. ldap.el (having pre-read the password into Elisp by various > means) runs the command, and, in response to its prompt, sends it the > password. First, I must apologize in advance: I might be mis-interpreting the situation, because I don't use ldap.el or ldapsearch. In that case, what I said before and what I say below might not make sense. That said, my rationale was simple: _any_ program that interacts with the user will generally behave better when connected through pty than when connected through a pipe, because the former looks and feels as a terminal, and thus will cause the program to use the appropriate buffering, will support terminal-only features like various escape sequences, cursor control, job control, etc. Using pipes will probably work in most cases, but might fail in some of them, so good engineering tells us to prefer pty's, like the ELisp manual says. > I re-read the Elisp "Asynchronous Processes" node; when I was deciding > how to set process-connection-type, I think I was following the > _underlined_ part in: > > [...] If available, ptys are usually preferable for processes visible > to the user, as in Shell mode, because they allow for job control > (‘C-c’, ‘C-z’, etc.) between the process and its children, and > because interactive programs treat ptys as terminal devices, whereas > pipes don’t support these features. However, _for subprocesses used > by Lisp programs for internal purposes, it is often better to use a > pipe_, because pipes are more efficient, and because they are immune > to stray character injections that ptys introduce for large (around > 500 byte) messages. Also, the total number of ptys is limited on > many systems and it is good not to waste them. > > Given that ldapsearch can operate over a pipe (i.e., doesn't need > terminal features, seems to be unaffected by buffering), and is used for > internal purposes (i.e., is not visible to the user) isn't pipe mode > preferable for the reasons given there? Not in my opinion, no. AFAIU, the efficiency considerations don't really apply here, since the amount of data exchanged is small (right?). All in all, I consider the "however" part above too vague to be useful (what exactly does "internal purposes" mean in this context?). I think it's even slightly misleading. I'll think about rewording it to make the point more clear and the decision easier. > But if ldap.el's current setting of process-connection-type really > is a flat out bug then the Elisp manual might need clarification or > stronger language about when not to set it to "pipe mode". Agreed.