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

From: Anders Lindgren <[email-masked]>
Date: Tue, 8 Dec 2015 20:16:29 +0100

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