bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24387: 25.1.50; w32-convert-standard-filenames no longer works


From: Eli Zaretskii
Subject: bug#24387: 25.1.50; w32-convert-standard-filenames no longer works
Date: Wed, 07 Sep 2016 19:30:06 +0300

> From: Richard Copley <rcopley@gmail.com>
> Date: Wed, 7 Sep 2016 16:59:56 +0100
> Cc: 24387@debbugs.gnu.org
> 
> >> It was explicitly documented that it would work,
> >> and it still is (see the docstring for `convert-standard-filename').
> >
> > Oops!  Will fix, thanks.

Done.

> In fact I sometimes modify `exec-path' at runtime (in a fairly controlled
> manner, but it's not something I'd inflict on other users); for the sake
> of subprocesses, I also set the PATH environment variable in Emacs
> correspondingly, using `convert-standard-filename' and `path-separator'

Not sure why you'd need to use convert-standard-filename for PATH:
that variable holds the original Windows directory names with
backslashes.  If you add to it directories you added to exec-path,
then you could simply add directories with backslashes to exec-path,
which then won't need to be mirrored.

> > I'm not sure what to say in the doc string.  On the one hand, the
> > function is not to be used in preparation of shell commands, so
> > talking about shell commands there would be wrong, IMO.  OTOH,
> > replacing one character with another is a trivial operation in Emacs,
> > something like
> >
> >         (setq start 0)
> >         (while (string-match "/" name start)
> >           (aset name (match-beginning 0) ?\\)
> >           (setq start (match-end 0))))
> >
> > should be all you need.
> >
> > I could add the above snippet to the NEWS entry that announces the
> > change; would that be good enough?
> 
> Up to you; if you want to help out other people who made the same
> mistake, I expect they'd appreciate it.

I added that to NEWS.

> The function `cygwin-convert-file-name-to-windows' exists.
> Maybe you'd consider including that function(ality) in non-cygwin
> builds, with an alias ((w32-)convert-file-name-to-windows?). It could
> be documented in the same footnote; I think that's where it would be
> easiest to discover.

cygwin-convert-file-name-to-windows relies on an internal Cygwin
function that doesn't exist on native Windows, so it must be
Cygwin-specific.  In addition, it goes through 2 encoding conversions,
something that IMO is overkill for a simple job of mirroring slashes.
(For Cygwin, I guess this is justified because of the /cygdrive/
magic, but we don't need that here.)

Thanks.  Unless you (or someone else) have further comments, I will
mark this bug done.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]