From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: emacs doesn't inherit PATH from environment Date: Thu, 15 Feb 2018 13:18:53 -0700 Message-ID: <20180215124731840633831@bob.proulx.com> References: <874lmjma7g.fsf@robertthorpeconsulting.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1518725864 6374 195.159.176.226 (15 Feb 2018 20:17:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Feb 2018 20:17:44 +0000 (UTC) User-Agent: Mutt/1.9.3 (2018-01-21) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Feb 15 21:17:40 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emPy9-0000P3-GF for geh-help-gnu-emacs@m.gmane.org; Thu, 15 Feb 2018 21:17:25 +0100 Original-Received: from localhost ([::1]:56176 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emQ0B-0000Ih-3e for geh-help-gnu-emacs@m.gmane.org; Thu, 15 Feb 2018 15:19:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emPzf-0000He-EH for help-gnu-emacs@gnu.org; Thu, 15 Feb 2018 15:19:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emPza-0005Va-Re for help-gnu-emacs@gnu.org; Thu, 15 Feb 2018 15:18:59 -0500 Original-Received: from havoc.proulx.com ([96.88.95.61]:46459) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1emPza-0005VI-IK for help-gnu-emacs@gnu.org; Thu, 15 Feb 2018 15:18:54 -0500 Original-Received: from joseki.proulx.com (localhost [127.0.0.1]) by havoc.proulx.com (Postfix) with ESMTP id 7B470C55 for ; Thu, 15 Feb 2018 13:18:53 -0700 (MST) Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 4718A21243 for ; Thu, 15 Feb 2018 13:18:53 -0700 (MST) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 30C932DC6B; Thu, 15 Feb 2018 13:18:53 -0700 (MST) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 96.88.95.61 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:116022 Archived-At: Barry Fishman wrote: > Bob Proulx wrote: > > IMNHO the only sane thing to do in the ~/.xsessionrc file is to source > > the $HOME/.profile file. They are both portable shell syntax files. > > Then put all of your environment setting in ~/.profile the same as > > always. > > This does not work very well for me. In particular, I find most of my > systems now use Wayland, so I'm not sure .xsession* files are > meaningful. Ah, yes, Wayland. Yet another case where everything is different. > Even under X, various distributions may not reference the > ~/.sessionrc file in the session startup scripts, although I used to add > it to systems without it. Recently I just gave up. Unfortunately it seems every distro tried to do things their own way. > There seems to be a conflict between the freedesktop people and the > shell maintainers on how things should be setup, and the user is left in > the crossfire. I would say there seems to be a conflict between the freedesktop people and, well, everyone else. :-( The shell has had a stable API for decades. I don't see there being any conflict between the shell maintainers and anyone. They certainly are not making any changes in the last decade or so about it. We could be using the v7 Bourne shell here and nothing either of us has said would have substantially changed. (I don't consider the .bashrc part to be conceptually a problem with what we are discussing so far. Although I realize it adds another layer to it. Since for zsh users it would be .zshrc; or ENV=$HOME/.kshrc, or .cshrc, and so forth.) > There is now even a pam_env.so specific > "~/.pam_environment" method (with a whole new vaguely defined file > format) which sometimes works (but not always). That isn't supported on the systems I use, for example. And I don't think it is a good idea either. I think we should be using the standard interfaces that already exist and not creating new and different badly supported ways of doing the same thing differently. > Personally I find myself brute forcing, and adding a zz-path.sh to > /etc/profile.d so it gets called last (and doesn't get replaced in > system updates) and just does: > > if [ -f "${HOME}/.config/paths.sh" ]; then > . "${HOME}/.config/paths.sh" > fi I know you are using profile.d to react to what is happening around you. But I have a comment about use of profile.d in general. When packages put files in /etc/profile.d/foo.sh then I know that they do not understand that this makes it impossible to install something and have it immediately available. Because that env file won't be sourced and available until the user logs out and then logs back in again. For most people today if you tell them to log out and log back in again they might as well be rebooting their system. It's basically the same for them. Instead packages should install in such a way that whatever they are installing is immediately usable by the logged in user without needing to log out and back in again. I feel /etc/profile.d/foo.sh is a *HUGE* step backwards in usability. > And have my ~/.config/paths.sh file setup just environment information I > need for applications launched via the desktop, such as fixing PATH. > > My ~/.bashrc is a link to my ~/.profile, which does the right thing > based on its own determination of if my environment has already been set > or if it is an interactive shell. I think what you have done is a great workaround for you. However I still see it as a workaround and not a real solution. And even without looking at the details of what you needed to do to accomplish it I think 80% of users will have glazed eyes and be lost by it. > I start it with: > > --8<---------------cut here---------------start------------->8--- > if [ -z "$BASH" ]; then > complete () { > : > } > shopt () { > false > } > fi > --8<---------------cut here---------------end--------------->8--- > > To disable my bash specific parts when some other shell is invoked. I was wrong. It's not 80% it's 99.44% of users will not want this much complexity in their lives. :-) :-) [/me laughs] In summary I think the root cause of most of these environment problems is inconsistency. Most OS's are inconsistent with each other. And even within a single OS it is very inconsistent what should be done depending upon what you are using. /bin/login, ssh, X, Wayland, and so forth, are all different. They all use the shell and the shell is therefore by definition consistent with itself. But those all set up the shell in different ways. I think that is problem. > Emacs is still left with resolving things like where to find info > directories, but doesn't have to deal with fixing the environment. My biggest rant there has to do with info files not always being installed due to other long standing philosophical debates that I will leave elsewhere. But then if they are not installed the info command line utility falls back to displaying man pages. That makes people dislike info even more. :-( > [Rant about the freedesktop's ideas left for a more appropriate time/group] I'm right there with you! We should be having a beer in the pub and working out the problem. :-) Bob