GNU bug report logs - #76982
30.1; url-generic-parse-url cannot parse Windows file paths

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: sebastian <at> sebasmonia.com
Cc: 76982 <at> debbugs.gnu.org, morgan <at> ice9.digital
Subject: Re: bug#76982: 30.1;
 url-generic-parse-url cannot parse Windows file paths
Date: Sat, 29 Mar 2025 14:16:13 +0300

Ping!  Sebastián, would you like to submit an updated patch which
addresses my comments?

> Cc: 76982 <at> debbugs.gnu.org, morgan <at> ice9.digital
> Date: Thu, 13 Mar 2025 10:20:41 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Cc: 76982 <at> debbugs.gnu.org
> > From: Sebastián Monía
> >  <sebastian <at> sebasmonia.com>
> > Date: Wed, 12 Mar 2025 15:23:08 -0400
> > 
> > Morgan Willcock <morgan <at> ice9.digital> writes:
> > 
> > >   (url-filename (url-generic-parse-url "file:///c:/windows"))
> > >   => "/c:/windows"
> > >
> > >   (url-filename (url-generic-parse-url "c:/windows"))
> > >   => "/windows"
> > >
> > > This is relevant in functions such as
> > > mml-expand-html-into-multipart-related, where there is a check that the
> > > file exists:
> > >
> > >   (when (and (null (url-type parsed))
> > >              (not (zerop (length (url-filename parsed))))
> > >              (file-exists-p (url-filename parsed)))
> > >     ...)
> > >
> > > An example of a real world problem is being unable to reliably send HTML
> > > mail when using Windows:
> > >
> > > https://github.com/jeremy-compostella/org-msg/issues/122
> > 
> > Attached a potential patch.
> 
> Thanks.
> 
> > >From 25c0cbeb1523e3fed3d3409465b6dcc99c967a38 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Sebasti=C3=A1n=20Mon=C3=ADa?=
> >  <sebastian.monia <at> sebasmonia.com>
> > Date: Wed, 12 Mar 2025 15:16:19 -0400
> > Subject: [PATCH] url-parse.el: Parsing exceptions for Windows paths
> >  (bug#76982)
> 
> Please add a ChangeLog-style list of functions that are modified and a
> short description of each modification.
> 
> > 
> > ---
> >  lisp/url/url-parse.el | 14 +++++++++++++-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lisp/url/url-parse.el b/lisp/url/url-parse.el
> > index 4c65721b83d..1dff66c6228 100644
> > --- a/lisp/url/url-parse.el
> > +++ b/lisp/url/url-parse.el
> > @@ -83,7 +83,12 @@ url-recreate-url
> >  	 ;; port is empty or if its value would be the same as that of
> >  	 ;; the scheme's default."
> >  	 (port (url-port-if-non-default urlobj))
> > -	 (file (url-filename urlobj))
> > +         ;; For Windows/DOS-like paths, `url-generic-parse-url' strips
> > +         ;; the leading /, so we need to add it back (bug#76982)
> > +	 (file (if (and (string= "file" type)
> > +                        (string-match "^[A-Za-z]:[/\\]" (url-filename urlobj)))
> > +                   (concat "/" (url-filename urlobj))
> > +                 (url-filename urlobj)))
> >  	 (frag (url-target urlobj)))
> >      (concat (if type (concat type ":"))
> >  	    (if (url-fullness urlobj) "//")
> 
> OK.
> 
> > @@ -210,6 +215,13 @@ url-generic-parse-url
> >  
> >            (if (and host (string-match "%[0-9][0-9]" host))
> >                (setq host (url-unhex-string host)))
> > +
> > +          ;; For file:// URIs, if the path "looks like" Windows/DOS, it
> > +          ;; makes sense to strip the leading slash (bug#76982)
> > +          (when (and (string= "file" scheme)
> > +                     (string-match "^/[A-Za-z]:[/\\]" file))
> > +            (setq file (substring file 1)))
> > +
> >            (url-parse-make-urlobj scheme user pass host port file
> >  				 fragment nil full))))))
> 
> Isn't it cleaner to go one more character forward here:
> 
>           ;; 3.2. Authority
>           (when (looking-at "//")
>             (setq full t)
>             (forward-char 2)  <<<<<<<<<<<<<<<<<<<<
>             (setq save-pos (point))
>             (skip-chars-forward "^/?#")
> 
> if the conditions for Windows-style absolute file name are fulfilled?
> 
> Also, could we please have some simple tests for this?
> 
> 
> 
> 

Previous Next

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