bug#21104: 25.0.50; relative paths are added to load-path without -nsl

bug#21104: 25.0.50; relative paths are added to load-path without -nsl

[Sam Steingold]

Relative paths in `load-path' seems like a bad idea:

--8<---------------cut here---------------start------------->8---
$ ./nextstep/Emacs.app/Contents/MacOS/Emacs -nsl --batch --eval '(print load-path)'

("/Users/sds/src/emacs/trunk/lisp" "/Users/sds/src/emacs/trunk/lisp/vc" "/Users/sds/src/emacs/trunk/lisp/url" "/Users/sds/src/emacs/trunk/lisp/textmodes" "/Users/sds/src/emacs/trunk/lisp/progmodes" "/Users/sds/src/emacs/trunk/lisp/play" "/Users/sds/src/emacs/trunk/lisp/org" "/Users/sds/src/emacs/trunk/lisp/nxml" "/Users/sds/src/emacs/trunk/lisp/net" "/Users/sds/src/emacs/trunk/lisp/mh-e" "/Users/sds/src/emacs/trunk/lisp/mail" "/Users/sds/src/emacs/trunk/lisp/leim" "/Users/sds/src/emacs/trunk/lisp/language" "/Users/sds/src/emacs/trunk/lisp/international" "/Users/sds/src/emacs/trunk/lisp/gnus" "/Users/sds/src/emacs/trunk/lisp/eshell" "/Users/sds/src/emacs/trunk/lisp/erc" "/Users/sds/src/emacs/trunk/lisp/emulation" "/Users/sds/src/emacs/trunk/lisp/emacs-lisp" "/Users/sds/src/emacs/trunk/lisp/cedet" "/Users/sds/src/emacs/trunk/lisp/calendar" "/Users/sds/src/emacs/trunk/lisp/calc" "/Users/sds/src/emacs/trunk/lisp/obsolete" "/Users/sds/src/emacs/trunk/build/lisp")
$ ./nextstep/Emacs.app/Contents/MacOS/Emacs --batch --eval '(print load-path)'

("." "./vc" "./url" "./textmodes" "./progmodes" "./play" "./org" "./nxml" "./net" "./mh-e" "./mail" "./leim" "./language" "./international" "./gnus" "./eshell" "./erc" "./emulation" "./emacs-lisp" "./cedet" "./calendar" "./calc" "./obsolete" "/Users/sds/src/emacs/trunk/lisp" "/Users/sds/src/emacs/trunk/lisp/vc" "/Users/sds/src/emacs/trunk/lisp/url" "/Users/sds/src/emacs/trunk/lisp/textmodes" "/Users/sds/src/emacs/trunk/lisp/progmodes" "/Users/sds/src/emacs/trunk/lisp/play" "/Users/sds/src/emacs/trunk/lisp/org" "/Users/sds/src/emacs/trunk/lisp/nxml" "/Users/sds/src/emacs/trunk/lisp/net" "/Users/sds/src/emacs/trunk/lisp/mh-e" "/Users/sds/src/emacs/trunk/lisp/mail" "/Users/sds/src/emacs/trunk/lisp/leim" "/Users/sds/src/emacs/trunk/lisp/language" "/Users/sds/src/emacs/trunk/lisp/international" "/Users/sds/src/emacs/trunk/lisp/gnus" "/Users/sds/src/emacs/trunk/lisp/eshell" "/Users/sds/src/emacs/trunk/lisp/erc" "/Users/sds/src/emacs/trunk/lisp/emulation" "/Users/sds/src/emacs/trunk/lisp/emacs-lisp" "/Users/sds/src/emacs/trunk/lisp/cedet" "/Users/sds/src/emacs/trunk/lisp/calendar" "/Users/sds/src/emacs/trunk/lisp/calc" "/Users/sds/src/emacs/trunk/lisp/obsolete" "/Users/sds/src/emacs/trunk/build/lisp")
--8<---------------cut here---------------end--------------->8---

in particular, this results in this start-up warning:


--8<---------------cut here---------------start------------->8---
Warning (initialization): Your `load-path' seems to contain
your `.emacs.d' directory: .
This is likely to cause problems...
Consider using a subdirectory instead, e.g.: /Users/sds/.emacs.d/lisp
--8<---------------cut here---------------end--------------->8---


In GNU Emacs 25.0.50.2 (x86_64-apple-darwin14.4.0, NS appkit-1348.17 Version 10.10.4 (Build 14E46))
 of 2015-07-21 on sds-MacBook-Pro.local
Repository revision: 7f58daf8166d03c664e5a6d1984dc3afd74e08d2
Windowing system distributor `Apple', version 10.3.1348
Configured using:
 `configure --with-ns'

Configured features:
JPEG IMAGEMAGICK NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LANG: C
  locale-coding-system: utf-8-unix

Major mode: C/lah

Minor modes in effect:
  diff-auto-refine-mode: t
  rcirc-track-minor-mode: t
  which-function-mode: t
  url-handler-mode: t
  show-paren-mode: t
  desktop-save-mode: t
  shell-dirtrack-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
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  abbrev-mode: t

Recent messages:
Grep finished with no matches found
Quit
Grep finished (matches found)
mouse-2: visit this file and line [2 times]
Quit
mouse-2: visit this file and line
Mark saved where search started [2 times]
Grep finished (matches found)
mouse-2: visit this file and line
C-x p is undefined

Load-path shadows:
None found.

Features:
(shadow sort bbdb-message mailalias cookie1 mail-extr gnus-msg gnus-art
mm-uu mml2015 mm-view mml-smime smime dig mailcap gnus-sum gnus-group
gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls utf7 netrc
nnoo parse-time gnus-spec gnus-int gnus-range gnus-win emacsbug message
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums edmacro kmacro
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
find-dired grep ffap time-stamp dabbrev cl-indent skeleton eieio-opt
speedbar sb-image ezimage dframe find-func pp markdown-mode noutline
outline misearch multi-isearch remember dired-aux nxml-uchnm rng-xsd
xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse
nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode
nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok sh-script smie
flyspell ispell info vc-hg smerge-mode python tramp-sh tramp
tramp-compat tramp-loaddefs trampver json vc-git diff-mode easy-mmode
vc-dir ewoc vc vc-dispatcher finder-inf package epg-config dired
warnings midnight gnus gnus-ems nnheader mail-utils wid-edit bbdb-mua
bbdb-com crm mailabbrev bbdb-loaddefs bbdb bbdb-site timezone rcirc
server which-func imenu url-handlers url-parse auth-source cl-seq eieio
byte-opt bytecomp byte-compile cl-extra cconv eieio-core cl-macs
gnus-util mm-util help-fns help-mode mail-prsvr password-cache url-vars
paren help-at-pt desktop frameset cus-start cus-load ido seq ess-toolbar
ess-mouse mouseme thingatpt browse-url ess-menu ess-swv ess-noweb
ess-noweb-font-lock-mode ess-bugs-l essd-els ess-sas-d ess-sas-l
ess-sas-a shell pcomplete ess-sta-d ess-sta-l cc-vars cc-defs
make-regexp ess-sp6-d ess-sp3-d ess-julia ess-r-d ess-r-completion
compile ess-tracebug format-spec ess-roxy advice hideshow ess-help
ess-developer ess-s-l ess ess-inf comint ansi-color ring ess-mode
ess-noweb-mode ess-utils ess-custom executable easymenu ess-compat
ess-site cl gv cl-loaddefs pcase cl-lib time-date mule-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
ns-win term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core 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 charscript case-table epa-hook jka-cmpr-hook help
simple abbrev 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
gfilenotify cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 567215 13667)
 (symbols 48 69494 0)
 (miscs 40 21339 937)
 (strings 32 203226 22330)
 (string-bytes 1 4960712)
 (vectors 16 59780)
 (vector-slots 8 1043715 8139)
 (floats 8 829 414)
 (intervals 56 8535 472)
 (buffers 976 62))

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1348
http://www.childpsy.net/ http://iris.org.il http://www.memritv.org
http://americancensorship.org http://www.dhimmitude.org http://camera.org
I'd give up my right arm to be ambidextrous.

bug#21104: workaround for the bug

[Sam Steingold]

workaround:

(setq load-path (cl-delete-if-not #'file-name-absolute-p load-path))

See also http://emacs.stackexchange.com/q/12145/795

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1348
http://www.childpsy.net/ http://www.memritv.org http://memri.org
http://honestreporting.com http://think-israel.org http://mideasttruth.com
The past is gone, the present is ephemeral, the future is a guess.

bug#21104: 25.0.50; relative paths are added to load-path without -nsl

[Glenn Morris]

Is this how a (relocatable) Nextstep build has always behaved, or is it "new"?

bug#21104: 25.0.50; relative paths are added to load-path without -nsl

[Sam Steingold]

this is not new.
I have been seeing this warning since at least April.
however, I traced this to the relative paths only now.

On Wed, Jul 22, 2015 at 2:02 PM, Glenn Morris <rgm@gnu.org> wrote:
>
> Is this how a (relocatable) Nextstep build has always behaved, or is it "new"?



-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>

bug#21104: 25.0.50; relative paths are added to load-path without -nsl

[Glenn Morris]

Sam Steingold wrote:

> this is not new.
> I have been seeing this warning since at least April.

By "new" I meant does Emacs 23.x, 24.x do this?
Has it always been like this?
If not and it is a "recent" change, bisecting might be helpful.

bug#21104: 25.0.50; relative paths are added to load-path without -nsl

[Sam Steingold]

Well, then this _is_ new.


On Wed, Jul 22, 2015 at 2:37 PM, Glenn Morris <rgm@gnu.org> wrote:
> Sam Steingold wrote:
>
>> this is not new.
>> I have been seeing this warning since at least April.
>
> By "new" I meant does Emacs 23.x, 24.x do this?
> Has it always been like this?
> If not and it is a "recent" change, bisecting might be helpful.



-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net/>

bug#21104: 25.0.50; relative paths are added to load-path without -nsl

[Glenn Morris]

Sam Steingold wrote:

> Well, then this _is_ new.

Then as I said, it would be helpful for someone to pinpoint when this started.
(It should be easy using nightly builds from

http://emacsformacosx.com/builds/all )

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 4343 bytes --]

Hi,

I decided to take a look at this, as I think it should be solved before
Emacs 25 is released.

Unfortunately, I haven't found the cause of it, bit I would like to share
what I found so far.

First, the call to `get_current_dir_name' in `init_buffer' returns an
absolute path, so this is not the cause.

After annotating the `bset_directory' function, I see the following:

bset_directory:
  buffer=*scratch* (/Users/anderslindgren/build/emacs-25/src/)
  current_buffer=*scratch* (/Users/anderslindgren/build/emacs-25/src/)
  new_directory=/Users/anderslindgren/build/emacs-25/
bset_directory:
  buffer= *Minibuf-0* (/Users/anderslindgren/build/emacs-25/src/)
  current_buffer=*scratch* (/Users/anderslindgren/build/emacs-25/)
  new_directory=/Users/anderslindgren/build/emacs-25/
bset_directory:
  buffer= *Minibuf-0* (/Users/anderslindgren/build/emacs-25/)
  current_buffer=*scratch* (/Users/anderslindgren/build/emacs-25/)
  new_directory=/Users/anderslindgren/build/emacs-25/
bset_directory:
  buffer= *load* (<NOT STRING>)
  current_buffer=*scratch* (.)
  new_directory=.
bset_directory:
  buffer= *load* (.)
  current_buffer=*scratch*
(/Users/anderslindgren/build/emacs-25/nextstep/Emacs.app/Contents/Resources/site-lisp)

new_directory=/Users/anderslindgren/build/emacs-25/nextstep/Emacs.app/Contents/Resources/site-lisp
bset_directory:
  buffer= *load* (<NOT STRING>)
  current_buffer=*scratch*
(/Users/anderslindgren/build/emacs-25/nextstep/Emacs.app/Contents/Resources/lisp)

new_directory=/Users/anderslindgren/build/emacs-25/nextstep/Emacs.app/Contents/Resources/lisp
bset_directory:
  buffer= *temp* (<NOT STRING>)
  current_buffer=*scratch* (/Users/anderslindgren/build/emacs-25/)
  new_directory=/Users/anderslindgren/build/emacs-25/

Clearly, the directory of *scratch* change from an absolute path to "."
between two calls to bset_directory. The way I see it that is that the
change does not originate from the C parts of Emacs.

After firing up gdb and setting a data break point on
"current_buffer->directory_" I see that it triggers as follows:

  * bset_directory (setting the directory to an absolute path)
  * set_buffer_internal_1 (twice, setting the directory to an absolute path)
  * set_per_buffer_value (see below)
  * bset_direcory (here, *scratch* already has "." in the directory field)

It looks like the call to `set_per_buffer_value' is causing this. This is
the backtrace at this point:

#0  0x000000010010d4c9 in set_per_buffer_value [inlined] () at
/Users/anderslindgren/build/emacs-25/src/buffer.h:1080
#1  0x000000010010d4c9 in store_symval_forwarding (valcontents=0x101898ac8,
newval=4304500124, buf=0x100900a98) at data.c:1080
#2  0x00000001001583c6 in exec_byte_code (bytestr=4320758472,
vector=140734799802712, maxdepth=140734799802488, args_template=2, nargs=0,
args=0x7fff5fbff250) at bytecode.c:842
#3  0x0000000100122ad9 in apply_lambda (fun=4298488197, args=<value
temporarily unavailable, due to optimizations>, count=3) at eval.c:2794
#4  0x0000000100120c9e in eval_sub (form=<value temporarily unavailable,
due to optimizations>) at eval.c:2241
#5  0x000000010012353c in Feval (form=4320886083, lexical=<value
temporarily unavailable, due to optimizations>) at eval.c:1988
#6  0x000000010011fa43 in internal_condition_case (bfun=0x1000b1d60
<top_level_2>, handlers=<value temporarily unavailable, due to
optimizations>, hfun=0x1000b4930 <cmd_error>) at eval.c:1309
#7  0x00000001000b2d78 in top_level_1 (ignore=<value temporarily
unavailable, due to optimizations>) at keyboard.c:1103
#8  0x000000010011faa7 in internal_catch (tag=<value temporarily
unavailable, due to optimizations>, func=0x1000b2d20 <top_level_1>, arg=0)
at eval.c:1074
#9  0x00000001000b1c02 in command_loop () at keyboard.c:1064
#10 0x00000001000b1cde in recursive_edit_1 () at keyboard.c:671
#11 0x00000001000b4bbf in Frecursive_edit () at keyboard.c:742
#12 0x00000001000aa763 in main (argc=5, argv=0x7fff5fbff6f0) at emacs.c:1656


Unfortunately, I can't make head of tails of this, as gdb seems to be
thrown off track as soon as I try to print anything or walk in the call
stack.

However, to my untrained eye, it looks like Emacs is evaluating elisp code.

What can I do to pinpoint which elisp code this is? Can I rebuild emacs
with other settings, making it more gdb friendly?

Sincerely,
    Anders Lindgren

[-- Attachment #2: Type: text/html, Size: 5358 bytes --]

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Eli Zaretskii]

> Date: Mon, 7 Dec 2015 20:00:21 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: Keith David Bershatsky <esq@lawlist.com>
> 
> It looks like the call to `set_per_buffer_value' is causing this. This is the
> backtrace at this point:
> 
> #0 0x000000010010d4c9 in set_per_buffer_value [inlined] () at
> /Users/anderslindgren/build/emacs-25/src/buffer.h:1080
> #1 0x000000010010d4c9 in store_symval_forwarding (valcontents=0x101898ac8,
> newval=4304500124, buf=0x100900a98) at data.c:1080
> #2 0x00000001001583c6 in exec_byte_code (bytestr=4320758472,
> vector=140734799802712, maxdepth=140734799802488, args_template=2, nargs=0,
> args=0x7fff5fbff250) at bytecode.c:842
> #3 0x0000000100122ad9 in apply_lambda (fun=4298488197, args=<value temporarily
> unavailable, due to optimizations>, count=3) at eval.c:2794
> #4 0x0000000100120c9e in eval_sub (form=<value temporarily unavailable, due to
> optimizations>) at eval.c:2241
> #5 0x000000010012353c in Feval (form=4320886083, lexical=<value temporarily
> unavailable, due to optimizations>) at eval.c:1988
> #6 0x000000010011fa43 in internal_condition_case (bfun=0x1000b1d60
> <top_level_2>, handlers=<value temporarily unavailable, due to optimizations>,
> hfun=0x1000b4930 <cmd_error>) at eval.c:1309
> #7 0x00000001000b2d78 in top_level_1 (ignore=<value temporarily unavailable,
> due to optimizations>) at keyboard.c:1103
> #8 0x000000010011faa7 in internal_catch (tag=<value temporarily unavailable,
> due to optimizations>, func=0x1000b2d20 <top_level_1>, arg=0) at eval.c:1074
> #9 0x00000001000b1c02 in command_loop () at keyboard.c:1064
> #10 0x00000001000b1cde in recursive_edit_1 () at keyboard.c:671
> #11 0x00000001000b4bbf in Frecursive_edit () at keyboard.c:742
> #12 0x00000001000aa763 in main (argc=5, argv=0x7fff5fbff6f0) at emacs.c:1656
> 
> Unfortunately, I can't make head of tails of this, as gdb seems to be thrown
> off track as soon as I try to print anything or walk in the call stack.
> 
> However, to my untrained eye, it looks like Emacs is evaluating elisp code.
> 
> What can I do to pinpoint which elisp code this is? Can I rebuild emacs with
> other settings, making it more gdb friendly?

Are you saying that xbacktrace doesn't work at this point?

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

> Are you saying that xbacktrace doesn't work at this point?


I'm new to gdb, so I don't know what xbacktrace is... What happen is that
after i try to print things, say "p SDATA(current_buffer->directory_)", gdb
no longer see the same call stack etc.

Anyway, I think I have tracked down the problem. In my generated
"epaths.h", there is a bad value for PATH_SITELOADSEARCH:

#define PATH_SITELOADSEARCH ""

I think this cause "." to be added to the load path in "init_lread" (I can
verify this tomorrow).

I have configured Emacs using "./configure --with-ns --without-dbus".

    -- Anders

[-- Attachment #2: Type: text/html, Size: 770 bytes --]

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Glenn Morris]

Anders Lindgren wrote:

> #define PATH_SITELOADSEARCH ""
>
> I think this cause "." to be added to the load path in "init_lread" (I can
> verify this tomorrow).

Sounds like unintended fallout from b9d8edcf6dbe; ie the cure for the
minor issue of #19850 is worse than the disease.

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Glenn Morris]

PS this would explain why http://debbugs.gnu.org/21353#24 saw no issue
with emacsformacosx.com builds. They pass an explicit
--enable-locallisppath to configure:

https://github.com/caldwell/build-emacs/commit/86e4c4d3bb383d02bf0826688235bd588133b2e9

ironically as an alternative solution to http://debbugs.gnu.org/19850,
which they opened, thereby masking the problem that the official
solution caused. It's all a conspiracy! ;)

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Keith David Bershatsky <esq@lawlist.com>,  21104@debbugs.gnu.org
> Date: Mon, 07 Dec 2015 20:22:01 -0500
> 
> Anders Lindgren wrote:
> 
> > #define PATH_SITELOADSEARCH ""
> >
> > I think this cause "." to be added to the load path in "init_lread" (I can
> > verify this tomorrow).
> 
> Sounds like unintended fallout from b9d8edcf6dbe; ie the cure for the
> minor issue of #19850 is worse than the disease.

Does the patch below solve the problem?

(Does anyone know why we call decode_env_path with last argument zero
in this case?  I don't see how that could make any sense here.)

diff --git a/src/lread.c b/src/lread.c
index 0da5819..c70a7b0 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -4356,7 +4356,7 @@ init_lread (void)
           if (!no_site_lisp)
             {
               Lisp_Object sitelisp;
-              sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 0);
+              sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 1);
               if (! NILP (sitelisp))
                 default_lpath = nconc2 (sitelisp, default_lpath);
             }
@@ -4387,7 +4387,7 @@ init_lread (void)
       if (initialized && !no_site_lisp)
         {
           Lisp_Object sitelisp;
-          sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 0);
+          sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 1);
           if (! NILP (sitelisp)) Vload_path = nconc2 (sitelisp, Vload_path);
         }
     }

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> (Does anyone know why we call decode_env_path with last argument zero
> in this case?  I don't see how that could make any sense here.)

In which way does that make a difference?  Both "." and nil mean the
same thing, namely default-directory.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Glenn Morris <rgm@gnu.org>,  esq@lawlist.com,  andlind@gmail.com,  21104@debbugs.gnu.org
> Date: Tue, 08 Dec 2015 18:06:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > (Does anyone know why we call decode_env_path with last argument zero
> > in this case?  I don't see how that could make any sense here.)
> 
> In which way does that make a difference?  Both "." and nil mean the
> same thing, namely default-directory.

Maybe I'm blind, but my reading of the code in init_lread indicates
that it does make a difference:

          Lisp_Object sitelisp;
          sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 0);
          if (! NILP (sitelisp)) Vload_path = nconc2 (sitelisp, Vload_path);

My reading of this is that if we call decode_env_path with last
argument non-zero, it will return nil, and Vload_path will not be
modified by adding anything.  What am I missing?

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe I'm blind, but my reading of the code in init_lread indicates
> that it does make a difference:
>
>           Lisp_Object sitelisp;
>           sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 0);
>           if (! NILP (sitelisp)) Vload_path = nconc2 (sitelisp, Vload_path);
>
> My reading of this is that if we call decode_env_path with last
> argument non-zero, it will return nil, and Vload_path will not be
> modified by adding anything.  What am I missing?

decode_env_path never returns nil.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Glenn Morris]

Eli Zaretskii wrote:

> Does the patch below solve the problem?

If I read configure correctly, the same issue will occur on any platform
if configured with --enable-locallisppath=no, so you could try it out.

Which suggests this (undocumented?) option has never worked properly,
so one option is simply to remove that alternative and not allow
locallispath to be empty, and choose a better default on OS X.
One can always call emacs --no-site-lisp for the same effect.

> (Does anyone know why we call decode_env_path with last argument zero
> in this case? 

The last argument is a relatively new addition. Before it existed
decode_env_path behaved like it was zero. So when adding the new
argument the default was to use zero. Again, this suggests empty
locallispath never worked as intended.

But like Andreas, my guess would be that "." and nil are equivalent here.
Maybe you could just special-case it so that PATH_SITELOADSEARCH empty
acts like no_site_lisp is set?

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: andlind@gmail.com,  esq@lawlist.com,  21104@debbugs.gnu.org
> Date: Tue, 08 Dec 2015 12:54:52 -0500
> 
> But like Andreas, my guess would be that "." and nil are equivalent here.
> Maybe you could just special-case it so that PATH_SITELOADSEARCH empty
> acts like no_site_lisp is set?

Yes, that would also work.  Anders, can you try that?

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

Hi!

I tries both solutions. Passing "1" as the last argument to
`decode_env_path' doesn't work. When inspecting the code, it looks like it
runs at least one iteration in the loop (see the `while (1)'), so the
return value is either `(".")' or `(nil)', which is not what we want.

> But like Andreas, my guess would be that "." and nil are equivalent here.
> > Maybe you could just special-case it so that PATH_SITELOADSEARCH empty
> > acts like no_site_lisp is set?
>
> Yes, that would also work.  Anders, can you try that?
>

Yes, this works.


However, I think it's a better solution to correct `decode_env_path' so
that it returns nil when the string is empty and the `empty' parameter is 1.

Also, I haven't investigated the cases where there is nothing between path
separators, as in "foo::bar" (or when the string starts or ends with a
separator). Today, it looks like it returns either `("foo" "." "bar)' or
`("foo" nil "bar")' -- although I haven't verified this. A better solution
would be to simply return `("foo" "bar")' -- path separators without
anything in between are often simply a user mistake, we don't want to
pollute system variables like `load-path' because of them.

I would suggest that we rewrite the loop so that it ignores empty parts of
the string (at the start, between two separators, and at the end). After
the loop, if `lpath' is nil and `empty' is 0, add a single "." to `lpath'.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 2268 bytes --]

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Glenn Morris]

Anders Lindgren wrote:

> Yes, this works.
>
>
> However, I think it's a better solution to correct `decode_env_path' so
> that it returns nil when the string is empty and the `empty' parameter is 1.

I think you've jumped outside the scope of this report.
I would suggest just going with the simple solution, absent evidence of
some other problem.

> Also, I haven't investigated the cases where there is nothing between path
> separators, as in "foo::bar" (or when the string starts or ends with a
> separator). Today, it looks like it returns either `("foo" "." "bar)' or
> `("foo" nil "bar")' -- although I haven't verified this. A better solution
> would be to simply return `("foo" "bar")' -- path separators without
> anything in between are often simply a user mistake, we don't want to
> pollute system variables like `load-path' because of them.

The feature is intentional, see 17e0445be4a.

I won't claim it's perfect, but IIRC I did test such things at the time.

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Anders Lindgren]

[-- Attachment #1.1: Type: text/plain, Size: 1798 bytes --]

Hi,

On Tue, Dec 8, 2015 at 8:21 PM, Glenn Morris <rgm@gnu.org> wrote:

> I think you've jumped outside the scope of this report.
> I would suggest just going with the simple solution, absent evidence of
> some other problem.
>

I have attached a simple solution that solves this specific problem. I'll
push it if it looks like an OK solution for you.


> Also, I haven't investigated the cases where there is nothing between path
> > separators, as in "foo::bar" (or when the string starts or ends with a
> > separator). Today, it looks like it returns either `("foo" "." "bar)' or
> > `("foo" nil "bar")' -- although I haven't verified this. A better
> solution
> > would be to simply return `("foo" "bar")' -- path separators without
> > anything in between are often simply a user mistake, we don't want to
> > pollute system variables like `load-path' because of them.
>
> The feature is intentional, see 17e0445be4a.
>
> I won't claim it's perfect, but IIRC I did test such things at the time.
>

Apparently, there is more to the code than I initially understood. I agree
with you, I no longer think we should change anything here on the short
term.

However, I think it behaves strange:

For example (on a Linux machine):
    env EMACSPATH=::/home::/bar:: emacs -q --batch --eval '(print
exec-path)'
   ("/usr/lib/lightdm/lightdm" "/usr/local/sbin" "/usr/local/bin"
"/use/sbin" "/usr/bin" "/sbin" "/bin" "/usr/games" "." "." "/home" "." "."
"/bar" "." ".")

Here, I don't think the ".":s should be included.

Another example (again on Linux):
    env EMACSLOADPATH=::/home::/bar:: emacs -q --batch --eval '(print
load-path)'
    The result is too long to print, as it duplicates the standard load
path five times.

Here, wouldn't it suffice to add the default load path once?

    -- Anders

[-- Attachment #1.2: Type: text/html, Size: 3380 bytes --]

[-- Attachment #2: path.diff --]
[-- Type: text/plain, Size: 849 bytes --]

diff --git a/src/lread.c b/src/lread.c
index 0da5819..74a5fdf 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -4353,7 +4353,7 @@ init_lread (void)
           load_path_check (default_lpath);
 
           /* Add the site-lisp directories to the front of the default.  */
-          if (!no_site_lisp)
+          if (!no_site_lisp && PATH_SITELOADSEARCH[0] != '\0')
             {
               Lisp_Object sitelisp;
               sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 0);
@@ -4384,7 +4384,7 @@ init_lread (void)
       load_path_check (Vload_path);
 
       /* Add the site-lisp directories at the front.  */
-      if (initialized && !no_site_lisp)
+      if (initialized && !no_site_lisp && PATH_SITELOADSEARCH[0] != '\0')
         {
           Lisp_Object sitelisp;
           sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 0);

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Andreas Schwab]

Anders Lindgren <andlind@gmail.com> writes:

> However, I think it behaves strange:
>
> For example (on a Linux machine):
>     env EMACSPATH=::/home::/bar:: emacs -q --batch --eval '(print
> exec-path)'
>    ("/usr/lib/lightdm/lightdm" "/usr/local/sbin" "/usr/local/bin"
> "/use/sbin" "/usr/bin" "/sbin" "/bin" "/usr/games" "." "." "/home" "." "."
> "/bar" "." ".")
>
> Here, I don't think the ".":s should be included.

You get what you asked for.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Keith David Bershatsky <esq@lawlist.com>,  21104@debbugs.gnu.org,  Andreas Schwab <schwab@suse.de>
> Date: Tue, 08 Dec 2015 14:21:20 -0500
> 
> > However, I think it's a better solution to correct `decode_env_path' so
> > that it returns nil when the string is empty and the `empty' parameter is 1.
> 
> I think you've jumped outside the scope of this report.
> I would suggest just going with the simple solution, absent evidence of
> some other problem.

I agree.

bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104)

[Eli Zaretskii]

> Date: Mon, 7 Dec 2015 23:09:09 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: 21104@debbugs.gnu.org, Keith David Bershatsky <esq@lawlist.com>
> 
> > Are you saying that xbacktrace doesn't work at this point?
> 
> I'm new to gdb, so I don't know what xbacktrace is...

It's one of the many commands defined in src/.gdbinit.  If you start
GDB in the src directory, it should read that file automatically (or
loudly refuse to, for security reasons).  Failing that, type "source
/path/to/src/.gdbinit" to force GDB to read it.

Once you did that, just typing "xbacktrace" should show the Lisp
backtrace which should give you a clue what Lisp code is being run.

> What happen is that after
> i try to print things, say "p SDATA(current_buffer->directory_)", gdb no longer
> see the same call stack etc.

Don't do that.  Instead, do this:

  (gdb) p current_buffer->directory_
  (gdb) xstring

(Usually, it's better to make sure the value is a string by typing
"xtype" before "xstring".)

See etc/DEBUG for more useful hints.

bug#21104: Don't add "." to load-path -- fixed

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

When configured with --enable-locallisppath=no, which is the default for OS
X, the load-path incorrectly was populated with ".".

See the following for for information:

http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=ae3057412a0673667e76cd281e5c5db46be18254

    -- Anders Lindgren

[-- Attachment #2: Type: text/html, Size: 540 bytes --]