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: Fri, 26 Oct 2018 11:41:02 -0400 Message-ID: References: <83a7n9udxv.fsf@gnu.org> <83ftwuq9ii.fsf@gnu.org> <83a7n2q6jb.fsf@gnu.org> <83sh0tp4z4.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1540568644 15064 195.159.176.226 (26 Oct 2018 15:44:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 Oct 2018 15:44:04 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 33050@debbugs.gnu.org, fgunbin@fastmail.fm, alan@idiocy.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 26 17:44:00 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 1gG4HG-0003lD-Ty for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Oct 2018 17:43:59 +0200 Original-Received: from localhost ([::1]:60718 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gG4JM-0004cH-Tc for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Oct 2018 11:46:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gG4Iu-0003tV-3d for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 11:45:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gG4AY-0006tT-3R for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 11:37:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39996) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gG4AX-0006tN-UK for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 11:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gG4AX-0005Vm-SA for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 11:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Thomas Fitzsimmons Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Oct 2018 15:37: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.154056817521125 (code B ref 33050); Fri, 26 Oct 2018 15:37:01 +0000 Original-Received: (at 33050) by debbugs.gnu.org; 26 Oct 2018 15:36:15 +0000 Original-Received: from localhost ([127.0.0.1]:44254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gG49m-0005Ue-Qh for submit@debbugs.gnu.org; Fri, 26 Oct 2018 11:36:15 -0400 Original-Received: from mail-it1-f172.google.com ([209.85.166.172]:35430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gG49l-0005UR-01 for 33050@debbugs.gnu.org; Fri, 26 Oct 2018 11:36:13 -0400 Original-Received: by mail-it1-f172.google.com with SMTP id p64-v6so2188376itp.0 for <33050@debbugs.gnu.org>; Fri, 26 Oct 2018 08:36:12 -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:content-transfer-encoding; bh=6tdIgKSJsZDImL03TomxlM6hdBvS3oCOfqaCuDmQ/WU=; b=Ls3g33xl1HYdpG8pOgTGhLur0QIJd/h8VZ0aWH8RXqzH/+3Ww5oxWJxzTSC0DRbZ8d 5VKwtmVjacmCThHz5h9pzYqkMZeYu49iudFafuUQ1WVkfioxmIaZ3Q+kJLK7VffE8TST aiydPpfs6upPNLEdsRe+5rY7RzQnZGxv7rEB6AlYs3Rxq5q6d7TDDf+dKn428WUuCZeq qbtM8cChF0wVaG1gJCYiSWt1oYY3iH9WNVVLD93RtcwDhc9rSEDIKAsuy9nmCZedfgkG f3bpDqjYnpG1Ew8aDcJGKdtU+w5ex4QEViwSaF7ADOBytXowDAzJMkCZNz+xIHSYCRfj E7bw== 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:content-transfer-encoding; bh=6tdIgKSJsZDImL03TomxlM6hdBvS3oCOfqaCuDmQ/WU=; b=obent82YeXCpeMR+kD0Qrj8AI7v97/ZJ52h5euZ7xk3cAfww/E/RdFqSLEZwayqFRd fmv66141mTPp4389e+wLkhxItgZkgbL31fboZEra1D1NnoISCawq1ebnjPXQKudBGvC9 0+dr8VSypwLiyryBUB78dNujSHSU/xHcOeqhHvX2DFS6I6sCmsdFGP5eAuU/5v+BzzNE gnpvGLlF3hNk9rlZmIxn6+j1ixtGBCgwquzgkOib5nyj7dKLxES1APCKUWFpLzbwUx2l q3yUF7f0ZP6UAIAtSrunikSllnJc3wr4w/ZaGXG5mZX3ORK49MWHjMBp52jl8gmDULhp Rlpg== X-Gm-Message-State: AGRZ1gKW4G+S+aMIu76hab+PqUNIreQknGufJtjNpw/JceLqVqkr03QC A6KfQYKAFwXS9mYeJxLMWHn+3Q== X-Google-Smtp-Source: AJdET5fYsoF95U0OacZT0f/xagvW5WnvwsxyEPLdbZEkKwx/gWTHFxaxY4wPx08YEs4TghOP81tD/g== X-Received: by 2002:a24:d703:: with SMTP id y3-v6mr4294125itg.154.1540568167065; Fri, 26 Oct 2018 08:36:07 -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 d8sm2069869itk.38.2018.10.26.08.36.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Oct 2018 08:36:06 -0700 (PDT) In-Reply-To: <83sh0tp4z4.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Oct 2018 10:00:31 +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:151646 Archived-At: Eli Zaretskii writes: >> From: Thomas Fitzsimmons >> Cc: Filipp Gunbin , 33050@debbugs.gnu.org, alan@i= diocy.org >> Date: Thu, 25 Oct 2018 21:41:34 -0400 >>=20 >> > I don't understand why: using nil process-connection-type for programs >> > that prompt the user is a bug anyway. >>=20 >> 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. OK, this makes sense, thanks for providing the rationale. Given that ldapsearch does issue a human-readable prompt for the password, it was likely written and tested assuming a pty. >> 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: >>=20 >> [...] If available, ptys are usually preferable for processes visible >> to the user, as in Shell mode, because they allow for job control >> (=E2=80=98C-c=E2=80=99, =E2=80=98C-z=E2=80=99, etc.) between the proc= ess and its children, and >> because interactive programs treat ptys as terminal devices, whereas >> pipes don=E2=80=99t support these features. However, _for subprocess= es 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. >>=20 >> 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?). 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. OK, sounds good. One worry I have about always leaving process-connection-type t is that, depending on the external system state -- specifically whether or not all ptys are busy -- process-connection-type might not have any effect, and the underlying process will rarely (and silently AFAICT) operate in pipe mode. By forcing process-connection-type nil, one is always testing in the same known mode. That said, it is probably a bad idea to warn or signal an error if all ptys are busy in the p-c-t t case. Anyway, I thought I'd mention it; maybe the documentation update can address this point as well. How about I make the change conditional on Mac OS on the release branch, and unconditional on the master branch (once the fix for 33154 is committed)? That way users on the master branch will be able to test pty mode before the next release, and we fix the release branch without potentially destabilizing non-Darwin users. Thomas