From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 Date: Thu, 21 Aug 2014 17:04:49 +0300 Message-ID: <83wqa2aqgu.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1408629985 16164 80.91.229.3 (21 Aug 2014 14:06:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Aug 2014 14:06:25 +0000 (UTC) Cc: 18310@debbugs.gnu.org To: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 21 16:06:19 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 1XKT0L-0000R4-Sj for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Aug 2014 16:06:18 +0200 Original-Received: from localhost ([::1]:60886 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKT0L-0001oG-Bo for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Aug 2014 10:06:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKT0C-0001mS-Iu for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 10:06:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKT06-0001Uf-Ot for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 10:06:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKT06-0001Ua-Li for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 10:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XKT06-0003Ha-0E for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 10:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Aug 2014 14:06:01 +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.140862990312549 (code B ref 18310); Thu, 21 Aug 2014 14:06:01 +0000 Original-Received: (at 18310) by debbugs.gnu.org; 21 Aug 2014 14:05:03 +0000 Original-Received: from localhost ([127.0.0.1]:49023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKSz8-0003GK-Bq for submit@debbugs.gnu.org; Thu, 21 Aug 2014 10:05:02 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:61200) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKSz3-0003Fj-LE for 18310@debbugs.gnu.org; Thu, 21 Aug 2014 10:04:59 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NAN00100TLOX700@a-mtaout22.012.net.il> for 18310@debbugs.gnu.org; Thu, 21 Aug 2014 17:04:50 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NAN001EJTS2OZ50@a-mtaout22.012.net.il>; Thu, 21 Aug 2014 17:04:50 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il 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:92562 Archived-At: > From: joaotavora@gmail.com (João Távora) > Date: Thu, 21 Aug 2014 11:33:32 +0100 > > On Windows 7: > > emacs -Q > M-x eww RET > http://www.lispworks.com/documentation/HyperSpec/Front/index.htm RET > > Try to follow any of the relative links on the page, they point to > something strange like "www.lispworks.comz" (note the final "z") which > basically breaks all navigation. > > The `shr-url' property at point shows > > http://www.lispworks.comz:/documentation/HyperSpec/Front/StartPts.htm > > And everything indicates this is a consequence of a previous bug fix of > mine for bug#17217 [1], which does not manifest itself in my Linux > box. I'm pretty sure it also did not manifest itself on my old Windows > XP box. I'm pretty sure it did happen on XP. > In that fix, I used the function `expand-file-name' in `shr-expand-url' > to compute the expanded URL for "totally relative" case of hrefs like > "../something". > > This new bug seems to be caused by `expand-file-name' insisting on > producing a valid windows pathname (with drive letter), even though it > was passed the second argument DEFAULT-DIRECTORY. That's what expand-file-name is supposed to do: it should produce a fully-qualified file name that unequivocally describes a file. That means the file name must specify the drive letter. > That is, on my Windows 7 system: > > (expand-file-name "../bla" "/something/else") > > expands to > > "z:/something/bla" > > Whereas I intented it to expand to "/something/bla". "/something/bla" is not a fully-qualified file name, not on Windows. As long as the drive letter is not specified, the file name is ambiguous. > My HOME variable is set to at "z:", but unsetting it does not help > either. I don't think it's because of HOME, since there was no "~" in the file name. I'm guessing that the default-directory of the buffer where you used that code was on the z: drive, so Emacs used that to complete the missing drive letter. > I don't have time right now to look at the C-code for > `expand-file-name'. There's nothing wrong with expand-file-name, please don't waste your time looking there. The problem is in the change you made. You cannot use expand-file-name on anything but a file name on a local filesystem, even if the "thing" you have to deal with happens to look like a file name and uses slashes as separators. expand-file-name assumes without testing that its arguments are syntactically valid local file names, and will produce invalid results if they are not. Please use url-expand-file-name instead, it does exactly what you want, and does that portably.