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

[Anders Lindgren]

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