Question regarding .xsession, .profile, .kshrc

[therue]

so, when using xenodm, it bypasses the console so .profile and .xinitrc won't be triggered? and instead what we normally put into those two should be placed in .xsession instead? (and to make sure URxvt*loginShell: true is set in .Xdefaults since I'm using urxvt instead of xterm)

example of my .xsession:
export ENV=$HOME/.kshrc
export LC_CTYPE="en_US.UTF-8"
urxvtd -q -o -f
~/.fehbg &
redshift &
exec cwm

if logging in via xenodm(1), add export LC_CTYPE="en_US.UTF-8" to your ~/.xsession before starting the window manager. See customizing X for more details.
If logging in via the text console, add export LC_CTYPE="en_US.UTF-8" to your ~/.profile. The text console's UTF-8 support is a work in progress, and some non-ASCII characters may not display properly.

QUESTION: when i did it this way, it did work, urxvt worked, and the utf-8 was set as well, and .kshrc with my custom aliases worked too... but does that basically mean that if i use xenodsm, i should just have all the stuff i normally would put into .profile in .xsessions as well?!?

for example, the default .profile contains: PATH=$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:. export PATH HOME TERM

does that mean i should put this into my .xsessions too? when using xenodm is .profile not used at all then? yet PATH HOME TERM from .profile did somehow get through though when i echo $PATH, echo $HOME, echo $TERM?

if it's not too much trouble could someone help a noob understand how to properly these up for openbsd? (.xsession, .profile, .kshrc)

ALSO, i noticed that when I 'ps -A' to check the processes, there appears to be two instances of urxvtd? why is that? shouldn't there be only 1 urxvtd, and the rest of the terminals as -ksh (since urxvtd is the daemon which i started from .xsession, and urxvtc as the client each time i open a new terminal - which each appear as an instance of -ksh) ?

[jggimi]

It appears this is the best answer:

https://www.reddit.com/r/openbsd/com...ssion/ern5dn3/

[Head_on_a_Stick]

Originally Posted by therue

so, when using xenodm, it bypasses the console so .profile and .xinitrc won't be triggered?

Yes.

Originally Posted by therue

and instead what we normally put into those two should be placed in .xsession instead?

Yes.

Originally Posted by therue

(and to make sure URxvt*loginShell: true is set in .Xdefaults since I'm using urxvt instead of xterm)

I don't think so, ~/.Xdefaults isn't read unless you run xterm or urxvt and by the time you can do that then login has already happened.

But maybe I have misunderstood you here.

Originally Posted by therue

but does that basically mean that if i use xenodsm, i should just have all the stuff i normally would put into .profile in .xsessions as well?!?

for example, the default .profile contains: PATH=$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:. export PATH HOME TERM

does that mean i should put this into my .xsessions too?

You only need to put custom content into ~/.xsession, PATH and a few other variables are set automatically:

https://man.openbsd.org/xenodm#SESSION_PROGRAM

Originally Posted by therue

i noticed that when I 'ps -A' to check the processes, there appears to be two instances of urxvtd? why is that?

Urxvt is setgid and forks itself when run.

From urxvt(7):

I need to make it setuid/setgid to support utmp/ptys on my OS, is this safe?

It should be, starting with release 7.1. You are encouraged to properly install urxvt with
privileges necessary for your OS now.

When rxvt-unicode detects that it runs setuid or setgid, it will fork into a helper process
for privileged operations (pty handling on some systems, utmp/wtmp/lastlog handling on
others) and drop privileges immediately. This is much safer than most other terminals that
keep privileges while running (but is more relevant to urxvt, as it contains things as perl
interpreters, which might be "helpful" to attackers).

This forking is done as the very first within main(), which is very early and reduces
possible bugs to initialisation code run before main(), or things like the dynamic loader of
your system, which should result in very little risk.

To prevent this from happening use

# chmod g-s $(which urxvtd)

You should then only see one urxvtd process.

But you should probably use xterm instead, it has been audited by the OpenBSD devs (and it supports truecolour, unlike urxvt).