From unknown Mon Aug 11 12:54:33 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#12908 <12908@debbugs.gnu.org> To: bug#12908 <12908@debbugs.gnu.org> Subject: Status: 24.3.50; file `emacs_backtrace.txt'? Reply-To: bug#12908 <12908@debbugs.gnu.org> Date: Mon, 11 Aug 2025 19:54:33 +0000 retitle 12908 24.3.50; file `emacs_backtrace.txt'? reassign 12908 emacs submitter 12908 "Drew Adams" severity 12908 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 13:31:43 2012 Received: (at submit) by debbugs.gnu.org; 16 Nov 2012 18:31:43 +0000 Received: from localhost ([127.0.0.1]:48907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZQha-0007rA-U4 for submit@debbugs.gnu.org; Fri, 16 Nov 2012 13:31:43 -0500 Received: from eggs.gnu.org ([208.118.235.92]:60033) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZQhX-0007r1-Oa for submit@debbugs.gnu.org; Fri, 16 Nov 2012 13:31:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZQgi-0001US-If for submit@debbugs.gnu.org; Fri, 16 Nov 2012 13:30:51 -0500 Received: from lists.gnu.org ([208.118.235.17]:59775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZQgi-0001UO-Ap for submit@debbugs.gnu.org; Fri, 16 Nov 2012 13:30:48 -0500 Received: from eggs.gnu.org ([208.118.235.92]:59298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZQgf-0002OJ-8C for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 13:30:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZQgc-0001Rn-2w for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 13:30:45 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:16611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZQgb-0001Ra-QX for bug-gnu-emacs@gnu.org; Fri, 16 Nov 2012 13:30:41 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAGIUdFV029930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 Nov 2012 18:30:40 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAGIUcbG013972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Nov 2012 18:30:39 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAGIUcJS019052 for ; Fri, 16 Nov 2012 12:30:38 -0600 Received: from dradamslap1 (/10.159.229.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Nov 2012 10:30:38 -0800 From: "Drew Adams" To: Subject: 24.3.50; file `emacs_backtrace.txt'? Date: Fri, 16 Nov 2012 10:30:34 -0800 Message-ID: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac3EKHdLQ5ijarbaToaOxnx/0V8OxQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) Still getting many crashes (every session), but now I notice that Emacs is creating a file `emacs_backtrace.txt' in the current directory (or perhaps it is in the dir in which Emacs was started?). I looked in the Emacs manual, the Elisp manual, and NEWS for some information about this file, but found nothing (so there is a doc bug, at least). What is the file for, how are users to use it and control whether and where it is written, etc.? Here is the content of one such file, in case it helps in some way (which I doubt): Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012072B8 0x012080B9 0x0103B54F 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x01063E40 0x010030FF 0x01001411 0x01021A07 0x01208B6F 0x01206FA0 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x01063E40 0x010030FF 0x01001411 0x01021A07 0x01271987 0x012753CF 0x01201334 0x01202410 0x0121160D 0x01208C14 0x01010FC6 0x01208BA1 0x01206FA0 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x010EFEEA 0x010F6A68 0x010F5208 0x010F48F4 0x010F4616 0x0120710E 0x01203D74 0x0103B556 0x0104F14B 0x01038878 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01144D4F 0x01144D2A 0x01144D83 0x010011E6 0x7C8438F6 Backtrace: 0x0115470D 0x0115477F 0x01001459 0x01021A07 0x012D32D3 0x01014F64 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E117F 0x01015E7E 0x01015317 0x010E6C1C 0x01014FD5 0x01014733 0x01052C55 0x010390C7 0x01010EDE 0x0103800B 0x0101093B 0x01037FC5 0x0103757F 0x010378AC 0x010029AB 0x010010F9 0x7C817073 In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2012-11-05 on MS-W7-DANI Bzr revision: 110809 lekktu@gmail.com-20121105172930-a5gn0bwi4lndchhw Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5 -I../../libs/giflib-4.1.4-1-lib/include -I../../libs/jpeg-6b-4-lib/include -I../../libs/tiff-3.8.2-1-lib/include -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2 -I../../libs/gnutls-3.0.9-w32-bin/include -I../../libs/libiconv-1.9.2-1-lib/include' From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 13:42:19 2012 Received: (at 12908) by debbugs.gnu.org; 16 Nov 2012 18:42:19 +0000 Received: from localhost ([127.0.0.1]:48937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZQrq-000875-Ic for submit@debbugs.gnu.org; Fri, 16 Nov 2012 13:42:19 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]:45410) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZQro-00086x-Ll for 12908@debbugs.gnu.org; Fri, 16 Nov 2012 13:42:17 -0500 Received: by mail-ee0-f44.google.com with SMTP id b47so1946603eek.3 for <12908@debbugs.gnu.org>; Fri, 16 Nov 2012 10:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H/0JJYAZTNs1oXuf/StDgBAS4U+K8gR8LyB50ehkTN8=; b=lPBQAXXiv9FpKHwckC4W7f9pTNnApAg/ob7coqbmZ83Aq0jhxdgqwntOmcD46sPfJb 8KYWeWNhdfkXbDuoHeDmFwV1Nw31K2s/fnoJ4KPx6ckR8lxCenxmp/SKfmZFDJFMrrSP 9/4rR7LXiXBEVbgOSrKdPeRuZJnest3igzVLkTgb5tzzJ92ZmMesynBdB8HWC/lj181t hgFeXuubBFFb/Qj1+kWBKlU1zUxBtH3VegnAnLoq+FgMPJjf37gLqZIZ/9U5q/1u237h ZIyvkCAvf92a74yEkXKJrkRkccVGqRMrFl3uyOwKM875Okew7PZe7qrFhO3jm1SfZyV6 6Qwg== Received: by 10.14.173.71 with SMTP id u47mr15919084eel.20.1353091287768; Fri, 16 Nov 2012 10:41:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.4.209 with HTTP; Fri, 16 Nov 2012 10:40:46 -0800 (PST) In-Reply-To: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> From: Juanma Barranquero Date: Fri, 16 Nov 2012 19:40:46 +0100 Message-ID: Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? To: Drew Adams Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On Fri, Nov 16, 2012 at 7:30 PM, Drew Adams wrote: > I looked in the Emacs manual, the Elisp manual, and NEWS for some > information about this file, but found nothing (so there is a doc bug, > at least). Yes. > What is the file for, how are users to use it and control whether and > where it is written, etc.? 2012-11-02 Eli Zaretskii Implement backtrace output for fatal errors on MS-Windows. * w32fns.c (CaptureStackBackTrace_proc): New typedef. (BACKTRACE_LIMIT_MAX): New macro. (w32_backtrace): New function. (emacs_abort): Use w32_backtrace when the user chooses not to attach a debugger. Update the text of the abort dialog. Currently you cannot control where it is written. As for how to use it, if you have MinGW installed you can use addr2line: addr2line -e /path/to/emacs.exe < emacs_backtrace.txt Juanma From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 14:01:45 2012 Received: (at 12908-done) by debbugs.gnu.org; 16 Nov 2012 19:01:45 +0000 Received: from localhost ([127.0.0.1]:49043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRAe-0000AJ-Qi for submit@debbugs.gnu.org; Fri, 16 Nov 2012 14:01:45 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:38454) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRAc-0000AB-GA for 12908-done@debbugs.gnu.org; Fri, 16 Nov 2012 14:01:43 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDL00F00GN4PL00@a-mtaout20.012.net.il> for 12908-done@debbugs.gnu.org; Fri, 16 Nov 2012 21:00:52 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDL00FVWGTG3NF0@a-mtaout20.012.net.il>; Fri, 16 Nov 2012 21:00:52 +0200 (IST) Date: Fri, 16 Nov 2012 21:00:21 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <838va14blm.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Date: Fri, 16 Nov 2012 10:30:34 -0800 > > Still getting many crashes (every session), but now I notice that Emacs > is creating a file `emacs_backtrace.txt' in the current directory (or > perhaps it is in the dir in which Emacs was started?). [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12908-done Cc: 12908-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Date: Fri, 16 Nov 2012 10:30:34 -0800 > > Still getting many crashes (every session), but now I notice that Emacs > is creating a file `emacs_backtrace.txt' in the current directory (or > perhaps it is in the dir in which Emacs was started?). [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] > From: "Drew Adams" > Date: Fri, 16 Nov 2012 10:30:34 -0800 > > Still getting many crashes (every session), but now I notice that Emacs > is creating a file `emacs_backtrace.txt' in the current directory (or > perhaps it is in the dir in which Emacs was started?). It's written in the current directory of the Emacs process, and only if you click NO on the abort dialog. > I looked in the Emacs manual, the Elisp manual, and NEWS for some > information about this file, but found nothing (so there is a doc bug, > at least). Right, now fixed (revision 110913 on the trunk). > What is the file for It contains the call-stack backtrace, which could be used to find the sequence of function calls that led to the crash. Similar to what GDB produces when you type "bt". > how are users to use it Users should include it with their bug reports. If you have the addr2line.exe program on your disk, you can produce a more readable backtrace from these numbers, see the Emacs user manual for details. > and control whether and where it is written You can't. It's always written in the current directory of the Emacs process, which is normally a single directory determined by what your desktop shortcut says. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 14:09:14 2012 Received: (at 12908) by debbugs.gnu.org; 16 Nov 2012 19:09:14 +0000 Received: from localhost ([127.0.0.1]:49049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRHt-0000Ko-J0 for submit@debbugs.gnu.org; Fri, 16 Nov 2012 14:09:14 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:46237) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRHr-0000Kh-Ga for 12908@debbugs.gnu.org; Fri, 16 Nov 2012 14:09:12 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAGJ8LcB005459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Nov 2012 19:08:22 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAGJ8L6N029970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2012 19:08:21 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAGJ8KQj013451; Fri, 16 Nov 2012 13:08:21 -0600 Received: from dradamslap1 (/10.159.229.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Nov 2012 11:08:20 -0800 From: "Drew Adams" To: "'Juanma Barranquero'" References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Fri, 16 Nov 2012 11:08:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac3EKf4ik7suC4KMSQGzwAAgVPWx0gAAnEhA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > > What is the file for, how are users to use it and control > > whether and where it is written, etc.? > > Implement backtrace output for fatal errors on MS-Windows. > * w32fns.c (CaptureStackBackTrace_proc): New typedef. > (BACKTRACE_LIMIT_MAX): New macro. > (w32_backtrace): New function. > (emacs_abort): Use w32_backtrace when the user chooses not to > attach a debugger. Update the text of the abort dialog. > > Currently you cannot control where it is written. Thanks for the info. Can you at least control _whether_ it is written? > As for how to use it, if you have MinGW installed you can use > addr2line: addr2line -e /path/to/emacs.exe < emacs_backtrace.txt (Which does what?) If you do *not* have MinGW installed then is it the case that you can do nothing with the file? If so then, in that case at least, users should have an easy way to turn off writing the file (which no one can use). Is there some way (e.g. an env var to check?) that Emacs can itself know whether MinGW is installed, so that at least in the case where it is not it can inhibit writing the file (by default - obviously to be overridable by users)? The file is not big (at least it wasn't in the case I had), so I don't mind Emacs writing it, even though I cannot use it. But I think users should be able to control whether and where it gets written. And I'm thinking that the default location should perhaps be somewhere under .emacs.d, perhaps with the dir that is currently used as the default recorded somehow. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 14:23:49 2012 Received: (at 12908) by debbugs.gnu.org; 16 Nov 2012 19:23:49 +0000 Received: from localhost ([127.0.0.1]:49078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRW1-0001W4-Dp for submit@debbugs.gnu.org; Fri, 16 Nov 2012 14:23:49 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:26659) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRVy-0001Vr-OI; Fri, 16 Nov 2012 14:23:47 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAGJMu54019270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Nov 2012 19:22:57 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAGJMueq023388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2012 19:22:56 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAGJMuqH024227; Fri, 16 Nov 2012 13:22:56 -0600 Received: from dradamslap1 (/10.159.229.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Nov 2012 11:22:55 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <838va14blm.fsf@gnu.org> Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Fri, 16 Nov 2012 11:22:51 -0800 Message-ID: <5F469B1E1F824FA8B16159BB2E0DE869@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <838va14blm.fsf@gnu.org> Thread-Index: Ac3ELLPuPAlb+rOkQdyAF8AwStvA3gAASE/w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org, 12908-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > It's written in the current directory of the Emacs process, and only > if you click NO on the abort dialog. I don't understand. If you click NO then you are saying that you do NOT want to participate in debugging the crash. Why would Emacs insist in that case in writing a backtrace file for debugging to your hard drive? That does not seem very friendly (or useful) on the part of Emacs. > > I looked in the Emacs manual, the Elisp manual, and NEWS for some > > information about this file, but found nothing (so there is > > a doc bug, at least). > > Right, now fixed (revision 110913 on the trunk). > > > What is the file for > > It contains the call-stack backtrace, which could be used to find the > sequence of function calls that led to the crash. Similar to what GDB > produces when you type "bt". So it could be used for debugging. But it is written only if a user says that s?he does NOT want to debug the crash. I understand that such a NO means, in particular, that s?he does not want to use gdb, but it can also mean that s?he does not want to bother with any debugging etc. Why assume that s?he wants a backtrace file written? > > how are users to use it > > Users should include it with their bug reports. Does my having included it in this bug report help in some way? I'm guessing no, but would love to be shown wrong. > If you have the addr2line.exe program on your disk, you can > produce a more readable backtrace from these numbers, see > the Emacs user manual for details. And if you do not have addr2line? Is the backtrace really useful for anyone in that case? Did the backtrace I included here help at all? (Not rhetorical questions.) > > and control whether and where it is written > > You can't. It's always written in the current directory of the Emacs > process, which is normally a single directory determined by what your > desktop shortcut says. Why not let users decide where the file is written, and record that directory (of the process) as part of the file content (or record it elsewhere)? Sounds like shades of Unix .core files. At least there are ways for users to turn off writing such coredumps (and even ways to turn that off selectively, for given directories). You've closed the bug, considering, I imagine, that it is only a doc bug and that you have now documented it, so end of story. I don't see it that way. Emacs is now writing something to arbitrary user directories. That is something new and not necessarily always welcome. Please consider working on this aspect some more. Thx. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 14:41:05 2012 Received: (at 12908) by debbugs.gnu.org; 16 Nov 2012 19:41:05 +0000 Received: from localhost ([127.0.0.1]:49103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRmi-0001w1-Ef for submit@debbugs.gnu.org; Fri, 16 Nov 2012 14:41:05 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:38267) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRme-0001vU-Bv; Fri, 16 Nov 2012 14:41:01 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDL00E00I6D7C00@a-mtaout22.012.net.il>; Fri, 16 Nov 2012 21:39:32 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDL00D22ILV6ZL0@a-mtaout22.012.net.il>; Fri, 16 Nov 2012 21:39:32 +0200 (IST) Date: Fri, 16 Nov 2012 21:39:01 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: <5F469B1E1F824FA8B16159BB2E0DE869@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <837gpl49t6.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <838va14blm.fsf@gnu.org> <5F469B1E1F824FA8B16159BB2E0DE869@us.oracle.com> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org>, <12908-done@debbugs.gnu.org> > Date: Fri, 16 Nov 2012 11:22:51 -0800 > > > It's written in the current directory of the Emacs process, and only > > if you click NO on the abort dialog. > > I don't understand. If you click NO then you are saying that you do NOT want to > participate in debugging the crash. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org, 12908-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org>, <12908-done@debbugs.gnu.org> > Date: Fri, 16 Nov 2012 11:22:51 -0800 > > > It's written in the current directory of the Emacs process, and only > > if you click NO on the abort dialog. > > I don't understand. If you click NO then you are saying that you do NOT want to > participate in debugging the crash. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org>, <12908-done@debbugs.gnu.org> > Date: Fri, 16 Nov 2012 11:22:51 -0800 > > > It's written in the current directory of the Emacs process, and only > > if you click NO on the abort dialog. > > I don't understand. If you click NO then you are saying that you do NOT want to > participate in debugging the crash. No, you say that you don't want to attach a debugger. > Why would Emacs insist in that case in writing a backtrace file for > debugging to your hard drive? Don't ask me, I just implemented on Windows what Emacs does on GNU and Unix platforms. When this was suggested, I posted a message describing the disadvantages of this method, see http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00501.html But the feature was implemented nonetheless. So now it's part Emacs, on Unix and Windows alike. > That does not seem very friendly (or useful) on the part of Emacs. There are gobs of programs writing to your disk right now, without asking for your permission. What's so unfriendly in Emacs doing the same? > > It contains the call-stack backtrace, which could be used to find the > > sequence of function calls that led to the crash. Similar to what GDB > > produces when you type "bt". > > So it could be used for debugging. But it is written only if a user says that > s?he does NOT want to debug the crash. Yes. We, the Emacs maintainers, expect you to submit that file for us to debug the problem. > > Users should include it with their bug reports. > > Does my having included it in this bug report help in some way? > I'm guessing no, but would love to be shown wrong. Your guess is wrong, that file includes enough information to understand where the crash happened, and in some cases also why. > > If you have the addr2line.exe program on your disk, you can > > produce a more readable backtrace from these numbers, see > > the Emacs user manual for details. > > And if you do not have addr2line? Then I do. > Is the backtrace really useful for anyone in that case? Did the > backtrace I included here help at all? Yes. Anyone with addr2line.exe can run it and recover the source file names and line numbers where the crash happened. > > > and control whether and where it is written > > > > You can't. It's always written in the current directory of the Emacs > > process, which is normally a single directory determined by what your > > desktop shortcut says. > > Why not let users decide where the file is written, and record that directory > (of the process) as part of the file content (or record it elsewhere)? Because (a) that's how Emacs works on other platforms, and (b) consulting Lisp when Emacs caught a fatal error is dangerous (could produce another fatal error). > Sounds like shades of Unix .core files. It is, indeed. > At least there are ways for users to turn off writing such coredumps > (and even ways to turn that off selectively, for given directories). Which is bad for maintainers, because users then flood them with worthless bug reports that cannot be acted upon. > You've closed the bug, considering, I imagine, that it is only a doc bug and > that you have now documented it, so end of story. End of _this_ story, yes. > I don't see it that way. Emacs is now writing something to arbitrary user > directories. That is something new and not necessarily always welcome. Please > consider working on this aspect some more. Thx. Then please submit another bug report, which is not Windows specific and not about the documentation of this file. If the general Emacs behavior changes, so will its behavior on Windows. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 14:43:28 2012 Received: (at 12908) by debbugs.gnu.org; 16 Nov 2012 19:43:28 +0000 Received: from localhost ([127.0.0.1]:49108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRp2-0001zV-7h for submit@debbugs.gnu.org; Fri, 16 Nov 2012 14:43:28 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:52085) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZRp0-0001zM-Hu for 12908@debbugs.gnu.org; Fri, 16 Nov 2012 14:43:27 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MDL00400IL9YJ00@a-mtaout21.012.net.il> for 12908@debbugs.gnu.org; Fri, 16 Nov 2012 21:42:37 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDL004E0IR0M4F0@a-mtaout21.012.net.il>; Fri, 16 Nov 2012 21:42:37 +0200 (IST) Date: Fri, 16 Nov 2012 21:42:06 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83625549o1.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Date: Fri, 16 Nov 2012 11:08:16 -0800 > Cc: 12908@debbugs.gnu.org > > Can you at least control _whether_ it is written? No. But you can set up a scheduled task to delete it every day, if you wish. You can even do this in Emacs, using the midnight.el package. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12908 Cc: lekktu@gmail.com, 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Date: Fri, 16 Nov 2012 11:08:16 -0800 > Cc: 12908@debbugs.gnu.org > > Can you at least control _whether_ it is written? No. But you can set up a scheduled task to delete it every day, if you wish. You can even do this in Emacs, using the midnight.el package. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] > From: "Drew Adams" > Date: Fri, 16 Nov 2012 11:08:16 -0800 > Cc: 12908@debbugs.gnu.org > > Can you at least control _whether_ it is written? No. But you can set up a scheduled task to delete it every day, if you wish. You can even do this in Emacs, using the midnight.el package. > And I'm thinking that the default location should perhaps be somewhere under > .emacs.d, perhaps with the dir that is currently used as the default recorded > somehow. This is dangerous, because accessing the home directory may involve Lisp evaluation, e.g. if that directory is remote. This facility must be as simple and close to the bare metal as possible, or else it will be more trouble than help. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 15:57:54 2012 Received: (at 12908) by debbugs.gnu.org; 16 Nov 2012 20:57:55 +0000 Received: from localhost ([127.0.0.1]:49302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZSz4-0004Z2-4n for submit@debbugs.gnu.org; Fri, 16 Nov 2012 15:57:54 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:40203) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZSz1-0004Ym-4T; Fri, 16 Nov 2012 15:57:52 -0500 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAGKv0JN006596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Nov 2012 20:57:01 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAGKv0KE010858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2012 20:57:00 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAGKuxVc019657; Fri, 16 Nov 2012 14:56:59 -0600 Received: from dradamslap1 (/10.159.229.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Nov 2012 12:56:59 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <838va14blm.fsf@gnu.org> <5F469B1E1F824FA8B16159BB2E0DE869@us.oracle.com> <837gpl49t6.fsf@gnu.org> Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Fri, 16 Nov 2012 12:56:55 -0800 Message-ID: <263AC1B3AE7347CEAA88A5723B1C7A7F@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <837gpl49t6.fsf@gnu.org> Thread-Index: Ac3EMjKasJxrsCMaRPKqjI8PgAupagABp/Ag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org, 12908-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > > Why would Emacs insist in that case in writing a backtrace file for > > debugging to your hard drive? > > Don't ask me, I just implemented on Windows what Emacs does on GNU and > Unix platforms. When this was suggested, I posted a message > describing the disadvantages of this method, see > http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00501.html > > But the feature was implemented nonetheless. So now it's part Emacs, > on Unix and Windows alike. Thanks for the background. > > That does not seem very friendly (or useful) on the part of Emacs. > > There are gobs of programs writing to your disk right now, without > asking for your permission. What's so unfriendly in Emacs doing the > same? I don't have gobs of programs writing to arbitrary directories, especially directories with user files. AFAIK, I have NO programs doing that. If whether such writing is done cannot be controlled by a user (not good, IMHO), then Emacs should at least write the information to a "hidden", more or less "internal" directory, such as .emacs.d. Putting this stuff willy nilly in user directories is a bad idea, IMO. Not at all user-friendly. (And that's regardless of whether Emacs feels free to do this on some other platforms. Emacs being rude elsewhere is not a good excuse for it to be rude on Windows too.) > We, the Emacs maintainers, expect you to submit that file for us > to debug the problem. > > > > Users should include it with their bug reports. > > > > Does my having included it in this bug report help in some way? > > I'm guessing no, but would love to be shown wrong. > > Your guess is wrong, that file includes enough information to > understand where the crash happened, and in some cases also why. That's good news. Let's hope it helps fix some of the crashing problems. > > Is the backtrace really useful for anyone in that case? Did the > > backtrace I included here help at all? > > Yes. Anyone with addr2line.exe can run it and recover the source file > names and line numbers where the crash happened. Very good. > > Why not let users decide where the file is written, and > > record that directory (of the process) as part of the file > > content (or record it elsewhere)? > > Because (a) that's how Emacs works on other platforms, and > (b) consulting Lisp when Emacs caught a fatal error is dangerous > (could produce another fatal error). a1. It is Emacs maintainers who decide how Emacs should work - on any platform. a2. "That's how Emacs works" is false: It is not true in any Emacs release. It is true only in code under development that is being _proposed_ for release. Hardly a "that's just how it is" precedent. b. Why would Lisp need to be consulted? But if there is no better alternative, a user's choice could be recorded in a file that is read before writing emacs_backtrace.txt. Of course, you will perhaps say the same thing wrt opening a file... I realize that might be problematic. (But at least it is not rude.) > > Sounds like shades of Unix .core files. > > It is, indeed. > > > At least there are ways for users to turn off writing such coredumps > > (and even ways to turn that off selectively, for given directories). > > Which is bad for maintainers, because users then flood them with > worthless bug reports that cannot be acted upon. Well, one of the main reasons people prevent coredumps in Unix is that they are costly in time & space. That of course does not apply here. I don't see a crying need to prevent writing these backtrace files. I do see a need (a courtesy to users) for letting users decide where to put them. Or barring that possibility, at least a need to confine them to someplace under .emacs.d. > Please submit another bug report, which is not Windows specific > and not about the documentation of this file. If the general Emacs > behavior changes, so will its behavior on Windows. Done (#12911). But it is you, not I, who chooses to characterizes this bug as being about only doc and only MS Windows. Please reread the subject line. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 16:03:25 2012 Received: (at 12908) by debbugs.gnu.org; 16 Nov 2012 21:03:25 +0000 Received: from localhost ([127.0.0.1]:49307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZT4O-0004hM-AP for submit@debbugs.gnu.org; Fri, 16 Nov 2012 16:03:25 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:28142) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZT4M-0004hE-J5 for 12908@debbugs.gnu.org; Fri, 16 Nov 2012 16:03:23 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAGL2Wex011648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Nov 2012 21:02:33 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAGL2War025904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2012 21:02:32 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAGL2VS2017900; Fri, 16 Nov 2012 15:02:31 -0600 Received: from dradamslap1 (/10.159.229.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Nov 2012 13:02:31 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <83625549o1.fsf@gnu.org> Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Fri, 16 Nov 2012 13:02:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <83625549o1.fsf@gnu.org> Thread-Index: Ac3EMomgpzGrR0tZShqxUUESx5Y65gACqIGg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12908 Cc: lekktu@gmail.com, 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > > And I'm thinking that the default location should perhaps > > be somewhere under .emacs.d, perhaps with the dir that is > > currently used as the default recorded somehow. > > This is dangerous, because accessing the home directory may involve > Lisp evaluation, e.g. if that directory is remote. This facility must > be as simple and close to the bare metal as possible, or else it will > be more trouble than help. Then put it under the Emacs installation directory. The point is to get it away from user files. Please use your imagination. If there are good reasons why you cannot easily put it here or there, then try somewhere else - but aim for somewhere that does not interfere with user data. A users looking in her folder of recipes should not find an Emacs debugging file. That should be a no-brainer, at least in terms of goal. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 16 16:50:14 2012 Received: (at 12908) by debbugs.gnu.org; 16 Nov 2012 21:50:14 +0000 Received: from localhost ([127.0.0.1]:49481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZTni-0005oM-Cu for submit@debbugs.gnu.org; Fri, 16 Nov 2012 16:50:14 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:46143) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZTng-0005oF-Aa for 12908@debbugs.gnu.org; Fri, 16 Nov 2012 16:50:13 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu09sr+ZY/2dsb2JhbABEsEiDSYEIghUBAQQBViMQCzQSFBgNJIgcBboJiwmFOwOIQpV3hHqBWIMHgUE X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="207820899" Received: from 108-175-230-88.dsl.teksavvy.com (HELO pastel.home) ([108.175.230.88]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 16 Nov 2012 16:49:23 -0500 Received: by pastel.home (Postfix, from userid 20848) id D90E659346; Fri, 16 Nov 2012 16:49:22 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Message-ID: References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <83625549o1.fsf@gnu.org> Date: Fri, 16 Nov 2012 16:49:22 -0500 In-Reply-To: <83625549o1.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 16 Nov 2012 21:42:06 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12908 Cc: lekktu@gmail.com, 12908@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >> And I'm thinking that the default location should perhaps be >> somewhere under .emacs.d, perhaps with the dir that is currently used >> as the default recorded somehow. > This is dangerous, because accessing the home directory may involve > Lisp evaluation, e.g. if that directory is remote. If the ~/.emacs.d is under some file-handler like Tramp, then we're out of luck, but I wouldn't worry about it. Just pass the file names to the OS's functions and if it can't handle them, then you'll get a write error and that's that (we have to handle that case anyway). Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 02:23:06 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 07:23:06 +0000 Received: from localhost ([127.0.0.1]:50160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZck6-0005Ox-DG for submit@debbugs.gnu.org; Sat, 17 Nov 2012 02:23:06 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:60875) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZck3-0005Op-PE for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 02:23:05 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDM00K00EXC6200@a-mtaout22.012.net.il> for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 09:22:11 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDM00KFEF4Z4240@a-mtaout22.012.net.il>; Sat, 17 Nov 2012 09:22:11 +0200 (IST) Date: Sat, 17 Nov 2012 09:21:42 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: <263AC1B3AE7347CEAA88A5723B1C7A7F@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83zk2g3da1.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <838va14blm.fsf@gnu.org> <5F469B1E1F824FA8B16159BB2E0DE869@us.oracle.com> <837gpl49t6.fsf@gnu.org> <263AC1B3AE7347CEAA88A5723B1C7A7F@us.oracle.com> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org>, <12908-done@debbugs.gnu.org> > Date: Fri, 16 Nov 2012 12:56:55 -0800 > > > > That does not seem very friendly (or useful) on the part of Emacs. > > > > There are gobs of programs writing to your disk right now, without > > asking for your permission. What's so unfriendly in Emacs doing the > > same? > > I don't have gobs of programs writing to arbitrary directories, especially > directories with user files. AFAIK, I have NO programs doing that. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org>, <12908-done@debbugs.gnu.org> > Date: Fri, 16 Nov 2012 12:56:55 -0800 > > > > That does not seem very friendly (or useful) on the part of Emacs. > > > > There are gobs of programs writing to your disk right now, without > > asking for your permission. What's so unfriendly in Emacs doing the > > same? > > I don't have gobs of programs writing to arbitrary directories, especially > directories with user files. AFAIK, I have NO programs doing that. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org>, <12908-done@debbugs.gnu.org> > Date: Fri, 16 Nov 2012 12:56:55 -0800 > > > > That does not seem very friendly (or useful) on the part of Emacs. > > > > There are gobs of programs writing to your disk right now, without > > asking for your permission. What's so unfriendly in Emacs doing the > > same? > > I don't have gobs of programs writing to arbitrary directories, especially > directories with user files. AFAIK, I have NO programs doing that. Yes, you do. You just don't know that. If you are really interested, you could try walking the process tree with Process Explorer and looking at the files they have open and amount of I/O on those files. > > Please submit another bug report, which is not Windows specific > > and not about the documentation of this file. If the general Emacs > > behavior changes, so will its behavior on Windows. > > Done (#12911). But it is you, not I, who chooses to characterizes this bug as > being about only doc and only MS Windows. Please reread the subject line. The details of the same feature on Unix were already in NEWS and in the manual, and emacs_backtrace.txt is a Windows-only file name (it has different names on Unix, as documented in the manual). So I don't see how your original report could have been interpreted in any other way than I did. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 02:24:36 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 07:24:36 +0000 Received: from localhost ([127.0.0.1]:50164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZclX-0005RR-P3 for submit@debbugs.gnu.org; Sat, 17 Nov 2012 02:24:35 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:38173) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZclV-0005RJ-JZ for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 02:24:34 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDM00L00F1EWA00@a-mtaout20.012.net.il> for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 09:23:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDM00LA4F7HRJ50@a-mtaout20.012.net.il>; Sat, 17 Nov 2012 09:23:41 +0200 (IST) Date: Sat, 17 Nov 2012 09:23:12 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83y5i03d7j.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <83625549o1.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: , <12908@debbugs.gnu.org> > Date: Fri, 16 Nov 2012 13:02:27 -0800 > > > > And I'm thinking that the default location should perhaps > > > be somewhere under .emacs.d, perhaps with the dir that is > > > currently used as the default recorded somehow. > > > > This is dangerous, because accessing the home directory may involve > > Lisp evaluation, e.g. if that directory is remote. This facility must > > be as simple and close to the bare metal as possible, or else it will > > be more trouble than help. > > Then put it under the Emacs installation directory. > > The point is to get it away from user files. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12908 Cc: lekktu@gmail.com, 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: , <12908@debbugs.gnu.org> > Date: Fri, 16 Nov 2012 13:02:27 -0800 > > > > And I'm thinking that the default location should perhaps > > > be somewhere under .emacs.d, perhaps with the dir that is > > > currently used as the default recorded somehow. > > > > This is dangerous, because accessing the home directory may involve > > Lisp evaluation, e.g. if that directory is remote. This facility must > > be as simple and close to the bare metal as possible, or else it will > > be more trouble than help. > > Then put it under the Emacs installation directory. > > The point is to get it away from user files. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] > From: "Drew Adams" > Cc: , <12908@debbugs.gnu.org> > Date: Fri, 16 Nov 2012 13:02:27 -0800 > > > > And I'm thinking that the default location should perhaps > > > be somewhere under .emacs.d, perhaps with the dir that is > > > currently used as the default recorded somehow. > > > > This is dangerous, because accessing the home directory may involve > > Lisp evaluation, e.g. if that directory is remote. This facility must > > be as simple and close to the bare metal as possible, or else it will > > be more trouble than help. > > Then put it under the Emacs installation directory. > > The point is to get it away from user files. Again, I just mimicked the behavior on Unix, as best as possible. Please read the manual to learn where this information is put on Unix. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 02:29:07 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 07:29:07 +0000 Received: from localhost ([127.0.0.1]:50175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZcpv-0005Xx-91 for submit@debbugs.gnu.org; Sat, 17 Nov 2012 02:29:07 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:61967) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZcps-0005Xq-Ma for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 02:29:05 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MDM00K00F897500@a-mtaout22.012.net.il> for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 09:28:13 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDM00KAOFF04250@a-mtaout22.012.net.il>; Sat, 17 Nov 2012 09:28:13 +0200 (IST) Date: Sat, 17 Nov 2012 09:27:43 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83vcd43d00.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <83625549o1.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: Drew Adams , lekktu@gmail.com, 12908@debbugs.gnu.org > Date: Fri, 16 Nov 2012 16:49:22 -0500 > > >> And I'm thinking that the default location should perhaps be > >> somewhere under .emacs.d, perhaps with the dir that is currently used > >> as the default recorded somehow. > > This is dangerous, because accessing the home directory may involve > > Lisp evaluation, e.g. if that directory is remote. > > If the ~/.emacs.d is under some file-handler like Tramp, then we're out > of luck, but I wouldn't worry about it. Just pass the file names to the > OS's functions and if it can't handle them, then you'll get a write > error and that's that (we have to handle that case anyway). [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12908 Cc: lekktu@gmail.com, 12908@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: Drew Adams , lekktu@gmail.com, 12908@debbugs.gnu.org > Date: Fri, 16 Nov 2012 16:49:22 -0500 > > >> And I'm thinking that the default location should perhaps be > >> somewhere under .emacs.d, perhaps with the dir that is currently used > >> as the default recorded somehow. > > This is dangerous, because accessing the home directory may involve > > Lisp evaluation, e.g. if that directory is remote. > > If the ~/.emacs.d is under some file-handler like Tramp, then we're out > of luck, but I wouldn't worry about it. Just pass the file names to the > OS's functions and if it can't handle them, then you'll get a write > error and that's that (we have to handle that case anyway). [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4728] > From: Stefan Monnier > Cc: Drew Adams , lekktu@gmail.com, 12908@debbugs.gnu.org > Date: Fri, 16 Nov 2012 16:49:22 -0500 > > >> And I'm thinking that the default location should perhaps be > >> somewhere under .emacs.d, perhaps with the dir that is currently used > >> as the default recorded somehow. > > This is dangerous, because accessing the home directory may involve > > Lisp evaluation, e.g. if that directory is remote. > > If the ~/.emacs.d is under some file-handler like Tramp, then we're out > of luck, but I wouldn't worry about it. Just pass the file names to the > OS's functions and if it can't handle them, then you'll get a write > error and that's that (we have to handle that case anyway). Fine with me. I will change the Windows code when the Unix code is changed along these lines. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 11:37:56 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 16:37:57 +0000 Received: from localhost ([127.0.0.1]:51089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZlP2-0005Ui-NX for submit@debbugs.gnu.org; Sat, 17 Nov 2012 11:37:56 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:22249) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZlP0-0005UW-VV for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 11:37:55 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAHGb0bu014079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Nov 2012 16:37:01 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAHGaxc6005681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2012 16:37:00 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAHGaxgj015690; Sat, 17 Nov 2012 10:36:59 -0600 Received: from dradamslap1 (/10.159.226.12) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Nov 2012 08:36:59 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <83625549o1.fsf@gnu.org> <83y5i03d7j.fsf@gnu.org> Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Sat, 17 Nov 2012 08:36:52 -0800 Message-ID: <3F1572E6BD6046649786AD0DD7B93FF2@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83y5i03d7j.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac3ElHkgnt5SS6UPTWGldTDPgwHAogATSJyw X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12908 Cc: lekktu@gmail.com, 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > > Then put it under the Emacs installation directory. > > The point is to get it away from user files. > > Again, I just mimicked the behavior on Unix, as best as possible. > Please read the manual to learn where this information is put on Unix. No one is blaming you, and certainly not for making things consistent with what is done on Unix. You have pointed out that the bug (annoyance) exists on Unix also. Fine. So let's correct it everywhere. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 11:38:01 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 16:38:01 +0000 Received: from localhost ([127.0.0.1]:51091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZlP6-0005Ut-Ul for submit@debbugs.gnu.org; Sat, 17 Nov 2012 11:38:01 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:42597) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZlP1-0005UY-Qq for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 11:37:56 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAHGb01c003851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Nov 2012 16:37:01 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAHGaxG1005683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2012 16:37:00 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAHGaxOt015693; Sat, 17 Nov 2012 10:36:59 -0600 Received: from dradamslap1 (/10.159.226.12) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Nov 2012 08:36:59 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <838va14blm.fsf@gnu.org> <5F469B1E1F824FA8B16159BB2E0DE869@us.oracle.com> <837gpl49t6.fsf@gnu.org> <263AC1B3AE7347CEAA88A5723B1C7A7F@us.oracle.com> <83zk2g3da1.fsf@gnu.org> Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Sat, 17 Nov 2012 08:36:52 -0800 Message-ID: <2DF469FAADEF449EB3AD69FD92F43C57@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83zk2g3da1.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac3ElEQUlZZPgoXxQiiPXgsBKlzVBwAS2e3w X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > > > > That does not seem very friendly (or useful) on the > > > > part of Emacs. > > > > > > There are gobs of programs writing to your disk right now, > > > without asking for your permission. What's so unfriendly > > > in Emacs doing the same? > > > > I don't have gobs of programs writing to arbitrary > > directories, especially directories with user files. > > AFAIK, I have NO programs doing that. > > Yes, you do. You just don't know that. If you are really interested, > you could try walking the process tree with Process Explorer and > looking at the files they have open and amount of I/O on those files. Let me put it this way, since I haven't been able to make it clear enough so far: I do not _se+_ files created in my user folders. If there are such files created, whether temporarily or permanently, I am unaware of it. Not so with emacs_backtrace.txt files. That is the point: the behavior that users witness - the user experience. I will not argue with you that there no such files are ever created by other programs. I will say that I don't see any such. Nothing about what other programs are doing is annoying in this respect. If you want to make Emacs not be annoying in the same way, please do. It is the user-level annoyance that this bug report is about. Users do not know or care about the implementation level at which you are examining the issue. Your answers do not address the issue, which is user annoyance at the _obvious_ creation of uninvited files in their folders. You may prove that I misunderstand this or that about what other programs do under the covers, but you are missing the point: what users see (and will be annoyed by). > > > Please submit another bug report, which is not Windows specific > > > and not about the documentation of this file. If the > > > general Emacs behavior changes, so will its behavior on Windows. > > > > Done (#12911). But it is you, not I, who chooses to > > characterizes this bug as being about only doc and only > > MS Windows. Please reread the subject line. > > The details of the same feature on Unix were already in NEWS and in > the manual, and emacs_backtrace.txt is a Windows-only file name (it > has different names on Unix, as documented in the manual). So I don't > see how your original report could have been interpreted in any other > way than I did. Even when the OP informs you that your interpretation is wrong (too limited)? Anyway, there is now another bug for the annoyance, and thank you for documenting the annoyance. I have no problem with splitting the bug report that way. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 13:45:57 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 18:45:57 +0000 Received: from localhost ([127.0.0.1]:51235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZnOv-0008No-DT for submit@debbugs.gnu.org; Sat, 17 Nov 2012 13:45:57 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:52086) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZnOs-0008Nf-9D for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 13:45:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id D3250A60018 for <12908@debbugs.gnu.org>; Sat, 17 Nov 2012 10:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXxSqjvCY5Ic for <12908@debbugs.gnu.org>; Sat, 17 Nov 2012 10:44:59 -0800 (PST) Received: from [192.168.1.3] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 83622A60017 for <12908@debbugs.gnu.org>; Sat, 17 Nov 2012 10:44:59 -0800 (PST) Message-ID: <50A7DB2C.7050501@cs.ucla.edu> Date: Sat, 17 Nov 2012 10:45:00 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: 12908@debbugs.gnu.org Subject: Re: 24.3.50; file `emacs_backtrace.txt'? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 12908 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) There seems to be some misunderstanding here. The Unix code does not write into $HOME/backtrace.txt, or into $HOME, or into anywhere like that. It writes to stderr. The programs that invoke Emacs (normally window managers) arrange for the standard error stream to be sent to a suitable place. The Microsoft Windows code does something different: it writes the backtrace both to stderr and to a file emacs_backtrace.txt. If the goal is to mimic the Unix behavior as closely as possible, then the fix should be simple: output the backtrace just to stderr, as the Unix code does. Perhaps there are reasons not to do that on Microsoft Windows, but as these reasons are specific to that platform it would seem that any fix would be platform-specific as well. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 14:10:54 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 19:10:54 +0000 Received: from localhost ([127.0.0.1]:51286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZnn3-0001Sj-O0 for submit@debbugs.gnu.org; Sat, 17 Nov 2012 14:10:54 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:57988) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZnn0-0001SX-UX for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 14:10:52 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MDN00A00BOIOG00@a-mtaout21.012.net.il> for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 21:09:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDN00A9YBWJ6CP0@a-mtaout21.012.net.il>; Sat, 17 Nov 2012 21:09:55 +0200 (IST) Date: Sat, 17 Nov 2012 21:09:27 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: <50A7DB2C.7050501@cs.ucla.edu> X-012-Sender: halo1@inter.net.il To: Paul Eggert Message-id: <8339082gig.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sat, 17 Nov 2012 10:45:00 -0800 > From: Paul Eggert > > There seems to be some misunderstanding here. The Unix code does > not write into $HOME/backtrace.txt, or into $HOME, or into anywhere > like that. It writes to stderr. The programs that invoke Emacs > (normally window managers) arrange for the standard error stream > to be sent to a suitable place. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sat, 17 Nov 2012 10:45:00 -0800 > From: Paul Eggert > > There seems to be some misunderstanding here. The Unix code does > not write into $HOME/backtrace.txt, or into $HOME, or into anywhere > like that. It writes to stderr. The programs that invoke Emacs > (normally window managers) arrange for the standard error stream > to be sent to a suitable place. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] > Date: Sat, 17 Nov 2012 10:45:00 -0800 > From: Paul Eggert > > There seems to be some misunderstanding here. The Unix code does > not write into $HOME/backtrace.txt, or into $HOME, or into anywhere > like that. It writes to stderr. The programs that invoke Emacs > (normally window managers) arrange for the standard error stream > to be sent to a suitable place. That suitable place is in a subdirectory of the user's home directory, at least on the most popular systems, according to the Emacs manual. > The Microsoft Windows code does something different: it writes the > backtrace both to stderr and to a file emacs_backtrace.txt. Yes. > If the goal is to mimic the Unix behavior as closely as possible, then > the fix should be simple: output the backtrace just to stderr, as > the Unix code does. This will not work: unlike Unix, a GUI program invoked on Windows from a desktop icon normally has its standard error stream closed. So writing there will end up nowhere. That is why my implementation writes both to stderr and to the file; in the worst (or best?) case, you have two copies of the information, but you always have at least one. > Perhaps there are reasons not to do that on Microsoft Windows, but > as these reasons are specific to that platform it would seem that > any fix would be platform-specific as well. I don't see it that way. If what the Unix code writes to stderr ends up in some random location under the user's home directory, or even in a place whose whereabouts no one knows, then I see no reason not to write it on Windows in the current directory of the Emacs process. (Note that unlike on Unix, Emacs on Windows doesn't change its current directory from where it was started, so the backtrace will normally end up in the same directory for all invocations of Emacs on that machine by that user.) If we want the information in .emacs.d, we need to actively write it there on Unix. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 14:30:44 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 19:30:44 +0000 Received: from localhost ([127.0.0.1]:51316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZo6G-0001vX-B0 for submit@debbugs.gnu.org; Sat, 17 Nov 2012 14:30:44 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:53392) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZo6D-0001vP-MC for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 14:30:42 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 9D661A60017; Sat, 17 Nov 2012 11:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouzLir6lQcpt; Sat, 17 Nov 2012 11:29:47 -0800 (PST) Received: from [192.168.1.3] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 0EA67A60001; Sat, 17 Nov 2012 11:29:47 -0800 (PST) Message-ID: <50A7E5AB.3040006@cs.ucla.edu> Date: Sat, 17 Nov 2012 11:29:47 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> In-Reply-To: <8339082gig.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) On 11/17/2012 11:09 AM, Eli Zaretskii wrote: > That suitable place is in a subdirectory of the user's home directory, > at least on the most popular systems, according to the Emacs manual. Sure, but it's under the user's control, and it's easy to change the default. I'm not a typical user, but I'd guess that about half the time I put stderr some place other than the default, because I start up Emacs from a terminal session or suchlike. And when Emacs is being debugged, stderr is almost never put into a home-directory file. > unlike Unix, a GUI program invoked on Windows > from a desktop icon normally has its standard error stream closed. This is a problem not just for backtraces, but for everything that Emacs sends to stderr. Perhaps it would be better for Emacs, on Microsoft Windows, to redirect stderr to a file, so that the information does not get lost. That file would serve the function that emacs_backtrace.txt serves now, but it would also capture all the other stuff that goes to stderr and currently gets lost. Even if we continue to restrict the contents of the file to backtraces, the name of this file is something that is specific to the Microsoft Windows version of Emacs, so the GNU and Unix versions don't have to worry about the file's name. > (Note that unlike on Unix, Emacs on Windows doesn't change its current > directory from where it was started No, Emacs is the same on both platforms. The main Emacs process doesn't invoke chdir on GNU or Unix either, unless you use the --chdir option. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 14:44:00 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 19:44:00 +0000 Received: from localhost ([127.0.0.1]:51324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZoJ5-0002Eo-JI for submit@debbugs.gnu.org; Sat, 17 Nov 2012 14:43:59 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:59481) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZoJ2-0002Ee-4x for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 14:43:57 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDN00500CQE5600@a-mtaout20.012.net.il> for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 21:43:01 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDN004LXDFMTDA0@a-mtaout20.012.net.il>; Sat, 17 Nov 2012 21:42:59 +0200 (IST) Date: Sat, 17 Nov 2012 21:42:31 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: <50A7E5AB.3040006@cs.ucla.edu> X-012-Sender: halo1@inter.net.il To: Paul Eggert Message-id: <83zk2g10ew.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sat, 17 Nov 2012 11:29:47 -0800 > From: Paul Eggert > CC: 12908@debbugs.gnu.org > > On 11/17/2012 11:09 AM, Eli Zaretskii wrote: > > > That suitable place is in a subdirectory of the user's home directory, > > at least on the most popular systems, according to the Emacs manual. > > Sure, but it's under the user's control, and it's easy to > change the default. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sat, 17 Nov 2012 11:29:47 -0800 > From: Paul Eggert > CC: 12908@debbugs.gnu.org > > On 11/17/2012 11:09 AM, Eli Zaretskii wrote: > > > That suitable place is in a subdirectory of the user's home directory, > > at least on the most popular systems, according to the Emacs manual. > > Sure, but it's under the user's control, and it's easy to > change the default. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4998] > Date: Sat, 17 Nov 2012 11:29:47 -0800 > From: Paul Eggert > CC: 12908@debbugs.gnu.org > > On 11/17/2012 11:09 AM, Eli Zaretskii wrote: > > > That suitable place is in a subdirectory of the user's home directory, > > at least on the most popular systems, according to the Emacs manual. > > Sure, but it's under the user's control, and it's easy to > change the default. Unless we are going to ask each Emacs user to change the default so that the file ends up in .emacs.d, we still have a discrepancy vs what Stefan asked to do. > > unlike Unix, a GUI program invoked on Windows > > from a desktop icon normally has its standard error stream closed. > > This is a problem not just for backtraces, but for everything that > Emacs sends to stderr. Which is nothing on Windows, except in debug builds with non-default options turned on, which are used only by experts (who know how not to lose this stuff). > Perhaps it would be better for Emacs, on Microsoft Windows, to > redirect stderr to a file, so that the information does not get > lost. It's not easy to do that, and it isn't worth the trouble, see above. But if someone volunteers to do that, my hat's off. Until then, we cannot safely use stderr on Windows for information we cannot afford losing. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 16:26:18 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 21:26:18 +0000 Received: from localhost ([127.0.0.1]:51435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZpu3-0004ZN-Ep for submit@debbugs.gnu.org; Sat, 17 Nov 2012 16:26:17 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:56633) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZptz-0004ZB-1J for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 16:26:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 2191AA60017; Sat, 17 Nov 2012 13:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reajfedXQeYR; Sat, 17 Nov 2012 13:25:15 -0800 (PST) Received: from [192.168.1.3] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id B6FA5A60001; Sat, 17 Nov 2012 13:25:15 -0800 (PST) Message-ID: <50A800BD.2@cs.ucla.edu> Date: Sat, 17 Nov 2012 13:25:17 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> In-Reply-To: <83zk2g10ew.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) On 11/17/2012 11:42 AM, Eli Zaretskii wrote: > Unless we are going to ask each Emacs user to change the default so > that the file ends up in .emacs.d, we still have a discrepancy vs what > Stefan asked to do. I must have missed that request; all I see from him in Bug#12908 is a comment about how to deal with the file names under the assumption that Emacs itself redirects stderr to a file whose name Emacs chooses. That assumption is currently true on Microsoft Windows for backtraces, but it's not true for GNU and Unix where we don't have the problem. >> Perhaps it would be better for Emacs, on Microsoft Windows, to >> redirect stderr to a file, so that the information does not get >> lost. > > It's not easy to do that Can Emacs use freopen? For example, the following code would do the job on a POSIX platform: if stderr is closed, it redirects it to emacs-stderr.txt in the current directory, if possible. Would this sort of thing work on Microsoft platform? === modified file 'src/emacs.c' --- src/emacs.c 2012-11-08 19:12:23 +0000 +++ src/emacs.c 2012-11-17 21:23:46 +0000 @@ -748,6 +748,11 @@ main (int argc, char **argv) unexec_init_emacs_zone (); #endif +#ifdef DOS_NT + if (dup2 (STDERR_FILENO, STDERR_FILENO) < 0) + ignore_value (freopen ("emacs-stderr.txt", "a", stderr)); +#endif + atexit (close_output_streams); sort_args (argc, argv); From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 18:02:58 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 23:02:58 +0000 Received: from localhost ([127.0.0.1]:51493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZrPd-0006iR-Uj for submit@debbugs.gnu.org; Sat, 17 Nov 2012 18:02:58 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:48671) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZrPa-0006iI-TA for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 18:02:56 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAHN1pt3015187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Nov 2012 23:01:52 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAHN1oNF014602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2012 23:01:50 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAHN1mC4029825; Sat, 17 Nov 2012 17:01:49 -0600 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Nov 2012 15:01:48 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" , "'Paul Eggert'" References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com><50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Sat, 17 Nov 2012 15:01:40 -0800 Message-ID: <753BC08DCC9A446BB22336EDB8AF31CF@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8339082gig.fsf@gnu.org> Thread-Index: Ac3E9y3ragTSqYNiRSOP9JYo6I8CxgAHy8HA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) (I see that everyone is using the original bug thread, even though I created a new one at Eli's request, and the original one was supposedly closed (doc fixed).) > (Note that unlike on Unix, Emacs on Windows doesn't change its current > directory from where it was started, so the backtrace will normally > end up in the same directory for all invocations of Emacs on that > machine by that user.) > > If we want the information in .emacs.d, we need to actively write it > there on Unix. On Windows, I believe that some (many? most?) users start Emacs from a shortcut, and that some (many? most?) of those start it in a directory that has meaning for them, e.g., a directory of user files. (I, for example, start it in a directory of my Emacs Lisp files, and I open it with Dired there.) Is the situation similar on Unix? Do users often start Emacs in a user directory? It's one thing to stick the backtrace file in the startup directory if that is the default Emacs bin directory or some such Emacs-related folder. It's another thing to stick the file in a user directory because the user intentionally starts Emacs there. That has been my point from the beginning: I don't really care where you stick it, as long as it is in some Emacs/system internal program folder and not a user folder. There is a reason why programs on Windows are often installed (and started) in an application-specific folder under `Program Files', and not in any old user folder. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 18:09:25 2012 Received: (at 12908) by debbugs.gnu.org; 17 Nov 2012 23:09:25 +0000 Received: from localhost ([127.0.0.1]:51500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZrVt-0006r8-5S for submit@debbugs.gnu.org; Sat, 17 Nov 2012 18:09:25 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:36281) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZrVr-0006qw-36; Sat, 17 Nov 2012 18:09:23 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAHN8QD7018088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Nov 2012 23:08:27 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAHN8P3a010912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2012 23:08:26 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAHN8Pb9021417; Sat, 17 Nov 2012 17:08:25 -0600 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Nov 2012 15:08:25 -0800 From: "Drew Adams" To: "'Paul Eggert'" , "'Eli Zaretskii'" References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com><50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org><50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Sat, 17 Nov 2012 15:08:17 -0800 Message-ID: <0D5E662929EB46BABC33674094EA6A24@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <50A800BD.2@cs.ucla.edu> Thread-Index: Ac3FCi5B+BsyMFPLQSC5tWeGjwiO4wADdi8A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 12908 Cc: 12911@debbugs.gnu.org, 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > > Unless we are going to ask each Emacs user to change the default so > > that the file ends up in .emacs.d, we still have a > > discrepancy vs what Stefan asked to do. > > I must have missed that request; all I see from him in Bug#12908 > is a comment about how to deal with the file names That's because Stefan wrote it in the proper bug thread, and not in this one (which Eli asked us to abandon (but which he too continues to populate)): > From: Stefan Monnier Sent: Friday, November 16, 2012 1:20 PM > To: Drew Adams Cc: 12911@debbugs.gnu.org > Subject: Re: bug#12911: 24.3.50; let users decide where (& > perhaps whether) `emacs_backtrace.txt' files are written > > > If such user control is not possible, then please confine > > such files to somewhere under .emacs.d or some other > > "hidden" directory that is > > Agreed: writing the file into ~/.emacs.d makes a lot more sense. > > Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 20:12:57 2012 Received: (at 12908) by debbugs.gnu.org; 18 Nov 2012 01:12:57 +0000 Received: from localhost ([127.0.0.1]:51672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZtRR-00020N-Hj for submit@debbugs.gnu.org; Sat, 17 Nov 2012 20:12:57 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:34497) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZtRO-00020F-Qo for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 20:12:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id E887EA60017; Sat, 17 Nov 2012 17:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQIZGLnaKRfv; Sat, 17 Nov 2012 17:11:58 -0800 (PST) Received: from [192.168.1.3] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 5FFE6A60001; Sat, 17 Nov 2012 17:11:58 -0800 (PST) Message-ID: <50A835E1.3080508@cs.ucla.edu> Date: Sat, 17 Nov 2012 17:12:01 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com><50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org><50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> <0D5E662929EB46BABC33674094EA6A24@us.oracle.com> In-Reply-To: <0D5E662929EB46BABC33674094EA6A24@us.oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 12908 Cc: 'Eli Zaretskii' , 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) On 11/17/2012 03:08 PM, Drew Adams wrote: >> I must have missed that request; all I see from him in Bug#12908 >> > is a comment about how to deal with the file names > That's because Stefan wrote it in the proper bug thread, and not in this one Ah, OK, I'll respond there. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 20:25:00 2012 Received: (at 12908) by debbugs.gnu.org; 18 Nov 2012 01:25:00 +0000 Received: from localhost ([127.0.0.1]:51682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZtd5-0002H6-J1 for submit@debbugs.gnu.org; Sat, 17 Nov 2012 20:25:00 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:34812) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZtd3-0002Gy-Dg for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 20:24:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id DC9FAA60017; Sat, 17 Nov 2012 17:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfzOxelrcCin; Sat, 17 Nov 2012 17:24:01 -0800 (PST) Received: from [192.168.1.3] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 51810A60001; Sat, 17 Nov 2012 17:24:01 -0800 (PST) Message-ID: <50A838B4.6010503@cs.ucla.edu> Date: Sat, 17 Nov 2012 17:24:04 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Drew Adams Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com><50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <753BC08DCC9A446BB22336EDB8AF31CF@us.oracle.com> In-Reply-To: <753BC08DCC9A446BB22336EDB8AF31CF@us.oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 12908 Cc: Eli Zaretskii , 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) On 11/17/2012 03:01 PM, Drew Adams wrote: > Is the situation similar on Unix? Do users often start Emacs in a user > directory? Yes, that's common. But it doesn't lead to backtrace files appearing in user directories, because Emacs does not create backtrace files on Unix; it merely writes the backtraces to stderr. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 22:58:19 2012 Received: (at 12908) by debbugs.gnu.org; 18 Nov 2012 03:58:19 +0000 Received: from localhost ([127.0.0.1]:51802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZw1T-0006lO-CV for submit@debbugs.gnu.org; Sat, 17 Nov 2012 22:58:19 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:45106) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZw1Q-0006lD-Kl; Sat, 17 Nov 2012 22:58:17 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDN00900ZYKCF00@a-mtaout20.012.net.il>; Sun, 18 Nov 2012 05:57:20 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDO0080J0BJXNI0@a-mtaout20.012.net.il>; Sun, 18 Nov 2012 05:57:20 +0200 (IST) Date: Sun, 18 Nov 2012 05:56:53 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: <0D5E662929EB46BABC33674094EA6A24@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83haon1s3e.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> <0D5E662929EB46BABC33674094EA6A24@us.oracle.com> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org>, <12911@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 15:08:17 -0800 > > > > Unless we are going to ask each Emacs user to change the default so > > > that the file ends up in .emacs.d, we still have a > > > discrepancy vs what Stefan asked to do. > > > > I must have missed that request; all I see from him in Bug#12908 > > is a comment about how to deal with the file names > > That's because Stefan wrote it in the proper bug thread, and not in this one > (which Eli asked us to abandon (but which he too continues to populate)): [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4998] X-Debbugs-Envelope-To: 12908 Cc: eggert@cs.ucla.edu, 12911@debbugs.gnu.org, 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org>, <12911@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 15:08:17 -0800 > > > > Unless we are going to ask each Emacs user to change the default so > > > that the file ends up in .emacs.d, we still have a > > > discrepancy vs what Stefan asked to do. > > > > I must have missed that request; all I see from him in Bug#12908 > > is a comment about how to deal with the file names > > That's because Stefan wrote it in the proper bug thread, and not in this one > (which Eli asked us to abandon (but which he too continues to populate)): I just reply to messages of others. I cannot afford reading the headers, nor keeping in mind all the bug numbers. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 22:59:46 2012 Received: (at 12908) by debbugs.gnu.org; 18 Nov 2012 03:59:46 +0000 Received: from localhost ([127.0.0.1]:51809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZw2r-0006nc-Tp for submit@debbugs.gnu.org; Sat, 17 Nov 2012 22:59:46 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:45328) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZw2r-0006nW-13 for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 22:59:45 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDN00900ZYKCF00@a-mtaout20.012.net.il> for 12908@debbugs.gnu.org; Sun, 18 Nov 2012 05:58:48 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDO008W10E0XNI0@a-mtaout20.012.net.il>; Sun, 18 Nov 2012 05:58:48 +0200 (IST) Date: Sun, 18 Nov 2012 05:58:21 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: <753BC08DCC9A446BB22336EDB8AF31CF@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83fw471s0y.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <753BC08DCC9A446BB22336EDB8AF31CF@us.oracle.com> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 15:01:40 -0800 > > That has been my point from the beginning: I don't really care where > you stick it, as long as it is in some Emacs/system internal program > folder and not a user folder. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12908 Cc: eggert@cs.ucla.edu, 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 15:01:40 -0800 > > That has been my point from the beginning: I don't really care where > you stick it, as long as it is in some Emacs/system internal program > folder and not a user folder. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4827] > From: "Drew Adams" > Cc: <12908@debbugs.gnu.org> > Date: Sat, 17 Nov 2012 15:01:40 -0800 > > That has been my point from the beginning: I don't really care where > you stick it, as long as it is in some Emacs/system internal program > folder and not a user folder. On Unix, the data winds up in some directory under user's home directory. See the manual. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 23:05:52 2012 Received: (at 12908) by debbugs.gnu.org; 18 Nov 2012 04:05:53 +0000 Received: from localhost ([127.0.0.1]:51823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZw8m-0006x6-Ie for submit@debbugs.gnu.org; Sat, 17 Nov 2012 23:05:52 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:46345) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZw8l-0006x0-3e for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 23:05:51 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MDO009000NEFW00@a-mtaout20.012.net.il> for 12908@debbugs.gnu.org; Sun, 18 Nov 2012 06:04:54 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MDO0087W0O6XNM0@a-mtaout20.012.net.il>; Sun, 18 Nov 2012 06:04:54 +0200 (IST) Date: Sun, 18 Nov 2012 06:04:28 +0200 From: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? In-reply-to: <50A800BD.2@cs.ucla.edu> X-012-Sender: halo1@inter.net.il To: Paul Eggert Message-id: <83d2zb1rqr.fsf@gnu.org> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sat, 17 Nov 2012 13:25:17 -0800 > From: Paul Eggert > CC: 12908@debbugs.gnu.org > > >> Perhaps it would be better for Emacs, on Microsoft Windows, to > >> redirect stderr to a file, so that the information does not get > >> lost. > > > > It's not easy to do that > > Can Emacs use freopen? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Sat, 17 Nov 2012 13:25:17 -0800 > From: Paul Eggert > CC: 12908@debbugs.gnu.org > > >> Perhaps it would be better for Emacs, on Microsoft Windows, to > >> redirect stderr to a file, so that the information does not get > >> lost. > > > > It's not easy to do that > > Can Emacs use freopen? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4999] > Date: Sat, 17 Nov 2012 13:25:17 -0800 > From: Paul Eggert > CC: 12908@debbugs.gnu.org > > >> Perhaps it would be better for Emacs, on Microsoft Windows, to > >> redirect stderr to a file, so that the information does not get > >> lost. > > > > It's not easy to do that > > Can Emacs use freopen? That's not the problem. The problem is that stderr is used when Emacs is run in non-interactive mode, and should not be touched then. The problem is in detecting when stderr is closed or an invalid handle to begin with, and do the redirection only then. In all my readings and tests, I was unable to find a reliable, let alone documented, way of determining that. I don't even know if the "invalid handle" (which is a pointer on Windows) is NULL or an INVALID_HANDLE_VALUE. > For example, the following code would do the job on a POSIX > platform: if stderr is closed, it redirects it to emacs-stderr.txt > in the current directory, if possible. Would this sort of thing > work on Microsoft platform? It will surely break -batch. And guess what happens with this redirection when Emacs has its stderr closed or invalid in the first place. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 17 23:41:42 2012 Received: (at 12908) by debbugs.gnu.org; 18 Nov 2012 04:41:42 +0000 Received: from localhost ([127.0.0.1]:51857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZwhS-0007j6-DP for submit@debbugs.gnu.org; Sat, 17 Nov 2012 23:41:42 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:41915) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZwhQ-0007ix-0t for 12908@debbugs.gnu.org; Sat, 17 Nov 2012 23:41:41 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAI4eImt027221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Nov 2012 04:40:19 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAI4eHss025801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Nov 2012 04:40:18 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAI4eH8g007031; Sat, 17 Nov 2012 22:40:17 -0600 Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Nov 2012 20:40:17 -0800 From: "Drew Adams" To: "'Eli Zaretskii'" References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <753BC08DCC9A446BB22336EDB8AF31CF@us.oracle.com> <83fw471s0y.fsf@gnu.org> Subject: RE: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Sat, 17 Nov 2012 20:40:08 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83fw471s0y.fsf@gnu.org> Thread-Index: Ac3FQQRXWus4+czcSLqvmDQwyGX9mAAADCHg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 12908 Cc: eggert@cs.ucla.edu, 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) > > That has been my point from the beginning: I don't really care where > > you stick it, as long as it is in some Emacs/system internal program > > folder and not a user folder. > > On Unix, the data winds up in some directory under user's home > directory. See the manual. I don't care what Emacs does on Unix or on Windows. Or on Peanut Butter. See the manual - sheesh. If Emacs on Unix is just as user-inconsiderate in this regard as it is on Windows, then it too needs to be sent back for regrooving. My point is the same: Please do not plop such a file into a user folder. On any platform. It does not belong there. I just happen to be using Emacs on Windows, and I reported this problem there. If it is not Windows-specific, fine - please fix it wherever it occurs. You are discussing implementation and platforms, as well you should, no doubt. But my concern is at the user level. Please don't mess with user data. That's not nice. And this includes user folders containing user files. I really don't care about the finger-pointing. You apparently claim that there is as much of this problem on Unix as on Windows. Some others seem to disagree (though that's not too clear to me). That does not matter to me. If there is a problem on platform XYZ, please fix it on XYZ. For all XYZ, preferably. For Windows, at least. It does not sound like a great argument to say that this will not be fixed on Windows until someone agrees to fix it on Unix also. Especially if those who would presumably be the ones to fix it on Unix do not seem to agree that it is a problem on Unix (again, I'm not sure that's what the claim is). IOW, here we go 'round & 'round again. Musical chairs with a bit of blame game thrown in, it seems. I hope the bug gets fixed. On Windows, at least, this is a regression: Users have never before had to put up with this Emacs pollution of user folders. Introducing a regression and then classifying it as `wont-fix' is disingenuous. Please just restore the state before the regression if you cannot find a good way to fix the bug and still get the backtrace info you want. Restore the sane state while you go on to discuss possible ways to deal with the problem in a ideal way. If you never find that ideal way, then leave things as they were before. I really do not agree with freewheeling introduction of "improvements" that are accompanied by regressions or other negative behavior that is then classified as `wont-fix'. Be less interested in your creative development than in the possible harm/annoyance to users of its side effects. The first rule should be not to do any harm. The second rule should be that if you accidentally do some harm while trying to improve something, then undo the harm. We have users jump through 39 questions/confirmations just to send a bug-report message or exit without saving a buffer. Nice and careful, respectful of user wishes. And yet here we are now writing crap to user folders without so much as a "Do you really want to...?" - or even a "Hey, I just wrote some crap to your folder XYZ - sorry about that!" From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 00:19:58 2012 Received: (at 12908) by debbugs.gnu.org; 18 Nov 2012 05:19:59 +0000 Received: from localhost ([127.0.0.1]:51901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZxIU-00007q-Nq for submit@debbugs.gnu.org; Sun, 18 Nov 2012 00:19:58 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:40378) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZxIR-00007i-Q2 for 12908@debbugs.gnu.org; Sun, 18 Nov 2012 00:19:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 51443A60001; Sat, 17 Nov 2012 21:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKVeFo8kbwUA; Sat, 17 Nov 2012 21:18:58 -0800 (PST) Received: from [192.168.1.3] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id D391AA60017; Sat, 17 Nov 2012 21:18:58 -0800 (PST) Message-ID: <50A86FC6.6080009@cs.ucla.edu> Date: Sat, 17 Nov 2012 21:19:02 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <753BC08DCC9A446BB22336EDB8AF31CF@us.oracle.com> <83fw471s0y.fsf@gnu.org> In-Reply-To: <83fw471s0y.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) On 11/17/2012 07:58 PM, Eli Zaretskii wrote: > On Unix, the data winds up in some directory under user's home > directory. No, on Unix that data is sent to the standard error stream. This is documented in the manual. It's common that stderr is redirected to a file, but it's also common that it's not. Traditionally it's not, and many people commonly run Emacs that way. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 00:20:33 2012 Received: (at 12908) by debbugs.gnu.org; 18 Nov 2012 05:20:34 +0000 Received: from localhost ([127.0.0.1]:51905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZxJ3-000099-03 for submit@debbugs.gnu.org; Sun, 18 Nov 2012 00:20:33 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:40395) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZxIz-000090-Ir for 12908@debbugs.gnu.org; Sun, 18 Nov 2012 00:20:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 4212EA60017; Sat, 17 Nov 2012 21:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9-ojewmfI4y; Sat, 17 Nov 2012 21:19:32 -0800 (PST) Received: from [192.168.1.3] (pool-71-189-154-249.lsanca.fios.verizon.net [71.189.154.249]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id A2F01A60001; Sat, 17 Nov 2012 21:19:32 -0800 (PST) Message-ID: <50A86FE8.4020203@cs.ucla.edu> Date: Sat, 17 Nov 2012 21:19:36 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <50A7E5AB.3040006@cs.ucla.edu> <83zk2g10ew.fsf@gnu.org> <50A800BD.2@cs.ucla.edu> <83d2zb1rqr.fsf@gnu.org> In-Reply-To: <83d2zb1rqr.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 12908 Cc: 12908@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) On 11/17/2012 08:04 PM, Eli Zaretskii wrote: > The > problem is in detecting when stderr is closed or an invalid handle to > begin with, and do the redirection only then. In all my readings and > tests, I was unable to find a reliable, let alone documented, way of > determining that. The method I gave in is portable to GNU and POSIXish hosts, where you can test whether a file descriptor FD is valid by invoking dup2 (FD, FD). Gnulib has a dup2 implementation that works on Microsoft Windows, so if we use that, it seems we should be able to use the same idea there too. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 18 02:10:12 2012 Received: (at submit) by debbugs.gnu.org; 18 Nov 2012 07:10:12 +0000 Received: from localhost ([127.0.0.1]:51983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZz1A-0002pD-3E for submit@debbugs.gnu.org; Sun, 18 Nov 2012 02:10:12 -0500 Received: from eggs.gnu.org ([208.118.235.92]:40676) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZz17-0002p5-5t for submit@debbugs.gnu.org; Sun, 18 Nov 2012 02:10:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZz09-0008UZ-LN for submit@debbugs.gnu.org; Sun, 18 Nov 2012 02:09:12 -0500 Received: from lists.gnu.org ([208.118.235.17]:45035) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZz09-0008UV-I2 for submit@debbugs.gnu.org; Sun, 18 Nov 2012 02:09:09 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZz06-0006RA-DE for bug-gnu-emacs@gnu.org; Sun, 18 Nov 2012 02:09:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZz03-0008Ky-B0 for bug-gnu-emacs@gnu.org; Sun, 18 Nov 2012 02:09:06 -0500 Received: from plane.gmane.org ([80.91.229.3]:33972) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZz03-0008Kf-4W for bug-gnu-emacs@gnu.org; Sun, 18 Nov 2012 02:09:03 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TZz08-0002R1-NM for bug-gnu-emacs@gnu.org; Sun, 18 Nov 2012 08:09:08 +0100 Received: from pd9eb2a60.dip.t-dialin.net ([217.235.42.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Nov 2012 08:09:08 +0100 Received: from Stromeko by pd9eb2a60.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Nov 2012 08:09:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Achim Gratz Subject: Re: bug#12908: 24.3.50; file `emacs_backtrace.txt'? Date: Sun, 18 Nov 2012 08:08:47 +0100 Organization: Linux Private Site Lines: 15 Message-ID: <87ip931j7k.fsf@Rainer.invalid> References: <4B9EFDFEE27E43DBB6331605DD7C2842@us.oracle.com> <50A7DB2C.7050501@cs.ucla.edu> <8339082gig.fsf@gnu.org> <753BC08DCC9A446BB22336EDB8AF31CF@us.oracle.com> <83fw471s0y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pd9eb2a60.dip.t-dialin.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) Cancel-Lock: sha1:TTZauMEJ0sVBksvRY59CVt1ALc4= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.0 (-----) Eli Zaretskii writes: > On Unix, the data winds up in some directory under user's home > directory. See the manual. That happens only if STDERR is redirected to a file, which is indeed commonly the case when a wrapper script starts Emacs on a GUI. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds From unknown Mon Aug 11 12:54:33 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 16 Dec 2012 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator