bug#33050: 27.0.50; [macOS] Problem with process input with process-connection-type nil

[Thomas Fitzsimmons]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Filipp Gunbin <fgunbin@fastmail.fm>
>> Cc: fitzsim@fitzsim.org,  33050@debbugs.gnu.org, alan@idiocy.org
>> Date: Thu, 25 Oct 2018 20:10:06 +0300
>> 
>> > I'm probably missing something: why are you still trying to find a
>> > solution, when one was already found?  What's wrong with setting
>> > process-connection-type non-nil in this case, at least for Darwin?
>> 
>> Yes, setting p-c-t to t worked from the start, but it's just a
>> workaround - there's still problem with p-c-t nil.
>> 
>> I'm currently running with this patch, which is based on Alan's fix in
>> callproc.c (call_process() had the same problem on Darwin).
>
> 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.

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?

ldapsearch works for me on GNU/Linux either way, and I don't mind
changing process-connection-type to t on the release branch to work
around the Darwin behaviour.  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".

Thanks,
Thomas