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

[Filipp Gunbin <fgunbin@fastmail.fm>]

On 25/10/2018 20:29 +0300, Eli Zaretskii wrote:

>> 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 think these are separate problems.

Here's my explanation of this problem on Darwin:

Some time ago, setsid() was called only if (pty_flag).  Alan's commit
a13eaddce2ddbe3ba0b7f4c81715bc0fcdba99f6 (fixes bug 26397) changes
vfork() to fork() for this case - so we never call setsid() after
vfork().  Then Paul's commit 5c91ca8f30098cb2593ca375daa82d25aef03ad7
(fixes bug 30762) changes setsid() to be invoked always.  So it again
became possible that we call setsid() after vfork(), and this I believe
is the root case of the current problem.

My patch tries to fix that.  I don't think it matters here whether we
call ldapsearch with correct value of p-c-t or not, it just the case
which was missed.  And vfork() should perform better than fork(), so it
looks like an improvement.

Filipp