[debbugs-tracker] bug#21831: closed (24.5 on Windows; start-process modifies its PROGRAM argument)

[GNU bug Tracking System]

Your message dated Wed, 04 Nov 2015 23:01:48 +0200
with message-id <address@hidden>
and subject line Re: bug#21831: 24.5 on Windows; start-process modifies its 
PROGRAM argument
has caused the debbugs.gnu.org bug report #21831,
regarding 24.5 on Windows; start-process modifies its PROGRAM argument
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
21831: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21831
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: 24.5 on Windows; start-process modifies its PROGRAM argument Date: Wed, 4 Nov 2015 21:31:55 +0100

start-process normalizes the given PROGRAM path by destructively modifying its contents.

This is problematic if the path variable is reused later on.

Minimal repro:

(let ((path "c:/Windows/System32/clip.exe"))

  (start-process "" nil path)

  path) ; => "c:\\Windows\\System32\\clip.exe"

In GNU Emacs 24.5.1 (i686-pc-mingw32)

 of 2015-04-11 on LEG570

Windowing system distributor `Microsoft Corp.', version 6.3.9600

Configured using:

 `configure --prefix=/c/usr --host=i686-pc-mingw32'

Important settings:

  value of $LANG: DEU

  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:

  tooltip-mode: t

  electric-indent-mode: t

  mouse-wheel-mode: t

  tool-bar-mode: t

  menu-bar-mode: t

  file-name-shadow-mode: t

  global-font-lock-mode: t

  font-lock-mode: t

  blink-cursor-mode: t

  auto-composition-mode: t

  auto-encryption-mode: t

  auto-compression-mode: t

  line-number-mode: t

  transient-mark-mode: t

Recent messages:

For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:

None found.

Features:

(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml

easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231

mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums

mm-util help-fns mail-prsvr mail-utils time-date tooltip electric

uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp

w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image

regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register

page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock

font-lock syntax facemenu font-core frame cham georgian utf-8-lang

misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew

greek romanian slovak czech european ethiopic indian cyrillic chinese

case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer 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 make-network-process w32notify w32

multi-tty emacs)

Memory information:

((conses 8 73857 5808)

 (symbols 32 17432 0)

 (miscs 32 33 131)

 (strings 16 10612 4319)

 (string-bytes 1 268415)

 (vectors 8 9520)

 (vector-slots 4 383153 5554)

 (floats 8 57 68)

 (intervals 28 196 45)

 (buffers 508 11))

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#21831: 24.5 on Windows; start-process modifies its PROGRAM argument
>
>
>
>
> Date: 
>
> Wed, 04 Nov 2015 23:01:48 +0200
>
>
>
>
> > From: Cornelius Mika <address@hidden>
> > Date: Wed, 4 Nov 2015 21:31:55 +0100
> > 
> > start-process normalizes the given PROGRAM path by destructively modifying its
> > contents.
> > This is problematic if the path variable is reused later on.
> > 
> > Minimal repro:
> > (let ((path "c:/Windows/System32/clip.exe"))
> > (start-process "" nil path)
> > path) ; => "c:\\Windows\\System32\\clip.exe"
> > 
> > In GNU Emacs 24.5.1 (i686-pc-mingw32)
> > of 2015-04-11 on LEG570
> > Windowing system distributor `Microsoft Corp.', version 6.3.9600
> > Configured using:
> > `configure --prefix=/c/usr --host=i686-pc-mingw32'
>
> Thanks.
>
> I can reproduce this in Emacs 24.5, but not in the current development
> sources.  So this problem was already fixed as part of the development
> since then, and I see the code which was added to avoid this.
>
> So I'm marking this bug done.
>
>
> --- End Message ---