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.
