[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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.
> 



Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: