Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #178181 > unrolled thread

The same environment variables everywhere

Back to article view | Back to linux.debian.user

Contents

  The same environment variables everywhere Teemu Likonen <tlikonen@iki.fi> - 2017-02-26 13:30 +0100
    Re: The same environment variables everywhere Matthias Bodenbinder <matthias@bodenbinder.de> - 2017-02-26 21:00 +0100
      Re: The same environment variables everywhere Stefan Monnier <monnier@iro.umontreal.ca> - 2017-02-27 06:00 +0100
        Re: The same environment variables everywhere deloptes <deloptes@gmail.com> - 2017-02-27 09:10 +0100
          Re: The same environment variables everywhere <tomas@tuxteam.de> - 2017-02-27 09:20 +0100
            Re: The same environment variables everywhere GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-02-27 12:40 +0100
              Re: The same environment variables everywhere Elimar Riesebieter <riesebie@lxtec.de> - 2017-02-27 13:40 +0100
            Re: The same environment variables everywhere Teemu Likonen <tlikonen@iki.fi> - 2017-02-27 14:30 +0100
              Re: The same environment variables everywhere David Wright <deblis@lionunicorn.co.uk> - 2017-02-27 18:10 +0100
                Re: The same environment variables everywhere Teemu Likonen <tlikonen@iki.fi> - 2017-02-27 19:00 +0100
                  Re: The same environment variables everywhere Nicolas George <george@nsup.org> - 2017-02-27 19:20 +0100
                    systemd service environment Teemu Likonen <tlikonen@iki.fi> - 2017-02-27 19:50 +0100
            Re: The same environment variables everywhere deloptes <deloptes@gmail.com> - 2017-02-27 19:30 +0100
    Re: The same environment variables everywhere Greg Wooledge <wooledg@eeg.ccf.org> - 2017-02-27 14:20 +0100

#178181 — The same environment variables everywhere

[Multipart message — attachments visible in raw view] — view raw

I would like to hear some ideas on how to set various environment
variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
effective everywhere. My "everywhere" means:

  - X session started through lightdm and ~/.xsession script
  - Linux console login (bash)
  - user's systemd services

Currently I define variables in ~/.profile and I import that file to
~/.xsession (with shell's source command: ". ~/.profile"). I also have
"systemd --user import-environment" command at the end of ~/.profile.

This works quite well but if there's a systemd user service that starts
automatically through ~/.config/systemd/user/default.target.wants/
symbolic link the service process doesn't get my variables. That's
probably because the service is started before my "systemd --user
import-environment" command.

Simple systemd user services don't need all the environment variables
but I'm also starting "emacs --daemon" as a systemd user service and for
that process I need my usual environment.

What would you do?

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[toc] | [next] | [standalone]

#178182

Am 26.02.2017 um 13:26 schrieb Teemu Likonen:
> I would like to hear some ideas on how to set various environment
> variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
> effective everywhere. My "everywhere" means:
> 
>   - X session started through lightdm and ~/.xsession script
>   - Linux console login (bash)
>   - user's systemd services

Put them into /etc/environment.
Matthias

[toc] | [prev] | [next] | [standalone]

#178184

>> I would like to hear some ideas on how to set various environment
>> variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
>> effective everywhere. My "everywhere" means:
>> - X session started through lightdm and ~/.xsession script
>> - Linux console login (bash)
>> - user's systemd services
> Put them into /etc/environment.

I haven't re-tried recently, but last time:
- It never worked for me.
- It can't hold user-specific settings.
- It can't *compute* a setting.


        Stefan

[toc] | [prev] | [next] | [standalone]

#178185

Stefan Monnier wrote:

>>> I would like to hear some ideas on how to set various environment
>>> variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
>>> effective everywhere. My "everywhere" means:
>>> - X session started through lightdm and ~/.xsession script
>>> - Linux console login (bash)
>>> - user's systemd services
>> Put them into /etc/environment.
> 
> I haven't re-tried recently, but last time:
> - It never worked for me.
> - It can't hold user-specific settings.
> - It can't *compute* a setting.
> 
> 
>         Stefan

IMO there is a good reason for so many places where you can put variables.
In fact it is not good to put X related variables in a non X session -
right?!
So I do distinguish between  settings for X session and for not X session -
at least two places for the variables.
Further more there are global and user specific ... etc

regards

[toc] | [prev] | [next] | [standalone]

#178186

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Feb 27, 2017 at 09:07:19AM +0100, deloptes wrote:
> Stefan Monnier wrote:
> 
> >>> I would like to hear some ideas on how to set various environment
> >>> variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
> >>> effective everywhere. My "everywhere" means:
> >>> - X session started through lightdm and ~/.xsession script
> >>> - Linux console login (bash)
> >>> - user's systemd services
> >> Put them into /etc/environment.
> > 
> > I haven't re-tried recently, but last time:
> > - It never worked for me.
> > - It can't hold user-specific settings.
> > - It can't *compute* a setting.
> > 
> > 
> >         Stefan
> 
> IMO there is a good reason for so many places where you can put variables.
> In fact it is not good to put X related variables in a non X session -
> right?!

There will be some that want to be different. There will be some that
want to be the same. The OP's question was about the latter, right?

> So I do distinguish between  settings for X session and for not X session -
> at least two places for the variables.
> Further more there are global and user specific ... etc

Yes, all of those! But I don't see how that's an answer to the OP's
legitimate question: how to keep things that belong together in one
place, instead of repeating it in every bit of config?

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliz32wACgkQBcgs9XrR2kbVmgCdHKWfY4folfhcY217hEGmjEdC
19wAnjlZrYwi5lqVCoAvj5bXWHf70qu+
=drZS
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#178197

tomas@tuxteam.de:
> On Mon, Feb 27, 2017 at 09:07:19AM +0100, deloptes wrote:
>> Stefan Monnier wrote:
> 
>>>>> I would like to hear some ideas on how to set various environment
>>>>> variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
>>>>> effective everywhere. My "everywhere" means:
>>>>> - X session started through lightdm and ~/.xsession script
>>>>> - Linux console login (bash)
>>>>> - user's systemd services
>>>> Put them into /etc/environment.

For a while I've been trying to set the locale but everytime I install a
package it returns locale not set returning to default C
I used /etc/environment, and no change.
I suspect this may be due to some skipped step on the original
installation as a similar installation on a similar machine does not
have this problem.  I have yet to locate the difference between the two.
I hope this is not perceived as hijacking.

Another possibly related problem I have is that although the language
env settings are for UTF8, non latin UTF8 valide characters if used as a
file name it is stored as ??????????.odt (example) This is a pain in the
posterior to have to rename them with a latin alphabet name and creates
all kinds of mix-up with doubling files.  Not that I want to create
filenames in other languages but downloading an archive of files with
such names makes the set unreadable (like an html set of files), the
local links break.


>>> I haven't re-tried recently, but last time:
>>> - It never worked for me.
>>> - It can't hold user-specific settings.
>>> - It can't *compute* a setting.
>>>
>>>
>>>         Stefan
> 
>> IMO there is a good reason for so many places where you can put variables.
>> In fact it is not good to put X related variables in a non X session -
>> right?!
> 
> There will be some that want to be different. There will be some that
> want to be the same. The OP's question was about the latter, right?
> 
>> So I do distinguish between  settings for X session and for not X session -
>> at least two places for the variables.
>> Further more there are global and user specific ... etc
> 
> Yes, all of those! But I don't see how that's an answer to the OP's
> legitimate question: how to keep things that belong together in one
> place, instead of repeating it in every bit of config?
> 
> regards
> -- tomás
> 

-- 
 "The most violent element in society is ignorance" rEG

[toc] | [prev] | [next] | [standalone]

#178199

* GiaThnYgeia <GiaThnYgeia@openmailbox.org> [2017-02-27 11:38 +0000]:

[...]
> For a while I've been trying to set the locale but everytime I install a
> package it returns locale not set returning to default C
> I used /etc/environment, and no change.
> I suspect this may be due to some skipped step on the original
> installation

Run as root:

# dpkg-reconfigure locales

You should have opened a new thread for that issue.

Elimar
-- 
    .~.
    /V\   L   I   N   U   X
   /( )\ >Phear the Penguin<
   ^^-^^

[toc] | [prev] | [next] | [standalone]

#178203

[Multipart message — attachments visible in raw view] — view raw

tomas@tuxteam.de [2017-02-27 09:12:28+01] wrote:

> On Mon, Feb 27, 2017 at 09:07:19AM +0100, deloptes wrote:
>> So I do distinguish between settings for X session and for not X
>> session - at least two places for the variables. Further more there
>> are global and user specific ... etc
>
> Yes, all of those! But I don't see how that's an answer to the OP's
> legitimate question: how to keep things that belong together in one
> place, instead of repeating it in every bit of config?

Yes. I know ~/.profile, ~/.xsession, systemd units' "Environment=...",
"systemctl --user import-enviroment" and various other things. I can
manage. I'm just asking for other ideas on how to handle things
mentioned in my original post.

Well, here's the idea of my current setup (not exact copy):

~/.profile:

    # Set the usual environment:
    export PATH=...
    export EDITOR=...
    systemctl --user import-enviroment

~/.xsession:

    . ~/.profile
    # Start various systemd services:
    systemctl --user start graphical-session.target
    /usr/bin/i3
    systemctl --user stop graphical-session.target

~/.config/systemd/user/emacs.service:

    [Unit]
    Description=The Emacs Operating System

    [Service]
    Type=forking
    ExecStart=/usr/bin/emacs --daemon
    SuccessExitStatus=15
    Restart=on-failure
    TimeoutStartSec=0
    TimeoutStopSec=0

    [Install]
    WantedBy=graphical-session.target

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[toc] | [prev] | [next] | [standalone]

#178218

On Mon 27 Feb 2017 at 15:19:27 (+0200), Teemu Likonen wrote:
> tomas@tuxteam.de [2017-02-27 09:12:28+01] wrote:
> 
> > On Mon, Feb 27, 2017 at 09:07:19AM +0100, deloptes wrote:
> >> So I do distinguish between settings for X session and for not X
> >> session - at least two places for the variables. Further more there
> >> are global and user specific ... etc
> >
> > Yes, all of those! But I don't see how that's an answer to the OP's
> > legitimate question: how to keep things that belong together in one
> > place, instead of repeating it in every bit of config?
> 
> Yes. I know ~/.profile, ~/.xsession, systemd units' "Environment=...",
> "systemctl --user import-enviroment" and various other things. I can
> manage. I'm just asking for other ideas on how to handle things
> mentioned in my original post.
> 
> Well, here's the idea of my current setup (not exact copy):
> 
> ~/.profile:
> 
>     # Set the usual environment:
>     export PATH=...
>     export EDITOR=...
>     systemctl --user import-enviroment

Is that typo actually in the file?

> ~/.xsession:
> 
>     . ~/.profile

My profile has side effects. Calling it from ~/.xsession
would repeat them, which would be undesirable.

I would be loath to just chuck everything in one place.
Unpicking an undesirable effect could be very tedious.

>     # Start various systemd services:
>     systemctl --user start graphical-session.target
>     /usr/bin/i3
>     systemctl --user stop graphical-session.target
> 
> ~/.config/systemd/user/emacs.service:
> 
>     [Unit]
>     Description=The Emacs Operating System
> 
>     [Service]
>     Type=forking

Have you tried putting an   EnvironmentFile=   in here
(man 5 systemd.service)? You could source the file from
elsewhere if required so that you only need one set of
definitions.

>     ExecStart=/usr/bin/emacs --daemon
>     SuccessExitStatus=15
>     Restart=on-failure
>     TimeoutStartSec=0
>     TimeoutStopSec=0
> 
>     [Install]
>     WantedBy=graphical-session.target

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#178219

[Multipart message — attachments visible in raw view] — view raw

David Wright [2017-02-27 10:56:55-06] wrote:

>>     systemctl --user import-enviroment
>
> Is that typo actually in the file?

No. I just (mis)typed those "files" here. In practice they contain quite
a lot more than that.

>> ~/.xsession:
>> 
>>     . ~/.profile
>
> My profile has side effects. Calling it from ~/.xsession
> would repeat them, which would be undesirable.

I moved my variable assignments to ~/.environment.sh and source that to
~/.profile and ~/.xsession.

> Have you tried putting an EnvironmentFile= in here (man 5
> systemd.service)? You could source the file from elsewhere if required
> so that you only need one set of definitions.

(EnvironmentFile's primary description is in systemd.exec(5).)

Doesn't work well with services that need X session which sets DISPLAY,
XAUTHORITY, GPG_AGENT_INFO, SSH_AUTH_SOCK and maybe other things. Some
of them have no static values. So, it's simpler to have things like:

~/.xsession:

    . ~/.environment.sh     # Import my variables.

    systemctl --user import-environment
    systemctl --user start [service-that-needs-X-session-environment]
    my-window-manager
    systemctl --user stop [service-that-needs-X-session-environment]

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[toc] | [prev] | [next] | [standalone]

#178224

[Multipart message — attachments visible in raw view] — view raw

Le nonidi 9 ventôse, an CCXXV, Teemu Likonen a écrit :
> I moved my variable assignments to ~/.environment.sh and source that to
> ~/.profile and ~/.xsession.

Zsh has a ~/.zshenv that is meant exactly for that. It is sourced by all
zsh instances, even those started as interpreters. It is very
convenient. I just have to make sure that ~/.xsession is a #!/bin/zsh
script, and it automatically gets the environment.

I start mine with:

[[ "$ZSHENV_USER" == $UID-1 ]] && return
export ZSHENV_USER=$UID-1

That way, I avoid re-sourcing the file if it has already been sourced by
an ancestor. Thus, I can change the environment of a subtree of
processes without having it overridden, but the environment is
re-sourced if I ever use su. The "-1" can be changed to force
re-sourcing the file by new shells, but I do not use it anymore.

I do not know what shell systemd uses to start user programs: the user's
login shell or /bin/sh. If it is the former, then it works for that case
too.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#178227 — systemd service environment

[Multipart message — attachments visible in raw view] — view raw

Nicolas George [2017-02-27 19:09:15+01] wrote:

> I do not know what shell systemd uses to start user programs:

It doesn't use shell at all. Systemd has its own parser for units'
ExecStart= lines and it's a lot more restricted than shells'. If more
control is needed the usual way is to have a launcher script:

    ExecStart=/usr/bin/my-service start
    ExecStop=/usr/bin/my-service stop

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[toc] | [prev] | [next] | [standalone]

#178225

tomas@tuxteam.de wrote:

> Yes, all of those! But I don't see how that's an answer to the OP's
> legitimate question: how to keep things that belong together in one
> place, instead of repeating it in every bit of config?

I use always /etc/profile for non user specific or X stuff.
Never had a problem with it.

regards

[toc] | [prev] | [next] | [standalone]

#178201

On Sun, Feb 26, 2017 at 02:26:08PM +0200, Teemu Likonen wrote:
> I would like to hear some ideas on how to set various environment
> variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
> effective everywhere. My "everywhere" means:
> 
>   - X session started through lightdm and ~/.xsession script
>   - Linux console login (bash)
>   - user's systemd services

The last one is simply not going to happen the way you seem to expect.
You should change the jobs launched by systemd to dot in the appropriate
file, instead of expecting systemd to load some interactive shell config
automatically.

As for the first two... well.  You know WHY there is a separation, right?
People put crap in .profile that would not work properly in an X config
file, because there is no terminal.  For example, /usr/games/fortune,
or something that probes the terminal settings.  The complete absence of
an underlying terminal, not to mention a TERM variable, would make many
.profile files fail, which is why .profile is not read by X startups.

However, if *you* have personally vetted your .profile and believe that
it will run safely in an X startup environment with no terminal, then
you can simply dot it in from ~/.xsessionrc and voila.

(Do not confuse ~/.xsessionrc and ~/.xsession; they are very different.)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web