From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell Date: Tue, 16 Aug 2022 19:25:16 +0300 Message-ID: <83wnb8dukz.fsf__10721.4154488005$1660667178$gmane$org@gnu.org> References: <1871347.6tgchFWduM@nimes> <838rnofgad.fsf@gnu.org> <4165399.mogB4TqSGs@nimes> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34695"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jporterbugs@gmail.com, larsi@gnus.org, eggert@cs.ucla.edu, bug-gnulib@gnu.org, 57129@debbugs.gnu.org To: Bruno Haible Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 16 18:26:11 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oNzOM-0008nQ-Pv for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Aug 2022 18:26:11 +0200 Original-Received: from localhost ([::1]:49990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oNzOL-00072i-NF for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Aug 2022 12:26:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50314) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNzOE-00072L-Ux for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 12:26:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58370) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oNzOE-0000K1-Mk for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 12:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oNzOE-0000Dq-HV for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 12:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 16 Aug 2022 16:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57129 X-GNU-PR-Package: emacs Original-Received: via spool by 57129-submit@debbugs.gnu.org id=B57129.1660667155842 (code B ref 57129); Tue, 16 Aug 2022 16:26:02 +0000 Original-Received: (at 57129) by debbugs.gnu.org; 16 Aug 2022 16:25:55 +0000 Original-Received: from localhost ([127.0.0.1]:48119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNzO7-0000DW-4N for submit@debbugs.gnu.org; Tue, 16 Aug 2022 12:25:55 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37240) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNzO2-0000DD-0L for 57129@debbugs.gnu.org; Tue, 16 Aug 2022 12:25:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58256) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNzNu-0000AR-OY; Tue, 16 Aug 2022 12:25:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Ocgy09KkRCZm2wECFo11lo6yvo6Dv/oSVgkgpO6HE08=; b=NDZC0dtzQEv+ bR4n4JpRJ6G+FF0zvGLhXD7XMqgJQPfhzVp2c2kR8Z6TETYR4mZMZsYFtI0LbUmvO1zmmq3uCewgp 9kQxmL/2BOIvQdkwICCu1zKoTtdTL2/7BGMZoC6ZEEEVJdubQen6IpRS+nFCTQ8KfRAYiFv/ulTpE kZD1Q+62ZIhDFPfyMrDzRWaffmJ998bWwxLWkoxTwNrt+0NAa1GFctxY1B8gye9jcpUiVVhPpI+dg K/VTZFEaodcTDHGDZm6V9v1N8osJ2q9FgQLhiIkOWBcPATRWkVIFXoousVwTFL74NMbfEHVWcyRhn 1rP0CtZ4w+I3u6q4clOiSw==; Original-Received: from [87.69.77.57] (port=1567 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNzNh-00007P-JC; Tue, 16 Aug 2022 12:25:41 -0400 In-Reply-To: <4165399.mogB4TqSGs@nimes> (message from Bruno Haible on Tue, 16 Aug 2022 16:40:16 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:239971 Archived-At: > From: Bruno Haible > Cc: eggert@cs.ucla.edu, bug-gnulib@gnu.org, larsi@gnus.org, 57129@debbugs.gnu.org, jporterbugs@gmail.com > Date: Tue, 16 Aug 2022 16:40:16 +0200 > > Eli Zaretskii wrote: > > Looking at your test program, I see that you generate the seconds file > > name without deleting the first one. When a file by the first > > generated name already exists, gen_tempname will indeed generate a > > different name. But in the scenario I described, Emacs creates one > > temporary file, uses it, then deletes it, and only after that creates > > another file. > > Why would it be important for the second temporary file to bear a different > name, once the first one is gone? I mean, process IDs get reused over time; > socket numbers get reused over time; what is wrong with reusing a file name, > once the older file is gone? Because the Emacs Lisp program expected that, based on what make-temp-file in Emacs promises (see the "random characters" part), and because that's how it behaves on GNU/Linux. Then the same program behaved differently on MS-Windows, and the programmer was stumped. Sure, it's possible to write the same program somewhat differently, carefully working around this issue, but my point is that such functions should ideally present the same behavior traits on all systems, otherwise the portability is hampered. > Maybe the problem is that the file gets deleted too early, when some parts > of Emacs still reference it? The buffer which visited that file still exists, and still records the name of the file, yes. And then, when the program writes to another file created by another call to make-temp-file, it actually writes to a file that some buffer still visits, and in Emacs that triggers a prompt to the user to refresh the buffer. The programmer didn't expect that because it is natural to expect each call to a function that creates a temporary file to create a file under a new name, not reuse the same name. E.g., similar facilities in the Standard C library exhibit that behavior. So the program was written assuming that the second write was to an entirely different and unrelated file. And again, my main point is: why does this work differently on different platforms? If you consider it OK to return the same file name each time, provided that no such file exists, then why doesn't that function do it on GNU/Linux?