From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr Date: Mon, 26 Sep 2022 10:56:10 +0300 Message-ID: <83h70ulgbp.fsf@gnu.org> References: <87pmfjmqnt.fsf@bernoul.li> <83tu4vl9wr.fsf@gnu.org> <87mtanmhn6.fsf@bernoul.li> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18289"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58073@debbugs.gnu.org To: Jonas Bernoulli Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 26 10:11:11 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ocjCp-0004eF-7P for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Sep 2022 10:11:11 +0200 Original-Received: from localhost ([::1]:59618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ocjCo-0006TR-5z for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Sep 2022 04:11:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ociz9-00063H-5g for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2022 03:57:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50114) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ociz8-00025M-NJ for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2022 03:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ociz8-0000eX-8h for bug-gnu-emacs@gnu.org; Mon, 26 Sep 2022 03:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Sep 2022 07:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58073 X-GNU-PR-Package: emacs Original-Received: via spool by 58073-submit@debbugs.gnu.org id=B58073.16641789932471 (code B ref 58073); Mon, 26 Sep 2022 07:57:02 +0000 Original-Received: (at 58073) by debbugs.gnu.org; 26 Sep 2022 07:56:33 +0000 Original-Received: from localhost ([127.0.0.1]:49192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ociye-0000dn-FD for submit@debbugs.gnu.org; Mon, 26 Sep 2022 03:56:32 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42450) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ociyc-0000da-UT for 58073@debbugs.gnu.org; Mon, 26 Sep 2022 03:56:31 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52336) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ociyU-0001xw-TW; Mon, 26 Sep 2022 03:56:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Dcbk0fLFC39lc7rpRbkGUkK4/2Y4zzCwTk2Vl4EIMVE=; b=nOQ5L8UPZuXM E0qFGzudIvhMs9eBv82drKNn4rzTJ4PJ9qw1l8eF7z9qlMkQcQWAEb2nGlGQbIG6gQ66oW5or1X15 zBotgwRoNPO+Dy8OP+nogxQXa9eUOmkTBZlwRvzKXsjW6Bn68NCiteebKvivT+ghiHZUHqxwY1HpA DgRuwWybqHNbylREEbjU1U69img5bU5TcnV8l0Tz09NuT9jmGAUf+JFlwcgbzWybBedRmY778sz2r 5lOTk9ZT66pnoLLlxqR9K9MKSfpL22BTjG2dcSLOCS9rj6Yw8owY7CpZw7jmudrVPareEzms8qwU4 P+mg9kT/85mabXVpyvBQug==; Original-Received: from [87.69.77.57] (port=2528 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ociyS-000842-O0; Mon, 26 Sep 2022 03:56:22 -0400 In-Reply-To: <87mtanmhn6.fsf@bernoul.li> (message from Jonas Bernoulli on Sun, 25 Sep 2022 20:30:05 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:243628 Archived-At: > From: Jonas Bernoulli > Cc: 58073@debbugs.gnu.org > Date: Sun, 25 Sep 2022 20:30:05 +0200 > > Installing emacs using guix sets EMACSLOADPATH in a file that is sourced > by the shells startup file. To me it looks like they are abusing this > variable; it makes it impossible to use an emacs that wasn't installed > using guix, without something to counter their modification. I did that > with a wrapper script. > > The value that is set somewhere in the shell's init files is something > like "/home/jonas/.guix-home/profile/share/emacs/site-lisp". It doesn't > contain an empty element, which would "stand for the default value of > `load-path'", according to (info "(emacs)General Variables"). > > The side startup file is located inside this directory and contains > > (when (require 'guix-emacs nil t) > (guix-emacs-autoload-packages) > (advice-add 'package-load-all-descriptors :after > #'guix-emacs-load-package-descriptors)) > > The file "guix-emacs.el" is located in the same directory. So the > purpose of setting EMACSLOADPATH seems to be to allow using `require' to > load that file. This doesn't seem right to me, they could just as well > extend the load-path inside "site-lisp.el", or load their additional > init file using `load'. > > To deal with the incomplete EMACSLOADPATH, as set in the shell > environment, they use a wrapper script named "emacs" and located on PATH: > > #!/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash > export XDG_DATA_DIRS="/gnu/store/h6qdfd4sjdg28jq16600hcjky0cfw9gx-shared-mime-info-1.15/share:/gnu/store/bnsf9il448hl5xjavbhq3rcx355svz2v-glib-2.70.2/share:/gnu/store/7njbpmsgwmx59xn2r6q097iy2wwscb44-gtk+-3.24.30/share:/gnu/store/w0ssipd06il3kvyvqihpmw4lwbhwwfq3-emacs-28.1/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" > export GTK_PATH="/gnu/store/7njbpmsgwmx59xn2r6q097iy2wwscb44-gtk+-3.24.30/lib/gtk-3.0${GTK_PATH:+:}$GTK_PATH" > export PATH="$PATH${PATH:+:}/gnu/store/0c1yfbxyv877mlgychfgvmk5ha2jqh52-gzip-1.10/bin:/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin" > export EMACSLOADPATH="$EMACSLOADPATH${EMACSLOADPATH:+:}/gnu/store/w0ssipd06il3kvyvqihpmw4lwbhwwfq3-emacs-28.1/share/emacs/28.1/lisp" > exec -a "$0" "/gnu/store/w0ssipd06il3kvyvqihpmw4lwbhwwfq3-emacs-28.1/bin/.emacs-28.1-real" "$@" > > I am under the impression that they should stop setting EMACSLOADPATH > and should either invent their own variable to replace that or load > "guix-emacs.el" using simpler means as I suggested above. I tend to agree. I don't understand why they "invade" EMACSLOADPATH: that is supposed to be left to the users. > > Emacs has special support for running from the build tree, but in your > > case it somehow doesn't realize that. > > As a side-note, the wrapper script that I previously used looked like > this: > > #!/bin/sh > export EMACSLOADPATH="\ > /home/jonas/.guix-home/profile/share/emacs/site-lisp:\ > /home/jonas/src/emacs/emacs/lisp" > exec -a "$0" "/home/jonas/src/emacs/emacs/src/emacs" "$@" > > The build tree is at "/home/jonas/src/emacs/emacs"; I think the value I > set above is correct (correct me if I am wrong), so it seems that when > running from the build tree EMACSLOADPATH has to be unset; explicitly > doubling down on the defaults doesn't work. I also tried with an empty > element. Your EMACSLOADPATH is not entirely correct, I think: it doesn't include the subdirectories of /home/jonas/src/emacs/emacs/lisp. All in all, when you run Emacs either from the source tree, or from the place where it was configured to be installed, there should be no need to set EMACSLOADPATH, and doing so without being VERY careful could indeed get you in trouble.