unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Bruno Haible <bruno@clisp.org>
Cc: jporterbugs@gmail.com, larsi@gnus.org, eggert@cs.ucla.edu,
	bug-gnulib@gnu.org, 57129@debbugs.gnu.org
Subject: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell
Date: Tue, 16 Aug 2022 16:51:06 +0300	[thread overview]
Message-ID: <838rnofgad.fsf__21557.5367373944$1660657949$gmane$org@gnu.org> (raw)
In-Reply-To: <1871347.6tgchFWduM@nimes> (message from Bruno Haible on Tue, 16 Aug 2022 15:35:17 +0200)

> From: Bruno Haible <bruno@clisp.org>
> Cc: larsi@gnus.org, 57129@debbugs.gnu.org, jporterbugs@gmail.com
> Date: Tue, 16 Aug 2022 15:35:17 +0200
> 
> Eli Zaretskii wrote:
> > The problem is that callers of
> > make-temp-file reasonably expect it to return a new name every call.
> > And evidently, it does that on GNU/Linux (not sure how, given that the
> > tempname.c code is supposed to be in glibc?).  So if there's no
> > intention to change gen_tempname on non-glibc platforms so that it
> > doesn't repeat the same "random characters" upon each call, I think
> > Emacs should call a different function to generate "random" names of
> > temporary files, for consistency across platforms if not for other
> > reasons.
> 
> You are making incorrect assumptions or hypotheses.

They are neither assumptions nor hypotheses.  They are what I actually
saw by stepping with a debugger into the code.

> I am adding the unit test below. It proves that (at least) on Linux,
> FreeBSD 11, NetBSD 7, OpenBSD 6.0, macOS, AIX 7.1, Solaris 10,
> Cygwin, and native Windows, gen_tempname *does* return a new file
> name on each call, with a very high probability.
> 
> So, gen_tempname does *not* repeat the same "random characters" upon each call.

Well, it does here, when called from Emacs in the particular scenario
of the unit test I was looking into.

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.  In terms of your test program, you need to move the
first unlink call to before the second call to gen_tempname.  Then
your test program will faithfully reproduce what Emacs does in the
case in point.





  parent reply	other threads:[~2022-08-16 13:51 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-11  2:43 bug#57129: 29.0.50; Improve behavior of conditionals in Eshell Jim Porter
2022-08-11  2:46 ` Jim Porter
2022-08-12 15:22   ` Lars Ingebrigtsen
2022-08-13  5:14     ` Jim Porter
2022-08-13  7:01       ` Eli Zaretskii
2022-08-13 18:56         ` Jim Porter
2022-08-14  5:07           ` Eli Zaretskii
2022-08-14  5:37             ` Jim Porter
2022-08-14  7:30               ` Eli Zaretskii
2022-08-14 21:40                 ` Jim Porter
2022-08-15 12:13                   ` Eli Zaretskii
2022-08-15 16:14                     ` Jim Porter
2022-08-15 16:49                       ` Eli Zaretskii
2022-08-15 18:08                         ` Jim Porter
2022-08-15 18:21                           ` Eli Zaretskii
2022-08-15 18:30                             ` Jim Porter
2022-08-15 18:58                               ` Eli Zaretskii
2022-08-15 20:55                                 ` Paul Eggert
     [not found]                                 ` <af0af29b-2362-77db-081e-046158937808@cs.ucla.edu>
2022-08-15 21:22                                   ` Bruno Haible
2022-08-16 11:04                                   ` Eli Zaretskii
     [not found]                                   ` <835yish2l1.fsf@gnu.org>
2022-08-16 13:35                                     ` Bruno Haible
     [not found]                                     ` <1871347.6tgchFWduM@nimes>
2022-08-16 13:51                                       ` Eli Zaretskii [this message]
     [not found]                                       ` <838rnofgad.fsf@gnu.org>
2022-08-16 14:40                                         ` Bruno Haible
2022-08-16 16:25                                           ` Eli Zaretskii
     [not found]                                           ` <83wnb8dukz.fsf@gnu.org>
2022-08-16 16:54                                             ` Paul Eggert
     [not found]                                             ` <206e38df-2db4-a46a-e0ff-952bc8ab939c@cs.ucla.edu>
2022-08-16 17:04                                               ` Eli Zaretskii
     [not found]                                               ` <83sflwdsr2.fsf@gnu.org>
2022-08-16 17:30                                                 ` Paul Eggert
2022-08-16 17:41                                                 ` Eli Zaretskii
     [not found]                                                 ` <ceeeaa86-6199-93b1-ff65-bbd3e531e235@cs.ucla.edu>
2022-08-16 17:56                                                   ` Eli Zaretskii
2022-08-16 17:25                                             ` Paul Eggert
2022-08-16 17:29                                             ` Bruno Haible
     [not found]                                             ` <f329244a-cba7-65cd-2e5d-2630eba3e9e9@cs.ucla.edu>
2022-08-16 17:47                                               ` Eli Zaretskii
2022-08-16 19:11                                                 ` Paul Eggert
     [not found]                                                 ` <d95734ab-6bbc-7403-c1f8-fbf742badda4@cs.ucla.edu>
2022-08-16 20:12                                                   ` Bruno Haible
2022-08-17 11:08                                                   ` Eli Zaretskii
     [not found]                                                   ` <83h72bdt4z.fsf@gnu.org>
2022-08-18  6:05                                                     ` Paul Eggert
     [not found]                                                     ` <57b8f10f-8e9b-5951-e5ad-8cba2a8cb569@cs.ucla.edu>
2022-08-18  6:44                                                       ` Eli Zaretskii
     [not found]                                             ` <2594092.Isy0gbHreE@nimes>
2022-08-16 17:52                                               ` Eli Zaretskii
2022-08-16 20:06                                                 ` Bruno Haible
     [not found]                                                 ` <2606289.q0ZmV6gNhb@nimes>
2022-08-17 11:29                                                   ` Eli Zaretskii
2022-08-16 19:59                                         ` Bruno Haible
     [not found]                                         ` <2135151.C4sosBPzcN@nimes>
2022-08-16 20:53                                           ` Paul Eggert
2022-08-21 16:20                                             ` Bruno Haible
2022-08-21 16:32                                               ` Eli Zaretskii
2022-08-21 17:17                                               ` Bruno Haible
2022-08-22 20:47                                                 ` Paul Eggert
     [not found]                                                 ` <2dc7ede0-eca7-baf5-f89a-f5d292b80808@cs.ucla.edu>
2022-08-23  0:13                                                   ` Bruno Haible
     [not found]                                                   ` <3893771.2iPT33SAM4@nimes>
2022-08-23 11:18                                                     ` Eli Zaretskii
     [not found]                                                     ` <831qt79pjj.fsf@gnu.org>
2022-08-23 14:49                                                       ` Bruno Haible
2022-08-23 16:07                                                         ` Eli Zaretskii
2022-08-20 18:03                                 ` Jim Porter
2022-08-20 18:14                                   ` Eli Zaretskii
2022-08-20 18:49                                     ` Jim Porter
2022-08-24 21:41                                   ` Jim Porter
2022-08-26  5:10                                     ` Jim Porter
2023-03-16  5:35                                       ` Jim Porter
2022-08-14  5:03       ` Sean Whitton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='838rnofgad.fsf__21557.5367373944$1660657949$gmane$org@gnu.org' \
    --to=eliz@gnu.org \
    --cc=57129@debbugs.gnu.org \
    --cc=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=jporterbugs@gmail.com \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).