From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Newsgroups: gmane.emacs.bugs Subject: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 Date: Fri, 22 Aug 2014 11:26:03 +0100 Message-ID: References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> <83k361bqjx.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1408703249 3771 80.91.229.3 (22 Aug 2014 10:27:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Aug 2014 10:27:29 +0000 (UTC) Cc: 18310@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 22 12:27:21 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XKm3y-000386-Ca for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Aug 2014 12:27:18 +0200 Original-Received: from localhost ([::1]:36059 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKm3x-00008E-Vp for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Aug 2014 06:27:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKm3o-0008W0-TL for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 06:27:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKm3i-0002vU-SZ for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 06:27:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKm3i-0002vO-Oz for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 06:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XKm3i-0003N1-6M for bug-gnu-emacs@gnu.org; Fri, 22 Aug 2014 06:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Aug 2014 10:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18310 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18310-submit@debbugs.gnu.org id=B18310.140870318112898 (code B ref 18310); Fri, 22 Aug 2014 10:27:02 +0000 Original-Received: (at 18310) by debbugs.gnu.org; 22 Aug 2014 10:26:21 +0000 Original-Received: from localhost ([127.0.0.1]:49313 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKm32-0003Ly-4d for submit@debbugs.gnu.org; Fri, 22 Aug 2014 06:26:20 -0400 Original-Received: from mail-wg0-f42.google.com ([74.125.82.42]:63661) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKm2y-0003Lg-KB for 18310@debbugs.gnu.org; Fri, 22 Aug 2014 06:26:17 -0400 Original-Received: by mail-wg0-f42.google.com with SMTP id l18so10177014wgh.25 for <18310@debbugs.gnu.org>; Fri, 22 Aug 2014 03:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=S1sr6nbF9F1EyNvtxOsTIntnZgN3nzh7eh3GNcG0YnA=; b=Mwa2PzPh9Dsc8gGboPKHlAkA4fZujpPQwVpS7gjY15F/5c2f5qpCWnCCM3V+3xjulP 3/0nVOj67+PDtlUC/S1H6IkjSxFaMIfZXx8cqwpl3zxHxinyTjzO+m0i0UCe2Samx/cW 8R99XrK3Iw4rE+AGTf/K3SxhXb8Zt5VlAbMdY6JRU4/03xtlg4n0AbSnKJRJ6L9ST9aT 1ndzL7gk8xr6fY5FFugEqY152Te4KYRWj+BC2UBqKZ9/RAGmgXTPIeJTmzv4O18qvmtV P5dwpec4lOvyKrwmNi6G2S4jFHAm9l+4X//4kltaXL1221vxq001qt+/ezzt5yWQGuqm nFjA== X-Received: by 10.194.6.233 with SMTP id e9mr4431930wja.29.1408703170697; Fri, 22 Aug 2014 03:26:10 -0700 (PDT) Original-Received: from GONDOMAR.yourcompany.com (a81-84-241-129.static.cpe.netcabo.pt. [81.84.241.129]) by mx.google.com with ESMTPSA id e3sm74040861wjp.4.2014.08.22.03.26.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Aug 2014 03:26:09 -0700 (PDT) In-Reply-To: <83k361bqjx.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 21 Aug 2014 22:17:38 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (windows-nt) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:92591 Archived-At: Eli Zaretskii writes: >> >> Finally >> >> >> >> (let ((default-directory "\\\\")) >> >> (expand-file-name "../" "/something/bla")) >> >> >> >> Crashed the Emacs process on my machine. >> > >> > It's not a crash, it's a deliberate abort. "\\\\" (i.e., 2 >> > backslashes in a row without anything after that) is an invalid file >> > name on Windows. >> >> Would signalling an error be very wrong, does the process really need to >> be aborted? > > Yes. This is a deliberate trap for code either in Emacs itself or in > Lisp applications that uses such invalid default-directory values. But it really seems arbitrary, since (let ((default-directory "><>:\"/\|?*")) (expand-file-name "../" "/something/bla")) contains very much an invalid `default-directory' value and does not "deliberately abort". It returs "z:/something" as always (i.e default-directory is fully ignored). >> I mean unprotected code may easily lead to that invalid case. > > Not "easily", no. Usually, default-directory comes from some file or > buffer. It can very well be lexically bound to something that eventually evaluates to "////". For example to temporarily work on a directory in a Lisp program. Emacs own lisp code seems littered with (let ((default-directory ...)), just grep for it. > But if some code does use that, we want to catch it red-handed, > because there's no way to know what other damage it can do down the > road. To be clear, I fully support your "early abort" cause. But one thing is aborting the command the other thing is aborting the process. I think you should do the latter if it's the Emacs' internals that caused the (supposedly unrecoverable) error. But you should do the former if it was the user's Lisp program that provided incorrect input. I've looked at the code and expand-file-name is a woolly mammoth so maybe that's hard to do, but it would be the right thing IMO. > Emacs is not mission-critical software. If it were, then I'd agree > with you (I happen to develop mission-critical software for a living). Me too. In Lisp. But that's besides the point. Just because Emacs exists "in the hope that it will be useful" doesn't mean one shouldn't care about user's critical mission.