From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#21104: 25.0.50; relative paths are added to load-path without -nsl (bug#21104) Date: Tue, 8 Dec 2015 21:03:01 +0100 Message-ID: References: <83mvtmcau2.fsf@gnu.org> <9aoae1wx8m.fsf@fencepost.gnu.org> <83h9jtc4eo.fsf@gnu.org> <6z4mfsu8pf.fsf@fencepost.gnu.org> <83wpsoby4s.fsf@gnu.org> <9ttwnsn3v3.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=001a11440176fa1832052668750d X-Trace: ger.gmane.org 1449605060 25881 80.91.229.3 (8 Dec 2015 20:04:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Dec 2015 20:04:20 +0000 (UTC) Cc: Andreas Schwab , Keith David Bershatsky , 21104@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 08 21:04:10 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a6OUc-0000Vi-EA for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Dec 2015 21:04:10 +0100 Original-Received: from localhost ([::1]:33303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6OUb-0006lb-Gz for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Dec 2015 15:04:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6OUX-0006lL-Oi for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2015 15:04:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a6OUU-0008A9-GB for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2015 15:04:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6OUU-0008A3-DI for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2015 15:04:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a6OUT-0007SI-Vr for bug-gnu-emacs@gnu.org; Tue, 08 Dec 2015 15:04:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Dec 2015 20:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21104 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21104-submit@debbugs.gnu.org id=B21104.144960501328615 (code B ref 21104); Tue, 08 Dec 2015 20:04:01 +0000 Original-Received: (at 21104) by debbugs.gnu.org; 8 Dec 2015 20:03:33 +0000 Original-Received: from localhost ([127.0.0.1]:43744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a6OU0-0007RR-Lc for submit@debbugs.gnu.org; Tue, 08 Dec 2015 15:03:33 -0500 Original-Received: from mail-vk0-f46.google.com ([209.85.213.46]:34039) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a6OTW-0007Qg-Vu for 21104@debbugs.gnu.org; Tue, 08 Dec 2015 15:03:30 -0500 Original-Received: by vkbs1 with SMTP id s1so27415459vkb.1 for <21104@debbugs.gnu.org>; Tue, 08 Dec 2015 12:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dNWVJZE/fnvuas6tInJkwD1tXPQ0Rt8iSI3/1ehqY3Y=; b=cIx18YszneONFojvLHCQu/IxZ3G/R35HnL4nANJeV2jxM3xeeBgeOPrCJut9V8FgFo ecurE3o2Vil7NUpZw0plOwBBz7dO2qDhfoWN7mOoOHIO3dWva3qyOomfaFOnJhLBDmFg sG3zYdeWgkNx6W/ILzJ4ijhcNHxVV9uKr7mmir8o06pBOJe44+O99IxTNpsBdY9RC0gl NqzXaKwk5TLFJ5Xan3fQsoXze+soPFxewpbT6SM3os5MpXqt0WIcLJ1ZmwErZIikQvOs fDhu5m3AHhzxRG4amt9nNUHveukcC46hei+R6iM6uzy/bMrCIhFYaqHuG4LqGNlQbUOU u3AQ== X-Received: by 10.31.10.199 with SMTP id 190mr1332855vkk.51.1449604981318; Tue, 08 Dec 2015 12:03:01 -0800 (PST) Original-Received: by 10.31.210.133 with HTTP; Tue, 8 Dec 2015 12:03:01 -0800 (PST) In-Reply-To: <9ttwnsn3v3.fsf@fencepost.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:109797 Archived-At: --001a11440176fa1832052668750d Content-Type: multipart/alternative; boundary=001a11440176fa182c052668750b --001a11440176fa182c052668750b Content-Type: text/plain; charset=UTF-8 Hi, On Tue, Dec 8, 2015 at 8:21 PM, Glenn Morris 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 --001a11440176fa182c052668750b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Tue, Dec 8, 2015 at 8:21 PM, Glenn M= orris <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 s= imple solution that solves this specific problem. I'll push it if it lo= oks 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 e= nds with a
> separator). Today, it looks like it returns either `("foo" &= quot;." "bar)' or
> `("foo" nil "bar")' -- although I haven't = verified this. A better solution
> would be to simply return `("foo" "bar")' -- p= ath 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 i= s more to the code than I initially understood. I agree with you, I no long= er think we should change anything here on the short term.

However, I think it b= ehaves strange:

For example (on a Linux machine):
=C2=A0 =C2=A0 env EMACSPATH=3D::/home::/bar:: emacs -q --batch --eval '= ;(print exec-path)'
=C2=A0 =C2=A0("= ;/usr/lib/lightdm/lightdm" "/usr/local/sbin" "/usr/loca= l/bin" "/use/sbin" "/usr/bin" "/sbin" &q= uot;/bin" "/usr/games" "." "." "/ho= me" "." "." "/bar" "." ".= ")

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

Another example= (again on Linux):
=C2=A0 =C2=A0 env EMACSL= OADPATH=3D::/home::/bar:: emacs -q --batch --eval '(print load-path)= 9;
=C2=A0 =C2=A0 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?

=C2=A0 =C2=A0 -- Anders

--001a11440176fa182c052668750b-- --001a11440176fa1832052668750d Content-Type: text/plain; charset=US-ASCII; name="path.diff" Content-Disposition: attachment; filename="path.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ihxssgix0 ZGlmZiAtLWdpdCBhL3NyYy9scmVhZC5jIGIvc3JjL2xyZWFkLmMKaW5kZXggMGRhNTgxOS4uNzRh NWZkZiAxMDA2NDQKLS0tIGEvc3JjL2xyZWFkLmMKKysrIGIvc3JjL2xyZWFkLmMKQEAgLTQzNTMs NyArNDM1Myw3IEBAIGluaXRfbHJlYWQgKHZvaWQpCiAgICAgICAgICAgbG9hZF9wYXRoX2NoZWNr IChkZWZhdWx0X2xwYXRoKTsKIAogICAgICAgICAgIC8qIEFkZCB0aGUgc2l0ZS1saXNwIGRpcmVj dG9yaWVzIHRvIHRoZSBmcm9udCBvZiB0aGUgZGVmYXVsdC4gICovCi0gICAgICAgICAgaWYgKCFu b19zaXRlX2xpc3ApCisgICAgICAgICAgaWYgKCFub19zaXRlX2xpc3AgJiYgUEFUSF9TSVRFTE9B RFNFQVJDSFswXSAhPSAnXDAnKQogICAgICAgICAgICAgewogICAgICAgICAgICAgICBMaXNwX09i amVjdCBzaXRlbGlzcDsKICAgICAgICAgICAgICAgc2l0ZWxpc3AgPSBkZWNvZGVfZW52X3BhdGgg KDAsIFBBVEhfU0lURUxPQURTRUFSQ0gsIDApOwpAQCAtNDM4NCw3ICs0Mzg0LDcgQEAgaW5pdF9s cmVhZCAodm9pZCkKICAgICAgIGxvYWRfcGF0aF9jaGVjayAoVmxvYWRfcGF0aCk7CiAKICAgICAg IC8qIEFkZCB0aGUgc2l0ZS1saXNwIGRpcmVjdG9yaWVzIGF0IHRoZSBmcm9udC4gICovCi0gICAg ICBpZiAoaW5pdGlhbGl6ZWQgJiYgIW5vX3NpdGVfbGlzcCkKKyAgICAgIGlmIChpbml0aWFsaXpl ZCAmJiAhbm9fc2l0ZV9saXNwICYmIFBBVEhfU0lURUxPQURTRUFSQ0hbMF0gIT0gJ1wwJykKICAg ICAgICAgewogICAgICAgICAgIExpc3BfT2JqZWN0IHNpdGVsaXNwOwogICAgICAgICAgIHNpdGVs aXNwID0gZGVjb2RlX2Vudl9wYXRoICgwLCBQQVRIX1NJVEVMT0FEU0VBUkNILCAwKTsK --001a11440176fa1832052668750d--