From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas =?UTF-8?Q?R=C3=B6hler?= Newsgroups: gmane.emacs.bugs Subject: bug#15647: 24.3.50; python.el does not clean up temp file Date: Sun, 20 Oct 2013 18:25:29 +0200 Message-ID: <526403F9.6020209@easy-emacs.de> References: <87eh7ih0pz.fsf@orion.kollektiv-hamburg.de> <5262BB9D.4050802@easy-emacs.de> <52638B84.6070409@easy-emacs.de> <83li1oklcu.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1382286257 19427 80.91.229.3 (20 Oct 2013 16:24:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2013 16:24:17 +0000 (UTC) Cc: 15647@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 20 18:24:20 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VXvnf-0001BI-EF for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Oct 2013 18:24:19 +0200 Original-Received: from localhost ([::1]:36875 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXvne-0005R4-Hc for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Oct 2013 12:24:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXvnW-0005Qg-IK for bug-gnu-emacs@gnu.org; Sun, 20 Oct 2013 12:24:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VXvnO-00064F-Eh for bug-gnu-emacs@gnu.org; Sun, 20 Oct 2013 12:24:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXvnO-000645-BG for bug-gnu-emacs@gnu.org; Sun, 20 Oct 2013 12:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VXvnN-0005vJ-Qg for bug-gnu-emacs@gnu.org; Sun, 20 Oct 2013 12:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andreas =?UTF-8?Q?R=C3=B6hler?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Oct 2013 16:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15647 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 15647-submit@debbugs.gnu.org id=B15647.138228619522712 (code B ref 15647); Sun, 20 Oct 2013 16:24:01 +0000 Original-Received: (at 15647) by debbugs.gnu.org; 20 Oct 2013 16:23:15 +0000 Original-Received: from localhost ([127.0.0.1]:59304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VXvmc-0005uF-5b for submit@debbugs.gnu.org; Sun, 20 Oct 2013 12:23:15 -0400 Original-Received: from moutng.kundenserver.de ([212.227.126.171]:49419) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VXvmZ-0005ty-Ix for 15647@debbugs.gnu.org; Sun, 20 Oct 2013 12:23:12 -0400 Original-Received: from purzel.sitgens (brln-4db9223c.pool.mediaWays.net [77.185.34.60]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MCuUJ-1VPzHh0pcZ-009NnU; Sun, 20 Oct 2013 18:23:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <83li1oklcu.fsf@gnu.org> X-Provags-ID: V02:K0:L3HRIbKgeGeco5ADbXhrFEdtXy6G64X1wrbyRauBU6X n/iMpsUZqsofEMDVXx0YiN8mK0gRK4OahXNZ+qU7lq1yNCCP3k nvhNGFYN8DkwBmdnJL4pz2oBbb+D2QGpCwx0GdT8UBw3dwHb+R a9GmE/314T5CFoXAGusOgdNT8pRC0pBe+qyAEc7DbDUV8LqLMD Kc4QPQ7vTJphqEUWnmRdqhlogBBZe3tf4NwfxP0C/HFtPzwkC7 qNUeYc9cHUW8geqtXMEdTdwYrPLWoek32fLEQknp41U23fUhv7 kOtTuERcKd94ggAZ6+sgwwcNfk5r7wg/4K1jJQhRI+q/Hho8GL LP6VIeR6/XXbBM+YImHo= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:79423 Archived-At: Am 20.10.2013 17:33, schrieb Eli Zaretskii: >> Date: Sun, 20 Oct 2013 09:51:32 +0200 >> From: Andreas Röhler >> Cc: 15647@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.