bug#27528: 26.0.50; load-path initialisation is wrong when Emacs is launched in batch mode from a console inside another Emacs

[Vincent Belaïche]

I consider two Emacs instance

1) instance master : it was built today (2017-06-29) from the HEAD of
   master branch. Its absolute path is
   c:/Nos_Programmes/GNU/Emacs/bin/emacs.exe

2) instance emacs-25: it was built on 2017-06-14 from the HEAD of
   emacs-25 branch. Its absolute path is
   c:/Nos_Programmes/GNU/Emacs_build20170614/bin/emacs.exe

Then I do the following two experiments :

1) The EMACS environment variable points at Emacs instance master,
   c:/Nos_Programmes/GNU/Emacs/bin/emacs.exe.

2) From an MSYS bash console, outside Emacs, I launch the following
command:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
$EMACS --batch -Q --eval '(princ load-path)' \
  > /tmp/load-path-outside-other-emacs.txt 2>&1
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

The content of load-path-outside-other-emacs.txt is as follows (all the
content is stdout):

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
(c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/vc 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/url 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/textmodes 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/progmodes 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/play 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/org 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/nxml 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/net 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/mh-e 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/mail 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/leim 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/language 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/international 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/image 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/gnus 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/eshell 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/erc 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/emulation 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/emacs-lisp 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/cedet 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/calendar 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/calc 
c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/obsolete)--8<----8<----8<----8<----8<--
  end  -->8---->8---->8---->8---->8----

To me this output is correct.

3) From a DOS shell inside emacs-25 instance, launched by `M-x shell', I
launch the following command, that is equivalent to the first one:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
%EMACS% --batch -Q --eval "(princ load-path)" ^
   > %TEMP%\load-path-inside-emacs-dos.txt 2>&1
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

Then I get the following output:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
(c:/Nos_Programmes/GNU/Emacs_build20170614/share/emacs/26.0.50/lisp)Warning: 
arch-dependent data dir 
'c:/Nos_Programmes/GNU/Emacs_build20170614/libexec/emacs/26.0.50/i686-pc-mingw32/':
 Permission denied
Warning: Lisp directory 
'c:/Nos_Programmes/GNU/Emacs_build20170614/share/emacs/26.0.50/lisp': Invalid 
argument
Warning: Could not find simple.el or simple.elc
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

The text up to `)' is stdout, and the remainder is stderr. To me this
output is wrong.

Please note that this has nothing to do with console being DOS or MSYS,
but it has to do with. I did the experiment the other way out (using a
DOS console outside Emacs, and an MSYS console inside Emacs). I get the
correct output when launching the command from outside Emacs, and the
wrong output when launching the command from inside another instance of
Emacs.

VBR,
        Vincent.

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus