GNU bug report logs - #15647
24.3.50; python.el does not clean up temp file

Previous Next

Full log

Message #23 received at 15647 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15647 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#15647: 24.3.50; python.el does not clean up temp file
Date: Sun, 20 Oct 2013 18:25:29 +0200

Am 20.10.2013 17:33, schrieb Eli Zaretskii:
>> Date: Sun, 20 Oct 2013 09:51:32 +0200
>> From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
>> Cc: 15647 <at> debbugs.gnu.org
>>
>>> IIUC the purpose is to make sure it's erased and to make sure it's
>>> erased *after* the use.  Whether it does that, I don't know.
>>> But doing it in Elisp would otherwise require detecting the next prompt
>>
>> Don't think so. Once the file is sent to process, it's sent.
>
> That's Unix-speak: deleting a file that is potentially in use.
> Outside of Posix, deleting a file immediately after submitting it to a
> process will at best fail (because the process is still using it), and
> at worst cause trouble (because the process didn't yet have enough
> time to even open the file).
>
> In fact, in this case, even on Unix this proposal will cause trouble,
> because the command sent to Python might take time to execute on the
> Python side, and we might already have deleted the file when Python
> tries to open it.
>
> I think in this case the better place to delete the file is in
> python-shell-send-file, as part of the command sent to Python, because
> that's where we know that the file was used up and closed by the
> Python interpreter.
>

Agreed.

>> A remaining question: what to do if the command fails? Maybe the temp file is of interest than?
>> Which might be an argument to do it from Python, as the error might prevent further action, i.e. deleting.
>
> No, it's an argument to add independent logging facilities to
> python.el, IMO.  IOW, if python.el wants to have debugging features,
> it should have them without relying on the Python interpreter and
> without interfering with the "normal" workflow (whereby the file is
> deleted after being used).  Relying on a temporary file to remain in
> the filesystem for prolonged periods of time is not a good idea
> anyway.
>

Agreed also. However don't think it's a big issue if the one or other file remains. Just it should not happen all the time.
BTW python-mode.el does this behind an unwind-protect, so errors should not go into the way.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.