.profile not being loaded (ksh) when opening shell in X

[t***@danwin1210.me]

I have some custom additions to my $PATH. They're defined in ~/.profile
and they are correctly loaded when I log in from a text console.

When I log in to X (cwm) and open a terminal window, $PATH does not
contain the entries.

I tried `chmod +x` on my .profile but that didn't help.

Both the text console and the X terminal window are using ksh.

When I call `/bin/ksh -l` then the resulting shell contains the correct
additions to $PATH.

It looks like the custom $PATH is not being passed from the login shell
on downwards, since ~/.profile is only read by a login shell.

~/.kshrc is (according to ksh(1)) read by every spawning shell, but I
don't see any documentation or examples on the Internet where someone
defined their $PATH in ~/.kshrc ...

What's the correct way to set $PATH and have it stick no matter where
and when the shell is spawned?

[Jan Vlach]

Hi,

you need:

xterm*loginShell: true

in ~/.xresources and something like xrdb ~/.Xresources in ~/.xsession

JV

I have some custom additions to my $PATH. They're defined in ~/.profile and
they are correctly loaded when I log in from a text console.
When I log in to X (cwm) and open a terminal window, $PATH does not contain
the entries.
I tried `chmod +x` on my .profile but that didn't help.
Both the text console and the X terminal window are using ksh.
When I call `/bin/ksh -l` then the resulting shell contains the correct
additions to $PATH.
It looks like the custom $PATH is not being passed from the login shell on
downwards, since ~/.profile is only read by a login shell.
~/.kshrc is (according to ksh(1)) read by every spawning shell, but I don't
see any documentation or examples on the Internet where someone defined
their $PATH in ~/.kshrc ...
What's the correct way to set $PATH and have it stick no matter where and
when the shell is spawned?

[Daniel Wilkins]

Post by Jan Vlach
Hi,
xterm*loginShell: true
in ~/.xresources and something like xrdb ~/.Xresources in ~/.xsession
JV

I have some custom additions to my $PATH. They're defined in ~/.profile and
they are correctly loaded when I log in from a text console.
When I log in to X (cwm) and open a terminal window, $PATH does not contain
the entries.
I tried `chmod +x` on my .profile but that didn't help.
Both the text console and the X terminal window are using ksh.
When I call `/bin/ksh -l` then the resulting shell contains the correct
additions to $PATH.
It looks like the custom $PATH is not being passed from the login shell on
downwards, since ~/.profile is only read by a login shell.
~/.kshrc is (according to ksh(1)) read by every spawning shell, but I don't
see any documentation or examples on the Internet where someone defined
their $PATH in ~/.kshrc ...
What's the correct way to set $PATH and have it stick no matter where and
when the shell is spawned?

Could also just source your profile in your .xsession. That's what I'm in the
habit of doing.

[Pierre-Philipp Braun]

Post by Daniel Wilkins
Could also just source your profile in your .xsession. That's what I'm in the
habit of doing.

I believe there's no need for neither login-shells nor those X-level
tricks. To load the interactive environment into xterms or screen, I
usually to define ENV accordingly in /etc/profile or .profile. Not sure
it's the right way to also put PATH in (k)shrc, but it would also work.

/etc/profile: export ENV=/etc/shrc

or

~/.profile: export ENV=/root/.shrc

[t***@danwin1210.me]

Post by Pierre-Philipp Braun

Post by Daniel Wilkins
Could also just source your profile in your .xsession. That's what I'm in the
habit of doing.

I believe there's no need for neither login-shells nor those X-level
tricks. To load the interactive environment into xterms or screen, I
usually to define ENV accordingly in /etc/profile or .profile. Not
sure it's the right way to also put PATH in (k)shrc, but it would also
work.
/etc/profile: export ENV=/etc/shrc
or
~/.profile: export ENV=/root/.shrc

That's very interesting. Can someone explain what this does?

[Daniel Wilkins]

Post by t***@danwin1210.me

Post by Pierre-Philipp Braun
I believe there's no need for neither login-shells nor those X-level
tricks. To load the interactive environment into xterms or screen, I
usually to define ENV accordingly in /etc/profile or .profile. Not sure
it's the right way to also put PATH in (k)shrc, but it would also work.
/etc/profile: export ENV=/etc/shrc
or
~/.profile: export ENV=/root/.shrc

That's very interesting. Can someone explain what this does?

This is incorrect (see upthread.) ENV is for setting what your interactive rc
ought to be. You usually point it at ~/.kshrc. If your session hasn't loaded
~/.profile in order to load $ENV then the kshrc won't necessarily be loaded
by your shell no matter what. For ~/.profile to be in your environmnt you
definitely need to load it in your xsession.

Danny

[Allan Streib]

Post by t***@danwin1210.me
It looks like the custom $PATH is not being passed from the login shell
on downwards, since ~/.profile is only read by a login shell.

I just was looking into the same thing last night. The ksh shell in the
xterm didn't seem to be processing my .profile. Adding the '-ls'
argument to the xterm command resolved that.

-ls This option indicates that the shell that is started in the
xterm window will be a login shell (i.e., the first character
of argv[0] will be a dash, indicating to the shell that it
should read the user's .login or .profile).

Allan

[t***@danwin1210.me]

Post by Allan Streib

Post by t***@danwin1210.me
It looks like the custom $PATH is not being passed from the login shell
on downwards, since ~/.profile is only read by a login shell.

I just was looking into the same thing last night. The ksh shell in the
xterm didn't seem to be processing my .profile. Adding the '-ls'
argument to the xterm command resolved that.
-ls This option indicates that the shell that is started in the
xterm window will be a login shell (i.e., the first character
of argv[0] will be a dash, indicating to the shell that it
should read the user's .login or .profile).

Thanks. Yes, that would work, but I feel like the contents of ~/.profile
should be available to other commands as well, not just the xterm
window.

[Alexandre Ratchov]

I have some custom additions to my $PATH. They're defined in ~/.profile and
they are correctly loaded when I log in from a text console.
When I log in to X (cwm) and open a terminal window, $PATH does not contain
the entries.
I tried `chmod +x` on my .profile but that didn't help.
Both the text console and the X terminal window are using ksh.
When I call `/bin/ksh -l` then the resulting shell contains the correct
additions to $PATH.
It looks like the custom $PATH is not being passed from the login shell on
downwards, since ~/.profile is only read by a login shell.
~/.kshrc is (according to ksh(1)) read by every spawning shell, but I don't
see any documentation or examples on the Internet where someone defined
their $PATH in ~/.kshrc ...
What's the correct way to set $PATH and have it stick no matter where and
when the shell is spawned?

If you're using a display manager (xenodm or whatever), you've to
include your .profile in your session login script (X equivalent of
shell's ~/.profile concept), so the envoronment (and other global
login settings) from your .profile become visible to all X programs,
not only xterm. For instance put:

. ~/.profile

at the beginning of our ~/.xsession

If you're using xinit(1), your ~/.profile is already loaded by
the login shell.

[t***@danwin1210.me]

Post by Alexandre Ratchov
If you're using a display manager (xenodm or whatever), you've to
include your .profile in your session login script (X equivalent of
shell's ~/.profile concept), so the envoronment (and other global
login settings) from your .profile become visible to all X programs,
. ~/.profile
at the beginning of our ~/.xsession
If you're using xinit(1), your ~/.profile is already loaded by
the login shell.

That seems the right way to go, if the other suggested solution of
defining ENV doesn't do the trick.

[Otto Moerbeek]

Post by Alexandre Ratchov
If you're using a display manager (xenodm or whatever), you've to
include your .profile in your session login script (X equivalent of
shell's ~/.profile concept), so the envoronment (and other global
login settings) from your .profile become visible to all X programs,
. ~/.profile
at the beginning of our ~/.xsession
If you're using xinit(1), your ~/.profile is already loaded by
the login shell.

That seems the right way to go, if the other suggested solution of defining
ENV doesn't do the trick.

Note that ENV processing is only done for interactive shells.
Traditionally, ENV would point the a ~/.kshrc file that contains init
commands only relevant for interactive use. See the ksh man page for
details.

-Otto

[David Dahlberg]

Post by Alexandre Ratchov
If you're using a display manager (xenodm or whatever), you've to
include your .profile in your session login script (X equivalent of
shell's ~/.profile concept), so the envoronment (and other global
login settings) from your .profile become visible to all X programs,
        . ~/.profile

I noticed the effect that the OP described ($PWD and $HOME/.profile
being ignored) too, when I reinstalled all packages (due to /usr/local
partition going foobar) and also switched to Mate a couple of weeks
ago. Happens both in mate-terminal and in xterm.

Unfortunately tricks like described above didn't help. I think, I also
tried Xfce and had the same effect, not sure though. Strangely, if I
open a new mate-terminal, $PWD and .profile are ignored; If I open the
second tab, they are processed, though ...

So I guess the next step is to upgrade to todays snap and test, I it
stays the same, and wheter I may reproduce it with a more basic WM like
CWM/FVWM ...

[David Dahlberg]

Post by David Dahlberg
I noticed the effect that the OP described ($PWD and $HOME/.profile
being ignored) too

After some testing of different WM/DE (Xenodm to FVWM, CWM, Xfce,
Lumina, Mate) and terminal emulators, I have to conclude, that the
effect seems to be limited to Mate. Are you using Mate, Jan?

[Jan Vlach]

Hi David,

Post by David Dahlberg

Post by David Dahlberg
I noticed the effect that the OP described ($PWD and $HOME/.profile
being ignored) too

After some testing of different WM/DE (Xenodm to FVWM, CWM, Xfce,
Lumina, Mate) and terminal emulators, I have to conclude, that the
effect seems to be limited to Mate. Are you using Mate, Jan?

I'm using i3 and xterms started via xenodm. I also used WindowMaker with
plain xterms. I also set fonts and colors via .Xresources, so it works.

AFAIK, mate has it's own terminal emulator in the desktop environment.
No idea if it honors Xresources.

JV

[Stuart Henderson]

Post by t***@danwin1210.me
I have some custom additions to my $PATH. They're defined in ~/.profile
and they are correctly loaded when I log in from a text console.
When I log in to X (cwm) and open a terminal window, $PATH does not
contain the entries.
I tried `chmod +x` on my .profile but that didn't help.
Both the text console and the X terminal window are using ksh.
When I call `/bin/ksh -l` then the resulting shell contains the correct
additions to $PATH.
It looks like the custom $PATH is not being passed from the login shell
on downwards, since ~/.profile is only read by a login shell.

Seems that your terminal in X is not configured to run a login shell.
By default that is done for xterm via .Xdefaults in a new user's profile
directory (copied from /etc/skel) but if you use a different terminal
or have modified these files, that won't be used.

Post by t***@danwin1210.me
~/.kshrc is (according to ksh(1)) read by every spawning shell, but I
don't see any documentation or examples on the Internet where someone
defined their $PATH in ~/.kshrc ...

That is only if ENV is set.

Post by t***@danwin1210.me
What's the correct way to set $PATH and have it stick no matter where
and when the shell is spawned?

If it's just PATH or some other environment variable, setting it for
the relevant class in /etc/login.conf is one option. But probably
simpler to configure your X terminal to run login shells.

[Allan Streib]

Post by Stuart Henderson
Seems that your terminal in X is not configured to run a login shell.
By default that is done for xterm via .Xdefaults in a new user's profile
directory (copied from /etc/skel) but if you use a different terminal
or have modified these files, that won't be used.

With the caveat that I have not perused all possibly relevant configs on
my system, my install is fairly standard and my ~/.Xdefaults file has:

! $OpenBSD: dot.Xdefaults,v 1.3 2014/07/10 10:22:59 jasper Exp $
XTerm*loginShell:true

Yet if I run an xterm from my window manager (aweswome) it does not read
my ~/.profile. I worked around this by using the '-ls' argument to
xterm, but maybe that's hiding the real reason this is happening. I have
not tried any other window managers. For good measure, here is my
~/.xsession:

xrdb -merge ~/.Xresources
xset +fp /usr/local/share/fonts/Liberation,/usr/local/share/fonts/ghostscript,/usr/local/share/fonts/cantarell,/usr/local/share/fonts/noto
autocutsel -fork &
autocutsel -selection PRIMARY -fork &
xset mouse 4/1 4
xset r rate 200 50
exec awesome

Allan

[Leon Fischer]

Date: Tue, 27 Apr 2021 14:54:48 -0400

Post by Stuart Henderson
Seems that your terminal in X is not configured to run a login shell.
By default that is done for xterm via .Xdefaults in a new user's profile
directory (copied from /etc/skel) but if you use a different terminal
or have modified these files, that won't be used.

With the caveat that I have not perused all possibly relevant configs on
! $OpenBSD: dot.Xdefaults,v 1.3 2014/07/10 10:22:59 jasper Exp $
XTerm*loginShell:true
Yet if I run an xterm from my window manager (aweswome) it does not read
my ~/.profile. I worked around this by using the '-ls' argument to
xterm, but maybe that's hiding the real reason this is happening. I have
not tried any other window managers. For good measure, here is my
xrdb -merge ~/.Xresources

There's your problem. If you run xrdb(1) then ~/.Xdefaults won't be
evaluated. Move the contents of your ~/.Xdefaults into ~/.Xresources if
you still want to use xrdb(1).

xset +fp /usr/local/share/fonts/Liberation,/usr/local/share/fonts/ghostscript,/usr/local/share/fonts/cantarell,/usr/local/share/fonts/noto
autocutsel -fork &
autocutsel -selection PRIMARY -fork &
xset mouse 4/1 4
xset r rate 200 50
exec awesome
Allan

[Allan Streib]

If you run xrdb(1) then ~/.Xdefaults won't be evaluated.

Well that's interesting and good to know, thanks! That doesn't seem
obvious from looking at mentions of "Xdefaults" in either the X(7) or
xrdb(1) man pages, unless it's implied in this from xdrb(1):

Xrdb does not load any files on its own, but many desktop environments
use xrdb to load ~/.Xresources files on session startup to initialize
the resource database, as a generalized replacement for ~/.Xdefaults
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Allan