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