bug#25183: 26.0.50; expanding quoted file name on w32

bug#25183: 26.0.50; expanding quoted file name on w32

[Michael Albinus]

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))

bug#25183: 26.0.50; expanding quoted file name on w32

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Albinus <michael.albinus@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Drew Adams]

> (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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Drew Adams]

> 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).

bug#25183: 26.0.50; expanding quoted file name on w32

[Noam Postavsky]

>>> (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).

bug#25183: 26.0.50; expanding quoted file name on w32

[Glenn Morris]

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. ?

bug#25183: 26.0.50; expanding quoted file name on w32

[Glenn Morris]

Glenn Morris wrote:

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

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

bug#25183: 26.0.50; expanding quoted file name on w32

[npostavs]

Glenn Morris <rgm@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).

bug#25183: 26.0.50; expanding quoted file name on w32

[Michael Albinus]

npostavs@users.sourceforge.net writes:

> Glenn Morris <rgm@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Tue, 13 Dec 2016 09:30:18 +0100
> Cc: 25183@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Eli Zaretskii]

> Date: Tue, 13 Dec 2016 18:28:22 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 25183@debbugs.gnu.org, npostavs@users.sourceforge.net
> 
> > From: Michael Albinus <michael.albinus@gmx.de>
> > Date: Tue, 13 Dec 2016 09:30:18 +0100
> > Cc: 25183@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?

bug#25183: 26.0.50; expanding quoted file name on w32

[npostavs]

Eli Zaretskii <eliz@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: michael.albinus@gmx.de,  25183@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Noam Postavsky]

On Sat, Dec 24, 2016 at 11:06 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: npostavs@users.sourceforge.net
>> Cc: michael.albinus@gmx.de,  25183@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sat, 24 Dec 2016 12:43:24 -0500
> Cc: Michael Albinus <michael.albinus@gmx.de>, 25183@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Sat, 24 Dec 2016 12:43:24 -0500
>> Cc: Michael Albinus <michael.albinus@gmx.de>, 25183@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'.

bug#25183: 26.0.50; expanding quoted file name on w32

[Michael Albinus]

Eli Zaretskii <eliz@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: 25183@debbugs.gnu.org,  npostavs@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Michael Albinus]

Eli Zaretskii <eliz@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: 25183@debbugs.gnu.org,  npostavs@users.sourceforge.net
> Date: Mon, 26 Dec 2016 17:19:24 +0100
> 
> Eli Zaretskii <eliz@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: 25183@debbugs.gnu.org,  michael.albinus@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Michael Albinus]

Eli Zaretskii <eliz@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.

bug#25183: 26.0.50; expanding quoted file name on w32

[Michael Albinus]

Michael Albinus <michael.albinus@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.