GNU bug report logs - #25183
26.0.50; expanding quoted file name on w32

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25183 in the body.
You can then email your comments to 25183 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50; expanding quoted file name on w32
Date: Mon, 12 Dec 2016 16:54:06 +0100

Expanding a quoted file name works wrong on w32 systems. With Emacs
running on ‘gnu/linux’, there is

(expand-file-name "/:~/path/./file")
=> "/:~/path/file"

This is correct. With Emacs running on ‘windows-nt’, there is

(expand-file-name "/:~/path/./file")
=> "/:c:/Users/lb01177/AppData/Roaming/path/file"

I would expect the same result as above, keeping the tilde unchanged. My
Emacs version on the ‘windows-nt’ system is

GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17


In GNU Emacs 26.0.50.7 (x86_64-pc-linux-gnu, GTK+ Version 2.24.30)
 of 2016-12-02 built on detlef
Repository revision: e9ac4b4c82a5698e9399deea2d6450890b8baf64
System Description:	Ubuntu 16.10

Recent messages:
Mark set [2 times]
Returning to the group buffer
Saving /home/albinus/.newsrc.eld...
Saving file /home/albinus/.newsrc.eld...
Wrote /home/albinus/.newsrc.eld
Saving /home/albinus/.newsrc.eld...done
current-kill: Kill ring is empty
"/:~/path/file"
Quit
Making completion list...

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GCONF GSETTINGS NOTIFY GNUTLS
LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8

Major mode: Lisp Interaction

Minor modes in effect:
  erc-notify-mode: t
  erc-notifications-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  display-time-mode: t
  shell-dirtrack-mode: t
  icomplete-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/albinus/src/elpa/packages/debbugs/debbugs-org hides /home/albinus/.emacs.d/elpa/debbugs-0.12/debbugs-org
/home/albinus/src/elpa/packages/debbugs/debbugs-gnu hides /home/albinus/.emacs.d/elpa/debbugs-0.12/debbugs-gnu
/home/albinus/src/elpa/packages/debbugs/debbugs hides /home/albinus/.emacs.d/elpa/debbugs-0.12/debbugs
/home/albinus/src/elpa/packages/debbugs/debbugs-autoloads hides /home/albinus/.emacs.d/elpa/debbugs-0.12/debbugs-autoloads
/home/albinus/src/elpa/packages/debbugs/debbugs-pkg hides /home/albinus/.emacs.d/elpa/debbugs-0.12/debbugs-pkg
/home/albinus/src/elpa/packages/debbugs/debbugs-browse hides /home/albinus/.emacs.d/elpa/debbugs-0.12/debbugs-browse
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme hides /home/albinus/.emacs.d/elpa/tramp-theme-0.1.1/tramp-theme
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme-autoloads hides /home/albinus/.emacs.d/elpa/tramp-theme-0.1.1/tramp-theme-autoloads
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme-pkg hides /home/albinus/.emacs.d/elpa/tramp-theme-0.1.1/tramp-theme-pkg
/home/albinus/.emacs.d/elpa/telepathy-20131209.458/telepathy hides ~/lisp/telepathy
/home/albinus/.emacs.d/elpa/ada-mode-5.2.1/ada-prj hides /usr/local/share/emacs/26.0.50/lisp/progmodes/ada-prj
/home/albinus/.emacs.d/elpa/ada-mode-5.2.1/ada-xref hides /usr/local/share/emacs/26.0.50/lisp/progmodes/ada-xref
/home/albinus/.emacs.d/elpa/ada-mode-5.2.1/ada-mode hides /usr/local/share/emacs/26.0.50/lisp/progmodes/ada-mode
/home/albinus/.emacs.d/elpa/ada-mode-5.2.1/ada-stmt hides /usr/local/share/emacs/26.0.50/lisp/progmodes/ada-stmt
~/src/tramp/lisp/tramp-smb hides /usr/local/share/emacs/26.0.50/lisp/net/tramp-smb
~/src/tramp/lisp/tramp-uu hides /usr/local/share/emacs/26.0.50/lisp/net/tramp-uu
~/src/tramp/lisp/tramp-adb hides /usr/local/share/emacs/26.0.50/lisp/net/tramp-adb
~/src/tramp/lisp/tramp-compat hides /usr/local/share/emacs/26.0.50/lisp/net/tramp-compat
~/src/tramp/lisp/tramp hides /usr/local/share/emacs/26.0.50/lisp/net/tramp
~/src/tramp/lisp/trampver hides /usr/local/share/emacs/26.0.50/lisp/net/trampver
~/src/tramp/lisp/tramp-ftp hides /usr/local/share/emacs/26.0.50/lisp/net/tramp-ftp
~/src/tramp/lisp/tramp-cmds hides /usr/local/share/emacs/26.0.50/lisp/net/tramp-cmds
~/src/tramp/lisp/tramp-gvfs hides /usr/local/share/emacs/26.0.50/lisp/net/tramp-gvfs
~/src/tramp/lisp/tramp-loaddefs hides /usr/local/share/emacs/26.0.50/lisp/net/tramp-loaddefs
~/lisp/dbus hides /usr/local/share/emacs/26.0.50/lisp/net/dbus
~/src/tramp/lisp/tramp-gw hides /usr/local/share/emacs/26.0.50/lisp/net/tramp-gw
~/src/tramp/lisp/tramp-sh hides /usr/local/share/emacs/26.0.50/lisp/net/tramp-sh
~/src/tramp/lisp/tramp-cache hides /usr/local/share/emacs/26.0.50/lisp/net/tramp-cache

Features:
(shadow warnings emacsbug mm-archive sort gnus-cite mail-extr gnus-bcklg
qp gnus-async gnus-ml pop3 utf-7 nndraft nnmh nnml network-stream nsm
starttls gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg
gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap gnus-cache
gnus-sum time-stamp nnnil smtpmail sendmail gnus-demon nntp gnus-group
gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls
utf7 netrc nnoo gnus-spec gnus-int gnus-range message puny rfc822 mml
mml-sec epa derived epg mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader gnus-win gnus nnheader subr-x gnus-util
rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums mail-utils mm-util
mail-prsvr term/xterm xterm erc-notify erc-desktop-notifications
notifications dbus xml erc-list erc-menu erc-join erc-ring erc-networks
erc-pcomplete erc-track erc-match erc-button wid-edit erc-fill erc-stamp
erc-netsplit erc-goodies erc erc-backend erc-compat thingatpt pp
cperl-mode tramp-theme em-dirs esh-var esh-io esh-cmd esh-opt esh-ext
esh-proc esh-arg esh-groups eshell esh-module esh-mode esh-util
finder-inf docker-tramp tramp-cache slime-autoloads url-auth
vagrant-tramp dash term disp-table ehelp info package epg-config
url-handlers url-parse url-vars time tramp-sh tramp tramp-compat
tramp-loaddefs trampver ucs-normalize shell pcomplete comint ansi-color
ring parse-time format-spec advice auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache ido seq byte-opt gv bytecomp
byte-compile cl-extra help-mode easymenu cconv jka-compr icomplete
time-date paren ps-print ps-print-loaddefs ps-def lpr vc cl-loaddefs
pcase cl-lib vc-dispatcher dired dired-loaddefs mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript case-table epa-hook jka-cmpr-hook help
simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 432481 46864)
 (symbols 48 40768 122)
 (miscs 40 70 352)
 (strings 32 90971 14491)
 (string-bytes 1 2780920)
 (vectors 16 57764)
 (vector-slots 8 936127 10743)
 (floats 8 686 548)
 (intervals 56 293 47)
 (buffers 976 20))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 25183 <at> debbugs.gnu.org
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Mon, 12 Dec 2016 18:48:18 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Mon, 12 Dec 2016 16:54:06 +0100
> 
> 
> Expanding a quoted file name works wrong on w32 systems. With Emacs
> running on ‘gnu/linux’, there is
> 
> (expand-file-name "/:~/path/./file")
> => "/:~/path/file"
> 
> This is correct. With Emacs running on ‘windows-nt’, there is
> 
> (expand-file-name "/:~/path/./file")
> => "/:c:/Users/lb01177/AppData/Roaming/path/file"

Try

   (expand-file-name "/:c:/~/path/./file")

expand-file-name needs to produce an absolute file name, and a file
name that begins with a "~" isn't.

IOW, I believe this is a feature.  If you think it isn't, please
explain why.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25183 <at> debbugs.gnu.org
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Mon, 12 Dec 2016 17:54:33 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Michael Albinus <michael.albinus <at> gmx.de>
>> Date: Mon, 12 Dec 2016 16:54:06 +0100
>> 
>> 
>> Expanding a quoted file name works wrong on w32 systems. With Emacs
>> running on ‘gnu/linux’, there is
>> 
>> (expand-file-name "/:~/path/./file")
>> => "/:~/path/file"
>> 
>> This is correct. With Emacs running on ‘windows-nt’, there is
>> 
>> (expand-file-name "/:~/path/./file")
>> => "/:c:/Users/lb01177/AppData/Roaming/path/file"
>
> Try
>
>    (expand-file-name "/:c:/~/path/./file")
>
> expand-file-name needs to produce an absolute file name, and a file
> name that begins with a "~" isn't.
>
> IOW, I believe this is a feature.  If you think it isn't, please
> explain why.

(file-name-absolute-p "/:~/path/./file")
=> t

Best regards, Michael.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Albinus <michael.albinus <at> gmx.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 25183 <at> debbugs.gnu.org
Subject: RE: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Mon, 12 Dec 2016 10:11:45 -0800 (PST)

> (file-name-absolute-p "/:~/path/./file") => t

It's not (to me) obvious that this would be the case.
Please call this out in the doc, if it is not done already.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Albinus <michael.albinus <at> gmx.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 25183 <at> debbugs.gnu.org
Subject: RE: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Mon, 12 Dec 2016 10:17:44 -0800 (PST)

> It's not (to me) obvious that this would be the case.
> Please call this out in the doc, if it is not done already.

Nevermind this suggestion, please.  It seems fine (and in
fact it is nothing new).

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 25183 <at> debbugs.gnu.org
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Mon, 12 Dec 2016 19:39:09 -0500

>>> (expand-file-name "/:~/path/./file")
>>> => "/:~/path/file"

>>> (expand-file-name "/:~/path/./file")
>>> => "/:c:/Users/lb01177/AppData/Roaming/path/file"

>
> (file-name-absolute-p "/:~/path/./file")
> => t

I think all these cases are user error, `(emacs) Quoted File Names' says

    You can "quote" an absolute file name [...] add ‘/:’ at the beginning

But you cannot quote a relative file name, which looks like what
you're trying to do here. It might better to throw an error than
return nonsense (though possibly not worth the trouble).

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

From: Glenn Morris <rgm <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 25183 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Mon, 12 Dec 2016 20:08:37 -0500

Noam Postavsky wrote:

>>>> (expand-file-name "/:~/path/./file")
>>>> => "/:~/path/file"
>
>>>> (expand-file-name "/:~/path/./file")
>>>> => "/:c:/Users/lb01177/AppData/Roaming/path/file"
>
>>
>> (file-name-absolute-p "/:~/path/./file")
>> => t
>
> I think all these cases are user error, `(emacs) Quoted File Names' says
>
>     You can "quote" an absolute file name [...] add '/:' at the beginning
>
> But you cannot quote a relative file name, which looks like what
> you're trying to do here. It might better to throw an error than
> return nonsense (though possibly not worth the trouble).

But "~/blah" is an absolute file name. ?

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

From: Glenn Morris <rgm <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 25183 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Mon, 12 Dec 2016 20:10:49 -0500

Glenn Morris wrote:

> But "~/blah" is an absolute file name. ?

Oh, but not on MS Windows apparently. (Yuck.) Blah, ignore me.

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

From: npostavs <at> users.sourceforge.net
To: Glenn Morris <rgm <at> gnu.org>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 25183 <at> debbugs.gnu.org
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Mon, 12 Dec 2016 20:33:54 -0500

Glenn Morris <rgm <at> gnu.org> writes:

> Noam Postavsky wrote:
>
>>>>> (expand-file-name "/:~/path/./file")
>>>>> => "/:~/path/file"
>>
>>>>> (expand-file-name "/:~/path/./file")
>>>>> => "/:c:/Users/lb01177/AppData/Roaming/path/file"
>>
>>>
>>> (file-name-absolute-p "/:~/path/./file")
>>> => t
>>
>> I think all these cases are user error, `(emacs) Quoted File Names' says
>>
>>     You can "quote" an absolute file name [...] add '/:' at the beginning
>>
>> But you cannot quote a relative file name, which looks like what
>> you're trying to do here. It might better to throw an error than
>> return nonsense (though possibly not worth the trouble).
>
> But "~/blah" is an absolute file name. ?

Yes, but in "/:~/blah", the /: should prevent expanding "~", so then it
seems not to refer to an absolute file name, but rather a file named
"blah" in a directory named literally "~".  But if it's not an absolute
file name, then /: doesn't make sense.  So it's a kind of paradox.  This
is not w32 specific (although the actual implementation happens to
resolve the "paradox" in a different way on w32).

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: npostavs <at> users.sourceforge.net
Cc: Glenn Morris <rgm <at> gnu.org>, 25183 <at> debbugs.gnu.org
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Tue, 13 Dec 2016 09:30:18 +0100

npostavs <at> users.sourceforge.net writes:

> Glenn Morris <rgm <at> gnu.org> writes:
>
>> Noam Postavsky wrote:
>>
>>>>>> (expand-file-name "/:~/path/./file")
>>>>>> => "/:~/path/file"
>>>
>>>>>> (expand-file-name "/:~/path/./file")
>>>>>> => "/:c:/Users/lb01177/AppData/Roaming/path/file"
>>>
>>>>
>>>> (file-name-absolute-p "/:~/path/./file")
>>>> => t
>>>
>>> I think all these cases are user error, `(emacs) Quoted File Names' says
>>>
>>>     You can "quote" an absolute file name [...] add '/:' at the beginning
>>>
>>> But you cannot quote a relative file name, which looks like what
>>> you're trying to do here. It might better to throw an error than
>>> return nonsense (though possibly not worth the trouble).
>>
>> But "~/blah" is an absolute file name. ?
>
> Yes, but in "/:~/blah", the /: should prevent expanding "~", so then it
> seems not to refer to an absolute file name, but rather a file named
> "blah" in a directory named literally "~".  But if it's not an absolute
> file name, then /: doesn't make sense.  So it's a kind of paradox.  This
> is not w32 specific (although the actual implementation happens to
> resolve the "paradox" in a different way on w32).

Well, I don't want to insist that it *must* be solved. But there's
different behaviour when running Emacs on GNU/Linux, or running on MS
Windows.

It is not an annoyance coming from a user's bug report; I've stumbled
over this when running tramp-tests.el under many different environments.

(expand-file-name "/:/~/path/./file") => "/:c:/~/path/file"

looks better, althoug the volume drive would still disturb me. But
that's my personal preference, the result might be OK on MS Windows.

Eli?

Best regards, Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 25183 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Tue, 13 Dec 2016 18:28:22 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Tue, 13 Dec 2016 09:30:18 +0100
> Cc: 25183 <at> debbugs.gnu.org
> 
> It is not an annoyance coming from a user's bug report; I've stumbled
> over this when running tramp-tests.el under many different environments.
> 
> (expand-file-name "/:/~/path/./file") => "/:c:/~/path/file"
> 
> looks better, althoug the volume drive would still disturb me. But
> that's my personal preference, the result might be OK on MS Windows.
> 
> Eli?

I will look into this in a couple of days.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: michael.albinus <at> gmx.de
Cc: 25183 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Sat, 24 Dec 2016 14:52:17 +0200

> Date: Tue, 13 Dec 2016 18:28:22 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 25183 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
> 
> > From: Michael Albinus <michael.albinus <at> gmx.de>
> > Date: Tue, 13 Dec 2016 09:30:18 +0100
> > Cc: 25183 <at> debbugs.gnu.org
> > 
> > It is not an annoyance coming from a user's bug report; I've stumbled
> > over this when running tramp-tests.el under many different environments.
> > 
> > (expand-file-name "/:/~/path/./file") => "/:c:/~/path/file"
> > 
> > looks better, althoug the volume drive would still disturb me. But
> > that's my personal preference, the result might be OK on MS Windows.
> > 
> > Eli?
> 
> I will look into this in a couple of days.

Sorry for the delay.

I looked into this, and I indeed think there might be a problem here.
I agree that "~" should not be expanded for file names escaped with
"/:", but before I propose a solution, I think we should decide
whether the "/:" escape should cause the rest be expanded "as usual",
i.e. produce an absolute file name after "/:" for local file names,
minus the "~" expansion.  Currently, Unix file names are not expanded
because '/' as the first character makes them look as absolute file
names.  MS-Windows specific code, OTOH, looks under the hood, and does
expand the rest.

IOW, the question is whether on Windows we should have this:

  (expand-file-name "/:~/path/./file") => "/:c:/~/path/file"

or this:

  (expand-file-name "/:~/path/./file") => "/:~/path/file"

If we want the former, then maybe the Unix code should be fixed to
produce "/:/~/path/file" in that case.

Thoughts?

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

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25183 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Sat, 24 Dec 2016 08:57:45 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

> I looked into this, and I indeed think there might be a problem here.
> I agree that "~" should not be expanded for file names escaped with
> "/:", but before I propose a solution, I think we should decide
> whether the "/:" escape should cause the rest be expanded "as usual",
> i.e. produce an absolute file name after "/:" for local file names,
> minus the "~" expansion.  Currently, Unix file names are not expanded
> because '/' as the first character makes them look as absolute file
> names.  MS-Windows specific code, OTOH, looks under the hood, and does
> expand the rest.
>
> IOW, the question is whether on Windows we should have this:
>
>   (expand-file-name "/:~/path/./file") => "/:c:/~/path/file"
>
> or this:
>
>   (expand-file-name "/:~/path/./file") => "/:~/path/file"
>
> If we want the former, then maybe the Unix code should be fixed to
> produce "/:/~/path/file" in that case.
>
> Thoughts?

If we want to extend the /: quoting to also apply to relative file names
too, then the latter makes sense.  Otherwise, the only consistent result
would be

    (expand-file-name "/:~/path/./file") => (error "/: quoting relative file name")

As I've said in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25183#29,
currently "/:~/foo" is a kind of paradoxical file name, being
both/neither relative nor absolute.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 25183 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Sat, 24 Dec 2016 18:06:36 +0200

> From: npostavs <at> users.sourceforge.net
> Cc: michael.albinus <at> gmx.de,  25183 <at> debbugs.gnu.org
> Date: Sat, 24 Dec 2016 08:57:45 -0500
> 
> If we want to extend the /: quoting to also apply to relative file names
> too, then the latter makes sense.  Otherwise, the only consistent result
> would be
> 
>     (expand-file-name "/:~/path/./file") => (error "/: quoting relative file name")

expand-file-name doesn't signal errors, and I don't think it would be
a good idea to have it start doing that.

> As I've said in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25183#29,
> currently "/:~/foo" is a kind of paradoxical file name, being
> both/neither relative nor absolute.

file-name-absolute-p is not smart enough to handle this case with the
rigor we are discussing, so I don't think this aspect is important for
the purposes of this discussion.  The "/:" quoting was chosen because
it fools file-name-absolute-p, so the above is not surprising.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25183 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Sat, 24 Dec 2016 12:43:24 -0500

On Sat, Dec 24, 2016 at 11:06 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: npostavs <at> users.sourceforge.net
>> Cc: michael.albinus <at> gmx.de,  25183 <at> debbugs.gnu.org
>> Date: Sat, 24 Dec 2016 08:57:45 -0500
>>
>> If we want to extend the /: quoting to also apply to relative file names
>> too, then the latter makes sense.  Otherwise, the only consistent result
>> would be
>>
>>     (expand-file-name "/:~/path/./file") => (error "/: quoting relative file name")
>
> expand-file-name doesn't signal errors, and I don't think it would be
> a good idea to have it start doing that.

I think the status quo (leaving it inconsistent) is okay too (garbage
in, garbage out).

>
>> As I've said in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25183#29,
>> currently "/:~/foo" is a kind of paradoxical file name, being
>> both/neither relative nor absolute.
>
> file-name-absolute-p is not smart enough to handle this case with the
> rigor we are discussing, so I don't think this aspect is important for
> the purposes of this discussion.  The "/:" quoting was chosen because
> it fools file-name-absolute-p, so the above is not surprising.

I don't think file-name-absolute-p is relevant.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 25183 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Sat, 24 Dec 2016 20:00:32 +0200

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Sat, 24 Dec 2016 12:43:24 -0500
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, 25183 <at> debbugs.gnu.org
> 
> >>     (expand-file-name "/:~/path/./file") => (error "/: quoting relative file name")
> >
> > expand-file-name doesn't signal errors, and I don't think it would be
> > a good idea to have it start doing that.
> 
> I think the status quo (leaving it inconsistent) is okay too (garbage
> in, garbage out).

But expansion of "~" in the Windows build should be bypassed in this
case, don't you agree?

> >> As I've said in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25183#29,
> >> currently "/:~/foo" is a kind of paradoxical file name, being
> >> both/neither relative nor absolute.
> >
> > file-name-absolute-p is not smart enough to handle this case with the
> > rigor we are discussing, so I don't think this aspect is important for
> > the purposes of this discussion.  The "/:" quoting was chosen because
> > it fools file-name-absolute-p, so the above is not surprising.
> 
> I don't think file-name-absolute-p is relevant.

We are in agreement about that.

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

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael.albinus <at> gmx.de, 25183 <at> debbugs.gnu.org
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Sat, 24 Dec 2016 13:51:14 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
>> Date: Sat, 24 Dec 2016 12:43:24 -0500
>> Cc: Michael Albinus <michael.albinus <at> gmx.de>, 25183 <at> debbugs.gnu.org
>> 
>> >>     (expand-file-name "/:~/path/./file") => (error "/: quoting relative file name")
>> >
>> > expand-file-name doesn't signal errors, and I don't think it would be
>> > a good idea to have it start doing that.
>> 
>> I think the status quo (leaving it inconsistent) is okay too (garbage
>> in, garbage out).
>
> But expansion of "~" in the Windows build should be bypassed in this
> case, don't you agree?

In the case of "/:~/whatever" I think any output is fine, since the
input is meaningless.  Avoiding ~-expansion is okay, though I don't
think it's actually a problem either way.

For reference, on a GNU system, doing

$ echo xx > '~'
$ emacs -Q '/:~'

opens up the $HOME directory, even though the "~" is not expanded by
`expand-file-name'.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25183 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Sun, 25 Dec 2016 12:31:40 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> I looked into this, and I indeed think there might be a problem here.
> I agree that "~" should not be expanded for file names escaped with
> "/:", but before I propose a solution, I think we should decide
> whether the "/:" escape should cause the rest be expanded "as usual",
> i.e. produce an absolute file name after "/:" for local file names,
> minus the "~" expansion.  Currently, Unix file names are not expanded
> because '/' as the first character makes them look as absolute file
> names.  MS-Windows specific code, OTOH, looks under the hood, and does
> expand the rest.
>
> IOW, the question is whether on Windows we should have this:
>
>   (expand-file-name "/:~/path/./file") => "/:c:/~/path/file"
>
> or this:
>
>   (expand-file-name "/:~/path/./file") => "/:~/path/file"
>
> If we want the former, then maybe the Unix code should be fixed to
> produce "/:/~/path/file" in that case.
>
> Thoughts?

(expand-file-name "/:~/path/./file") => "/:~/path/file"

looks proper to me. Prepending "c:/" moves the file to another location
on the c: drive, perhaps.

What does (expand-file-name "/:dir/path/./file") ?

Best regards, Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 25183 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Mon, 26 Dec 2016 17:58:15 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: 25183 <at> debbugs.gnu.org,  npostavs <at> users.sourceforge.net
> Date: Sun, 25 Dec 2016 12:31:40 +0100
> 
> (expand-file-name "/:~/path/./file") => "/:~/path/file"
> 
> looks proper to me.

That's proper on Unix, but on MS-Windows it will look like a
non-absolute file name, which might break things.

> Prepending "c:/" moves the file to another location
> on the c: drive, perhaps.

It should use CWD, not necessarily c:/.  See below.

> What does (expand-file-name "/:dir/path/./file") ?

It produces "/:CURDIR/dir/path/file", where CURDIR is the current
default directory, including the drive letter.  My current way of
thinking is to produce the same when "dir" is replaced with "~".  Is
that acceptable, in particular for Tramp?

Thanks.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25183 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Mon, 26 Dec 2016 17:19:24 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> What does (expand-file-name "/:dir/path/./file") ?
>
> It produces "/:CURDIR/dir/path/file", where CURDIR is the current
> default directory, including the drive letter.  My current way of
> thinking is to produce the same when "dir" is replaced with "~".  Is
> that acceptable, in particular for Tramp?

Looks OK. Thanks!

> Thanks.

Best regards, Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 25183 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Tue, 27 Dec 2016 10:14:19 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: 25183 <at> debbugs.gnu.org,  npostavs <at> users.sourceforge.net
> Date: Mon, 26 Dec 2016 17:19:24 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> What does (expand-file-name "/:dir/path/./file") ?
> >
> > It produces "/:CURDIR/dir/path/file", where CURDIR is the current
> > default directory, including the drive letter.  My current way of
> > thinking is to produce the same when "dir" is replaced with "~".  Is
> > that acceptable, in particular for Tramp?
> 
> Looks OK. Thanks!

OK, now done on master.  Please see if any problems are left, and if
not, please close the bug.

Thanks for the discussion and the feedback.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: michael.albinus <at> gmx.de, 25183 <at> debbugs.gnu.org
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Tue, 27 Dec 2016 10:17:07 +0200

> From: npostavs <at> users.sourceforge.net
> Cc: 25183 <at> debbugs.gnu.org,  michael.albinus <at> gmx.de
> Date: Sat, 24 Dec 2016 13:51:14 -0500
> 
> For reference, on a GNU system, doing
> 
> $ echo xx > '~'
> $ emacs -Q '/:~'
> 
> opens up the $HOME directory, even though the "~" is not expanded by
> `expand-file-name'.

On MS-Windows, after I pushed my changes, the above opens the file
'~', not the home directory.  Not sure if we care, since we in effect
decided that this invokes undefined behavior.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25183 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Tue, 27 Dec 2016 10:56:27 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

> OK, now done on master.  Please see if any problems are left, and if
> not, please close the bug.

Will check. However, I have no idea where I could get precompiled Emacs
26 binaries for MS Windows.

> Thanks for the discussion and the feedback.

Best regards, Michael.

Message #76 received at 25183-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25183-done <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#25183: 26.0.50; expanding quoted file name on w32
Date: Fri, 27 Jan 2017 10:51:26 +0100

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi Eli,

>> OK, now done on master.  Please see if any problems are left, and if
>> not, please close the bug.
>
> Will check. However, I have no idea where I could get precompiled Emacs
> 26 binaries for MS Windows.

Well, I see no chance to get Emacs 26 for MS Windows in the foreseeable
future. I'm closing this bug.

If there are still problems, it shall be reopened.

Best regards, Michael.

Previous Next

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