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

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

Bash isn't reading ~/.profile file when login from GNOME

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

Contents

  Bash isn't reading ~/.profile file when login from GNOME Vipul <finn02@disroot.org> - 2019-08-20 16:30 +0200
    Re: Bash isn't reading ~/.profile file when login from GNOME Greg Wooledge <wooledg@eeg.ccf.org> - 2019-08-20 16:40 +0200
      Re: Bash isn't reading ~/.profile file when login from GNOME Reco <recoverym4n@enotuniq.net> - 2019-08-20 16:50 +0200
      Re: Bash isn't reading ~/.profile file when login from GNOME Andrei POPESCU <andreimpopescu@gmail.com> - 2019-08-20 22:30 +0200
        Re: Bash isn't reading ~/.profile file when login from GNOME Greg Wooledge <wooledg@eeg.ccf.org> - 2019-08-20 22:50 +0200
          Re: Bash isn't reading ~/.profile file when login from GNOME Andrei POPESCU <andreimpopescu@gmail.com> - 2019-08-22 23:10 +0200
            Re: Bash isn't reading ~/.profile file when login from GNOME Greg Wooledge <wooledg@eeg.ccf.org> - 2019-08-22 23:20 +0200
              Re: Bash isn't reading ~/.profile file when login from GNOME Andrei POPESCU <andreimpopescu@gmail.com> - 2019-08-23 15:00 +0200
        Re: Bash isn't reading ~/.profile file when login from GNOME Vipul <finn02@disroot.org> - 2019-08-21 05:10 +0200
      Re: Bash isn't reading ~/.profile file when login from GNOME Vipul <finn02@disroot.org> - 2019-08-21 04:50 +0200
        Re: Bash isn't reading ~/.profile file when login from GNOME Greg Wooledge <wooledg@eeg.ccf.org> - 2019-08-21 15:20 +0200
          Re: Bash isn't reading ~/.profile file when login from GNOME Greg Wooledge <wooledg@eeg.ccf.org> - 2019-08-21 16:50 +0200
            Re: Bash isn't reading ~/.profile file when login from GNOME Greg Wooledge <wooledg@eeg.ccf.org> - 2019-08-21 17:10 +0200
          Re: Bash isn't reading ~/.profile file when login from GNOME Vipul <finn02@disroot.org> - 2019-08-22 21:10 +0200
            Re: Bash isn't reading ~/.profile file when login from GNOME Greg Wooledge <wooledg@eeg.ccf.org> - 2019-08-22 21:30 +0200

#213028 — Bash isn't reading ~/.profile file when login from GNOME

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

Hi there,

From few days, I'm trying find answer of a question "which program does
read ~/.profile if I login from graphical user interface (for ex: GNOME)?".

I'm trying to get colored man page output by sourcing ~/.less_termcap"
[1] file from ~/.profile [2] but, LESS_TERMCAP_xx unset and empty

$ hd <<< "$LESS_TERMCAP_mb"
00000000  0a                                                |.|
00000001

To fix this problem I've to source ~/.profile from gnome-terminal
(output after running `source ~/.profile` in gnome-terminal)

$ hd <<< "$LESS_TERMCAP_mb"
00000000  1b 5b 31 3b 33 32 6d 0a                           |.[1;32m.|
00000008

This problem only happens when I login from graphical interface whereas,
login from console works perfectly fine means value of LESS_TERMCAP_xx
set correctly and gets colored man page output.

I've asked this question on some IRC channels (#debian, ##linux, #bash)
but, didn't get the right answer. Some says
    * "Login from graphical interface doesn't trigger login shell" then
who reads ~/.profile file?
    * "Bash isn't started as login shell" but bash is my default login
shell which I verified by login from console and check default login
shell entry in /etc/passwd file.
    * "Graphical Desktop Managers don't read ~/.profile file" with which
I agreed. But, I've a counter question if no one reads ~/.profile file,
how does value of PATH variable set correctly which I've set in
~/.profile file.

$ echo "$PATH"
/home/finn/.local/bin:/home/finn/.local/bin:/home/finn/.local/lib/npm/bin:/home/finn/scripts:/home/finn/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games


From this, I've concluded that some program must reads ~/.profile when I
login from graphical interface but, not by bash may be some other shell
(for ex: sh, ksh etc) despite of being bash as default login shell.
Please correct if I'm wrong.

Any help would be greatly appreciated.

## Additional info:

Debian Stretch (v9.9) with GNOME interface.

$ bash --version
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)

## References:

[1]: https://salsa.debian.org/snippets/316 (link to ~/.less_termcap file)
[2]: https://salsa.debian.org/snippets/314 (link to ~/.profile file)

[toc] | [next] | [standalone]

#213029

On Tue, Aug 20, 2019 at 02:27:40PM +0000, Vipul wrote:
> Hi there,
> 
> From few days, I'm trying find answer of a question "which program does
> read ~/.profile if I login from graphical user interface (for ex: GNOME)?".

https://wiki.debian.org/Xsession
https://wiki.debian.org/EnvironmentVariables

These are, of course, incomplete.

The short answer is: if you login through a Display Manager (a graphical
login program), NOTHING reads ~/.profile.  Ever.

So, let's try to guess what the actual goal is here.

If your goal is to set an environment variable in every program in your X
session, and you're not using GNOME, then you can put an export command
in ~/.xsessionrc and it should work great.

If you are using GNOME, please find out how to do it, and then tell us,
because as far as I've been able to determine, GNOME makes this completely
impossible.

Normal window managers run programs as children of themselves, using the
standard Unix fork-and-exec model.  The window manager is executed with
various environment variables, umask, resource limits, and so on, and
its children inherit these.  So, the standard Unix login configuration
stuff all works.  You edit a magic dot file, you login, the dot file is
read by a shell, the shell executes your window manager, the WM inherits
your desired environment, and everything launched from the WM also
inherits this environment.  Easy peasy.

But with GNOME, applications are launched by sending a message to dbus,
and then dbus spawns things as *its* children.  They are not children of
the WM.  They do not inherit the environment from the WM.  They inherit
the environment from dbus.

And there is no known way to configure the environment of dbus in a way
that is useful to end users.

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

#213030

On Tue, Aug 20, 2019 at 10:36:19AM -0400, Greg Wooledge wrote:
> And there is no known way to configure the environment of dbus in a way
> that is useful to end users.

dbus-update-activation-environment(1) says otherwise.

Reco

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

#213057

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

On Ma, 20 aug 19, 10:36:19, Greg Wooledge wrote:
> On Tue, Aug 20, 2019 at 02:27:40PM +0000, Vipul wrote:
> > Hi there,
> > 
> > From few days, I'm trying find answer of a question "which program does
> > read ~/.profile if I login from graphical user interface (for ex: GNOME)?".
> 
> https://wiki.debian.org/Xsession
> https://wiki.debian.org/EnvironmentVariables
> 
> These are, of course, incomplete.
> 
> The short answer is: if you login through a Display Manager (a graphical
> login program), NOTHING reads ~/.profile.  Ever.

Some (most?) X terminal emulators have the option to start a login 
shell, which would read ~/.profile.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#213058

On Tue, Aug 20, 2019 at 11:24:55PM +0300, Andrei POPESCU wrote:
> On Ma, 20 aug 19, 10:36:19, Greg Wooledge wrote:
> > On Tue, Aug 20, 2019 at 02:27:40PM +0000, Vipul wrote:
> > > Hi there,
> > > 
> > > From few days, I'm trying find answer of a question "which program does
> > > read ~/.profile if I login from graphical user interface (for ex: GNOME)?".
> > 
> > https://wiki.debian.org/Xsession
> > https://wiki.debian.org/EnvironmentVariables
> > 
> > These are, of course, incomplete.
> > 
> > The short answer is: if you login through a Display Manager (a graphical
> > login program), NOTHING reads ~/.profile.  Ever.
> 
> Some (most?) X terminal emulators have the option to start a login 
> shell, which would read ~/.profile.

Yeah, the old 1980s academia memes strike back.  We come full circle.

"I can't get GNOME to do anything I tell it, so I'll work around that
by making GNOME make dbus make footerminalizer run my shell as a login
shell, and that'll read my dot files that should've been read a dozen
processes ago!"

All the lessons that we learned, all the wisdom that we dispensed, all
the FAQs we wrote, all the heartache and agony and repetition, all the
sheer bloody WORK that we have put in for the last 20 years to try to
teach people the right way to do things...

... has all gone up in smoke, because of fucking GNOME.  You can't do
things the right way now.  You have to do them the wrong way.

And now people will think that running login shells in every terminal
session is the RIGHT way.  And thus we start from scratch.

Cue a thousand newbies asking why there's a .bashrc file and why it
doesn't get read unless they source it from their profile, and why
they can't just put everything in profile.  Cue ten thousand people
giving wrong answers, partly wrong answers, anecdotes, offtopic
digressions.

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

#213130

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

On Ma, 20 aug 19, 16:39:50, Greg Wooledge wrote:
> 
> And now people will think that running login shells in every terminal
> session is the RIGHT way.

Please do feel free to educate me on when/why it's wrong to run login 
shells instead of a plain interactive shell (or just point me to the 
relevant docs).

Thanks,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#213131

On Fri, Aug 23, 2019 at 12:01:09AM +0300, Andrei POPESCU wrote:
> On Ma, 20 aug 19, 16:39:50, Greg Wooledge wrote:
> > 
> > And now people will think that running login shells in every terminal
> > session is the RIGHT way.
> 
> Please do feel free to educate me on when/why it's wrong to run login 
> shells instead of a plain interactive shell (or just point me to the 
> relevant docs).

https://mywiki.wooledge.org/DotFiles gives some reasons.  Of course it
was written before systemd, and therefore doesn't cover all of the
recent contortions, revelations, intrigues, scandals and madness.  (And
it's a wiki, so some parts of the page aren't mine -- draw your own
conclusions about each piece of the content.)

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

#213139

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

On Jo, 22 aug 19, 17:15:17, Greg Wooledge wrote:
> On Fri, Aug 23, 2019 at 12:01:09AM +0300, Andrei POPESCU wrote:
> > On Ma, 20 aug 19, 16:39:50, Greg Wooledge wrote:
> > > 
> > > And now people will think that running login shells in every terminal
> > > session is the RIGHT way.
> > 
> > Please do feel free to educate me on when/why it's wrong to run login 
> > shells instead of a plain interactive shell (or just point me to the 
> > relevant docs).
> 
> https://mywiki.wooledge.org/DotFiles gives some reasons.  Of course it
> was written before systemd, and therefore doesn't cover all of the
> recent contortions, revelations, intrigues, scandals and madness.  (And
> it's a wiki, so some parts of the page aren't mine -- draw your own
> conclusions about each piece of the content.)

Thank you.

In my understanding there is no inherent harm in always starting a login 
shell, you are only loosing the option to separate stuff that you want 
to run always (.bashrc) or just at login (.profile[1])

Performance is also typically not a concern unless you run some heavy 
and/or network stuff in your .profile.

[1] in Debian's default configuration, which also takes care to source 
.bashrc if the login shell is bash. 

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#213064

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

Andrei POPESCU wrote:
> On Ma, 20 aug 19, 10:36:19, Greg Wooledge wrote:
>> On Tue, Aug 20, 2019 at 02:27:40PM +0000, Vipul wrote:
>>> Hi there,
>>>
>>> From few days, I'm trying find answer of a question "which program does
>>> read ~/.profile if I login from graphical user interface (for ex: GNOME)?".
>>
>> https://wiki.debian.org/Xsession
>> https://wiki.debian.org/EnvironmentVariables
>>
>> These are, of course, incomplete.
>>
>> The short answer is: if you login through a Display Manager (a graphical
>> login program), NOTHING reads ~/.profile.  Ever.
> 
> Some (most?) X terminal emulators have the option to start a login 
> shell, which would read ~/.profile.
> 

Probably, gnome-terminal is not a X terminal emulator but, it does able
to recognize variables set in ~/.profile file when login from GNOME
interface. Why is so?

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

#213063

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

Greg Wooledge wrote:
> On Tue, Aug 20, 2019 at 02:27:40PM +0000, Vipul wrote:
>> Hi there,
>>
>> From few days, I'm trying find answer of a question "which program does
>> read ~/.profile if I login from graphical user interface (for ex: GNOME)?".
> 
> https://wiki.debian.org/Xsession
> https://wiki.debian.org/EnvironmentVariables
> 
> These are, of course, incomplete.
> 
> The short answer is: if you login through a Display Manager (a graphical
> login program), NOTHING reads ~/.profile.  Ever.
> 

Try this if you're using GNOME with bash as a default shell. Export two
variables in $TEST_PRO and $TEST_BASH by adding these line `export
TEST_PRO="Hello from profile"` and `export TEST_BASH="Hello from bash"`
in ~/.profile and ~/.bash_profile file respectively.

Now, login from GNOME interface and run following command in gnome-terminal

$ echo "$TEST_PRO"
Hello from profile

$ echo "$TEST_BASH"

(output is empty string that means TEST_BASH variable is unset. see
below output of hd command)

$ hd <<< "$TEST_BASH"
00000000  0a                                                |.|
00000001

Whereas, login from console then behavior is reversed

$ echo "$TEST_PRO"

(output is empty string. see below output of hd command)

$ hd <<< "$TEST_PRO"
00000000  0a                                                |.|
00000001

$ echo "$TEST_BASH"
Hello from bash

which is kind of expected behavior because is presence of
~/.bash_profile file login shell (bash) will not read ~/.profile but,
not clear who reads ~/.profile when login from GNOME interface.
    I think, it's sh (bourne) shell because according to INVOCATION
section bash man page if bash is invoked as sh, it tries to mimic bash
behavior by reading ~/.profile.

This behavior have something to do with Debian default configuration not
with any part of graphical interface program.

> So, let's try to guess what the actual goal is here.
> 
> If your goal is to set an environment variable in every program in your X
> session, and you're not using GNOME, then you can put an export command
> in ~/.xsessionrc and it should work great.
> 
> If you are using GNOME, please find out how to do it, and then tell us,
> because as far as I've been able to determine, GNOME makes this completely
> impossible.
> 

I asked this on #gnome:gnome.org they said try ~/.config/environment.d/

> Normal window managers run programs as children of themselves, using the
> standard Unix fork-and-exec model.  The window manager is executed with
> various environment variables, umask, resource limits, and so on, and
> its children inherit these.  So, the standard Unix login configuration
> stuff all works.  You edit a magic dot file, you login, the dot file is
> read by a shell, the shell executes your window manager, the WM inherits
> your desired environment, and everything launched from the WM also
> inherits this environment.  Easy peasy.
> 
> But with GNOME, applications are launched by sending a message to dbus,
> and then dbus spawns things as *its* children.  They are not children of
> the WM.  They do not inherit the environment from the WM.  They inherit
> the environment from dbus.
> 
> And there is no known way to configure the environment of dbus in a way
> that is useful to end users.
> 

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

#213069

On Wed, Aug 21, 2019 at 02:48:45AM +0000, Vipul wrote:
> (output is empty string that means TEST_BASH variable is unset. see
> below output of hd command)
> 
> $ hd <<< "$TEST_BASH"
> 00000000  0a                                                |.|
> 00000001

I prefer printf %s "$variable" | od -tx1 -An

wooledg:~$ x=$'foo\r' y=''
wooledg:~$ printf %s "$x" | od -tx1 -An
 66 6f 6f 0d
wooledg:~$ printf %s "$y" | od -tx1 -An
wooledg:~$ 

Your test is also reasonable, as long as you understand that <<< adds
a newline (0a) which has to be accounted for.

> which is kind of expected behavior because is presence of
> ~/.bash_profile file login shell (bash) will not read ~/.profile but,
> not clear who reads ~/.profile when login from GNOME interface.

An excellent question, which only a GNOME user can answer.  I also
wonder whether you're performing your tests with your own regular
user account, or a brand new user account created specifically for
these tests.

If your tests give different results in a brand new user account, then
it's possible you've got some custom config in your regular account
that's distorting the results.

>     I think, it's sh (bourne) shell because according to INVOCATION
> section bash man page if bash is invoked as sh, it tries to mimic bash
> behavior by reading ~/.profile.

Yes, sh (either dash or bash) invoked as a login shell would read
~/.profile.  It's also possible that something else is explicitly dotting
in ~/.profile.  The first candidates that come to mind are ~/.gnomerc
or ~/.xsessionrc or something in a system-wide GNOME session or Debian
X session config file.

> This behavior have something to do with Debian default configuration not
> with any part of graphical interface program.

Possibly, but you'd have to *find* it to prove it.

> I asked this on #gnome:gnome.org they said try ~/.config/environment.d/

Hmm, that's new to me.  Took a couple tries to Google it, but I came up
with <https://www.freedesktop.org/software/systemd/man/environment.d.html>,
which is also apparently available as environment.d(5) locally.

It still isn't clear to me what actually READS these files, but it does
look like something that merits investigation.

On my system, there isn't much that's currently using them, but I did
find:

wooledg:~$ ls /etc/environment.d/
90qt-a11y.conf
wooledg:~$ cat /etc/environment.d/90qt-a11y.conf
QT_ACCESSIBILITY=1
wooledg:~$ env | grep QT
QT_ACCESSIBILITY=1


wooledg:~$ ls /usr/lib/environment.d/
99-environment.conf
wooledg:~$ cat /usr/lib/environment.d/99-environment.conf 
wooledg:~$ 


So apparently (a) it works, even for users like me who use console logins
plus startx, and (b) someone decided I needed QT_ACCESSIBILITY=1 in my
environment.

wooledg:~$ dpkg -S /etc/environment.d/90qt-a11y.conf
at-spi2-core: /etc/environment.d/90qt-a11y.conf

I don't even know what that is.


wooledg:~$ dpkg -s at-spi2-core
...
Priority: optional
...
Description: Assistive Technology Service Provider Interface (dbus core)
 This package contains the core components of GNOME Accessibility.


O... k...

wooledg:~$ aptitude why at-spi2-core
i   google-chrome-stable Depends    libatspi2.0-0 (>= 2.9.90)
i A libatspi2.0-0        Recommends at-spi2-core (= 2.30.0-7)

All right.  That one's on me, then.  That's what I get for using
third-party packages.  Anyway, it doesn't seem to be hurting anything.
And it's been an interesting investigation.


Finally, I'll point out this part of environment.d(5):

  CONFIGURATION FORMAT
       The configuration files contain a list of "KEY=VALUE" environment
       variable assignments, separated by newlines. The right hand side of
       these assignments may reference previously defined environment
       variables, using the "${OTHER_KEY}" and "$OTHER_KEY" format. It is also
       possible to use "${FOO:-DEFAULT_VALUE}" to expand in the same way as
       "${FOO}" unless the expansion would be empty, in which case it expands
       to DEFAULT_VALUE, and use "${FOO:+ALTERNATE_VALUE}" to expand to
       ALTERNATE_VALUE as long as "${FOO}" would have expanded to a non-empty
       value. No other elements of shell syntax are supported.

This is a huge and dramatic improvement over PAM's /etc/environment,
which can't even use $HOME in its variables.  But you still can't set
umask or resource limits.  So it's still not up to the power of ~/.profile,
but it's better than what we had a decade ago.  Maybe some day Desktop
Environments will finally catch up to the technological wizardry of the
1980s, but I'm not holding my breath.

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

#213072

On Wed, Aug 21, 2019 at 09:19:07AM -0400, Greg Wooledge wrote:
> On Wed, Aug 21, 2019 at 02:48:45AM +0000, Vipul wrote:
> > I asked this on #gnome:gnome.org they said try ~/.config/environment.d/

Further investigation of this thing.  So far, I am not impressed.

The first thing I attempted was to create a single file in this directory,
conforming to the documentation's requirements, with a single variable
in it.

wooledg:~$ ls -l .config/environment.d/69-foo.conf 
-rw-r--r-- 1 wooledg voice 14 Aug 21 09:17 .config/environment.d/69-foo.conf
wooledg:~$ cat "$_"
FOO=$HOME/bar

Then, I attempted to get this variable to show up in my login environment.
My first try: su - $LOGNAME.  This failed (variable not present).

My second try: logging in on tty2.  This failed.

I read some more man pages, poking around, trying to figure out how
this stuff works.  Or is supposed to work.

It turns out there is a command called "systemctl --user show-environment"
which is supposed to "Dump the systemd manager environment block.",
whatever THAT means.  And there are some related commands, like
"set-environment".  And I still have no idea what this "manager" is,
exactly, but there are "Manager Lifecycle Commands" like "daemon-reload"
to poke and prod.

So, I tried using "systemctl --user set-environment FOO=bar,baby" to
set a variable within this "manager environment block".  And I was
able to see this variable when I did "systemctl --user show-environment".

But this variable DOES NOT APPEAR in my environment when I login on tty2.
Neither does the variable in my ~/.config/environment.d/*.conf file.

I tried doing "sudo systemctl daemon-reload", because the man page says
that this "will rerun all generators (see systemd.generator(7))", which
sounds like the thing that environment.d(5) was talking about.

No success.  The variable still does not appear anywhere.


More poking around.  I got *somewhere* after reading systemd-logind(8)
which tells me:

       •   Keeping track of users and sessions, their processes and their idle
           state. This is implemented by allocating a systemd slice unit for
           each user below user.slice, and a scope unit below it for each
           concurrent session of a user. Also, a per-user service manager is
           started as system service instance of user@.service for each logged
           in user.

Well, that's not very clear to me, but at least I was able to find the
thing called "user.slice".  And indeed, underneath that in the process
tree view, there was a thing called "user-563.slice" (563 being my UID).

As it turns out, this "user-563.slice" is *not* respawned when I logout
and back in.  Logging ALL the way out of X (a pain in the ass), and then
logging out of tty1 (and tty2), and logging back in on tty1, I still
saw the start date on user-563.slice was prior to today.

So, the next thing I tried was "sudo systemctl restart user-563.slice",
while logged in as 563 on tty1.  I wasn't sure if this would log me out,
so I didn't want to try it while in X.

It did not log me out, but it DID cause my variable to finally appear
in the output of show-environment:

wooledg:~$ systemctl --user show-environment | grep FOO
FOO=/home/wooledg/bar

That's... progress, then?  Right?

As it turns out, the variable STILL DOES NOT APPEAR in my login session,
even after logging out and back in after restarting user-563.slice.

Next, I rebooted the whole system.

Anyone care to guess the result?  No?  OK, fine, I'll tell you: the
variable STILL DOES NOT APPEAR in my login session, even after a full
reboot.

wooledg:~$ env | grep FOO
wooledg:~$ 

You're all shocked, right?

So, I've discovered a way to make an environment variable appear in
the output of some random systemd administration command, but NOT in
an actual user's login session.

Finally, I tried to use the system-wide config directory which is
apparently successful in populating me with a QT variable, and see
if I could get it to give me one of my own.

wooledg:~$ sudo sh -c 'echo FOO=\$HOME/thissucks > /etc/environment.d/11-foo.conf'
[sudo] password for wooledg: 
wooledg:~$ su - $LOGNAME
Password: 
wooledg:~$ env | grep FOO
wooledg:~$ logout
wooledg:~$ sudo systemctl restart user-563.slice
wooledg:~$ su - $LOGNAME
Password: 
wooledg:~$ env | grep FOO
wooledg:~$ systemctl --user show-environment | grep FOO
Failed to connect to bus: No such file or directory

I have no idea what I broke *now*, but this shit is preposterous.

It turns out, that brokenness is only within the su - session.
systemctl --user show-environment works in all other terminals, and
in the same terminal after exiting from su -.  But still no success
in getting the environment variable to show up in my actual environment,
even logging in on tty2.

wooledg:~$ ls -l /etc/environment.d
total 8
-rw-r--r-- 1 root root 20 Aug 21 10:18 11-foo.conf
-rw-r--r-- 1 root root 19 Feb  9  2019 90qt-a11y.conf
wooledg:~$ cat /etc/environment.d/90qt-a11y.conf
QT_ACCESSIBILITY=1
wooledg:~$ cat /etc/environment.d/11-foo.conf
FOO=$HOME/thissucks

Seriously, what does it TAKE?  Why does QT's work but not mine?


Maybe if I wait another 10 years, someone will kill systemd and replace
it with something that doesn't suck, and then the next time a Desktop
Environment user asks for help configuring their environment, we'll be
able to say "Oh, you just edit ~/.config/qqz-profile and put commands
in there, and they'll run when you login, and it'll affect your whole
session, even the terminals, even if you run GOBLIN or the legacy GNOME
desktop."

Meanwhile, we're stuck with this.

I'll just stick with my console logins, and my login shells that actually
READ the config files that their manuals say they read, and I'll be able
to do stuff.  But every time a Desktop Environment user tries to do
anything, I'll just have to point to this thread and say "Sorry, I tried,
but it looks like your Desktop Environment just can't do it."

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

#213073

On Wed, Aug 21, 2019 at 10:43:18AM -0400, Greg Wooledge wrote:
> wooledg:~$ ls -l /etc/environment.d
> total 8
> -rw-r--r-- 1 root root 20 Aug 21 10:18 11-foo.conf
> -rw-r--r-- 1 root root 19 Feb  9  2019 90qt-a11y.conf
> wooledg:~$ cat /etc/environment.d/90qt-a11y.conf
> QT_ACCESSIBILITY=1
> wooledg:~$ cat /etc/environment.d/11-foo.conf
> FOO=$HOME/thissucks
> 
> Seriously, what does it TAKE?  Why does QT's work but not mine?

... because they're not actually doing it that way.

wooledg:~$ grep -rF QT_ACCESS /etc 2>/dev/null
/etc/X11/Xsession.d/90qt-a11y:QT_ACCESSIBILITY=1
/etc/X11/Xsession.d/90qt-a11y:export QT_ACCESSIBILITY
/etc/X11/Xsession.d/90qt-a11y:        dbus-update-activation-environment --verbose --systemd QT_ACCESSIBILITY
/etc/environment.d/90qt-a11y.conf:QT_ACCESSIBILITY=1

They spammed this variable in multiple places, hoping that at least
one of them would work.  Which... it did.  Just not the one I thought.


Also, I did some more Google searching and came across
<https://github.com/systemd/systemd/issues/7641>.  Which seems to be
saying "sorry, this isn't going to work, we didn't intend for these
environment variables to be used in user login environments".

So just what the hell are they FOR, then?

Another morning wasted on bullshit that does not work and is not ever
going to work and is not even going to be DOCUMENTED as not working.
I guess they enjoy watching us bash our heads against their brick walls
over and over.

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

#213126

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

Greg Wooledge wrote:
> On Wed, Aug 21, 2019 at 02:48:45AM +0000, Vipul wrote:
>> (output is empty string that means TEST_BASH variable is unset. see
>> below output of hd command)
>>
>> $ hd <<< "$TEST_BASH"
>> 00000000  0a                                                |.|
>> 00000001
> 
> I prefer printf %s "$variable" | od -tx1 -An
> 
> wooledg:~$ x=$'foo\r' y=''
> wooledg:~$ printf %s "$x" | od -tx1 -An
>  66 6f 6f 0d
> wooledg:~$ printf %s "$y" | od -tx1 -An
> wooledg:~$ 
> 
> Your test is also reasonable, as long as you understand that <<< adds
> a newline (0a) which has to be accounted for.
> 
>> which is kind of expected behavior because is presence of
>> ~/.bash_profile file login shell (bash) will not read ~/.profile but,
>> not clear who reads ~/.profile when login from GNOME interface.
> 
> An excellent question, which only a GNOME user can answer.

To know who actually reads ~/.profile I've set an environment variable
"SHELL_PRO" by adding `export SHELL_PRO=$(echo $0)` line in ~/.profile
file then re-login and typed following command in gnome-terminal

$ echo "$SHELL_PRO"
/etc/gdm3/Xsession

Is it reasonable test?

Similarly, I've done in ~/.bash_profile file (export SHELL_BASH=$(echo
$0)) and login from console

$ echo "$SHELL_BASH"
-bash

which is expected.

> I also wonder whether you're performing your tests with your own regular
> user account, or a brand new user account created specifically for
> these tests.
> 

On both means first, I face this issue on regular user account then,
test it on new user account.

> If your tests give different results in a brand new user account, then
> it's possible you've got some custom config in your regular account
> that's distorting the results.
> 

Test gives me same result on both accounts (regular user as well as
newer one).

>>     I think, it's sh (bourne) shell because according to INVOCATION
>> section bash man page if bash is invoked as sh, it tries to mimic bash
>> behavior by reading ~/.profile.
> 
> Yes, sh (either dash or bash) invoked as a login shell would read
> ~/.profile. 
> It's also possible that something else is explicitly dotting in ~/.profile.  

I think it's not. Here is my ~/.profile file:
https://salsa.debian.org/snippets/314

> The first candidates that come to mind are ~/.gnomerc
> or ~/.xsessionrc or something in a system-wide GNOME session or Debian
> X session config file.
> 
>> This behavior have something to do with Debian default configuration not
>> with any part of graphical interface program.
> 
> Possibly, but you'd have to *find* it to prove it.
> >> I asked this on #gnome:gnome.org they said try ~/.config/environment.d/
> 
> Hmm, that's new to me.  Took a couple tries to Google it, but I came up
> with <https://www.freedesktop.org/software/systemd/man/environment.d.html>,
> which is also apparently available as environment.d(5) locally.
> 
> It still isn't clear to me what actually READS these files, but it does
> look like something that merits investigation.

Systemd reads /etc/environment and files present in /etc/environment.d/
folder.

> 
> On my system, there isn't much that's currently using them, but I did
> find:
> 
> wooledg:~$ ls /etc/environment.d/
> 90qt-a11y.conf
> wooledg:~$ cat /etc/environment.d/90qt-a11y.conf
> QT_ACCESSIBILITY=1
> wooledg:~$ env | grep QT
> QT_ACCESSIBILITY=1
> 
> 
> wooledg:~$ ls /usr/lib/environment.d/
> 99-environment.conf
> wooledg:~$ cat /usr/lib/environment.d/99-environment.conf 
> wooledg:~$ 
> 
> 
> So apparently (a) it works, even for users like me who use console logins
> plus startx, and (b) someone decided I needed QT_ACCESSIBILITY=1 in my
> environment.
> 
> wooledg:~$ dpkg -S /etc/environment.d/90qt-a11y.conf
> at-spi2-core: /etc/environment.d/90qt-a11y.conf
> 
> I don't even know what that is.
> 
> 
> wooledg:~$ dpkg -s at-spi2-core
> ...
> Priority: optional
> ...
> Description: Assistive Technology Service Provider Interface (dbus core)
>  This package contains the core components of GNOME Accessibility.
> 
> 
> O... k...
> 
> wooledg:~$ aptitude why at-spi2-core
> i   google-chrome-stable Depends    libatspi2.0-0 (>= 2.9.90)
> i A libatspi2.0-0        Recommends at-spi2-core (= 2.30.0-7)
> 
> All right.  That one's on me, then.  That's what I get for using
> third-party packages.  Anyway, it doesn't seem to be hurting anything.
> And it's been an interesting investigation.
> 
> 
> Finally, I'll point out this part of environment.d(5):
> 
>   CONFIGURATION FORMAT
>        The configuration files contain a list of "KEY=VALUE" environment
>        variable assignments, separated by newlines. The right hand side of
>        these assignments may reference previously defined environment
>        variables, using the "${OTHER_KEY}" and "$OTHER_KEY" format. It is also
>        possible to use "${FOO:-DEFAULT_VALUE}" to expand in the same way as
>        "${FOO}" unless the expansion would be empty, in which case it expands
>        to DEFAULT_VALUE, and use "${FOO:+ALTERNATE_VALUE}" to expand to
>        ALTERNATE_VALUE as long as "${FOO}" would have expanded to a non-empty
>        value. No other elements of shell syntax are supported.
> 
> This is a huge and dramatic improvement over PAM's /etc/environment,
> which can't even use $HOME in its variables.  But you still can't set
> umask or resource limits.  So it's still not up to the power of ~/.profile,
> but it's better than what we had a decade ago.  Maybe some day Desktop
> Environments will finally catch up to the technological wizardry of the
> 1980s, but I'm not holding my breath.
> 

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

#213128

On Thu, Aug 22, 2019 at 07:07:08PM +0000, Vipul wrote:
> To know who actually reads ~/.profile I've set an environment variable
> "SHELL_PRO" by adding `export SHELL_PRO=$(echo $0)` line in ~/.profile
> file then re-login and typed following command in gnome-terminal
> 
> $ echo "$SHELL_PRO"
> /etc/gdm3/Xsession

Cool.  You can start reading stuff in and around there, to try to figure
out how a gdm3 login with this particular session type works.

> > It's also possible that something else is explicitly dotting in ~/.profile.  
> I think it's not. Here is my ~/.profile file:
> https://salsa.debian.org/snippets/314

That doesn't tell you who's dotting in ~/.profile.  But apparently you
found that out using your SHELL_PRO variable trick.

> Systemd reads /etc/environment and files present in /etc/environment.d/
> folder.

I covered this elsewhere in the thread.  It's technically true that some
part of systemd reads these files, but the contents of those files do
not appear in user login environments, ever.  At least not due to anything
that systemd does.

PAM reads /etc/environment and this causes the variables in THAT FILE
ONLY to appear in user login environments.  That has nothing to do
with systemd.

Systemd also reads that file, and populates "the environment exported
by the systemd user instance to the services it starts".  This does not
include login sessions.

[toc] | [prev] | [standalone]

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

csiph-web