From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.devel Subject: Re: Sending EOF to process as part of comint-simple-send Date: Sat, 14 Jan 2023 21:27:56 -0800 Message-ID: <1c1a3086-1c0a-e4c0-0bd6-6c48cd0efaa3@gmail.com> References: <83v8l971id.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2857"; mail-complaints-to="usenet@ciao.gmane.io" To: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 15 06:28:27 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pGvZD-0000b1-9g for ged-emacs-devel@m.gmane-mx.org; Sun, 15 Jan 2023 06:28:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGvYo-0000h3-8q; Sun, 15 Jan 2023 00:28:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGvYn-0000gf-3U for emacs-devel@gnu.org; Sun, 15 Jan 2023 00:28:01 -0500 Original-Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pGvYl-0004Ey-8e; Sun, 15 Jan 2023 00:28:00 -0500 Original-Received: by mail-pg1-x52c.google.com with SMTP id f3so17550337pgc.2; Sat, 14 Jan 2023 21:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=uH6EboAer0d4TER++qMU+UUks2HrBCcSRoSgHrikcuo=; b=BrE+Myp6Cdz5jPUiq/YzsH5BX0CjN66zEWaQ+LR+G93T3ySE6l0xjVOkCJD0sPmXME LUkKIuxTgG5u2uYjTjHyM8rfxv8VmHhnA2wodyayAC2nQoB9E4oMyOdn6be4neDbX4tC jWZdRloaEocayVjJ0G6OuSI77YAD89+UEX5X7ZBGA3KA5mjkgJ9SWJyWn2IpfDqc5SZv MPvBHI/KCk9gtTyYYfvJkP7mk6WC0FcLuYhBF+uyOs0CboA5arNPM90HiMqXAl40mKOl XYHfnzpe6kygX9+9eI5bnmMsFn5fRTQ/s/Q7CupaUqTJ+1knqKd3R1Ww4iWe4jfMJdmz dOcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uH6EboAer0d4TER++qMU+UUks2HrBCcSRoSgHrikcuo=; b=Y3AKrW/Z0y4W/3V93oNhpWyp+YvIFTkKD44W0SnPvLZgGJ2zYB/JN5SB4dXsiPV7/r DvBnZ+84EzALTZJ3FOCAVwDcmhC/FG460DoZVfs/aZi/3PrlyRmRC58mvnCXCv8SZSap shOwL+f3VSFMdmoujz1dmBVp82xx8mOwshOpCyjf+ymUt82ZcJj1bTvF/lqWcA4HKcrZ 2sFg8y8Zf/5HRYHOWnIC87kXBy4CyZyhM5iJFZ8FJSQxjjiS7EtccHHF36nnN/eny3e7 4FHqaXKnUL8nv+cyx1Yvt9awUty2Rveuvn3HmDoX3RyglAYUHDvHk6ebDab+Yjcp6KTt PFmg== X-Gm-Message-State: AFqh2kpyIN+ZMlPJz12UwS7xP284AmfdyTwFCsV4Hx8t14BhmnucJyKZ i9ou+6V92LjaS/v8YZLrbsw/qGzdRRJoqA== X-Google-Smtp-Source: AMrXdXtL4ualTwTcncQuWjenMEx9VAaHMLq4LrxD30Q0CXWYsBO2ItcN+ki/cq5Q8KqeoWDAJpBprg== X-Received: by 2002:a05:6a00:18a3:b0:582:197e:f6c1 with SMTP id x35-20020a056a0018a300b00582197ef6c1mr75712714pfh.4.1673760476931; Sat, 14 Jan 2023 21:27:56 -0800 (PST) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id f7-20020a623807000000b00589500f19d0sm11650313pfa.142.2023.01.14.21.27.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Jan 2023 21:27:56 -0800 (PST) Content-Language: en-US In-Reply-To: <83v8l971id.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::52c; envelope-from=jporterbugs@gmail.com; helo=mail-pg1-x52c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302423 Archived-At: On 1/14/2023 4:18 AM, Eli Zaretskii wrote: > In comint-simple-send, we have: > > (comint-send-string proc send-string)) > (if (and comint-input-sender-no-newline > (not (string-equal string ""))) > (process-send-eof))) > > Thus, if we send sub-process input without a newline, we then send EOF > to the sub-process, except when the string we send is empty. > > I can only understand this logic if it assumes a Posix shell or other > Posix process with which we communicate via a PTY. Because in that > case, we just send C-d to the process, and AFAIK that will not cause > the sub-process to finish except when C-d is the only character we > send. [snip] > So I think comint-simple-send should only send EOF if the > communications with the process are via a PTY, at least if the > sub-process is a real process (as opposed to a network or serial or > pipe process). Or maybe we should only refrain from sending EOF on > MS-Windows? I agree with this: I think we should only call 'process-send-eof' here when communicating via PTY. (To be precise, whenever the process's *stdin* is a PTY; as of Emacs 29, a process's stdin can be a PTY even if its stdout isn't, or vice versa. See commit d7b89ea407.) I imagine you've looked into the relevant POSIX specs already, but just to explain my reasoning for why I agree... my reading of the POSIX spec[1] for EOF is that the code above is using it as a way to flush the I/O buffer for the PTY, which makes sense to me: > EOF: Special character on input, which is recognized if the > ICANON flag is set. When received, all the bytes waiting to be > read are immediately passed to the process without waiting for a > , and the EOF is discarded. Thus, if there are no bytes > waiting (that is, the EOF occurred at the beginning of a line), a > byte count of zero shall be returned from the read(), > representing an end-of-file indication. If ICANON is set, the EOF > character shall be discarded when processed. However, that logic would only apply for PTYs, since a) this documentation is about the POSIX terminal interface, and b) as you said in your message, 'process-send-eof' doesn't actually send an EOF character when communicating via a pipe at all; it closes the file descriptor! [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html#tag_11_01_09