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