Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #177977 > unrolled thread

Whats the alternative to .xinitrc

Back to article view | Back to linux.debian.user

Contents

  Whats the alternative to .xinitrc Bob Brewer <granturav8@gmail.com> - 2017-02-18 19:20 +0100
    Re: Whats the alternative to .xinitrc <tomas@tuxteam.de> - 2017-02-18 21:30 +0100
    Re: Whats the alternative to .xinitrc Brian <ad44@cityscape.co.uk> - 2017-02-18 22:10 +0100
      Re: Whats the alternative to .xinitrc Vincent Lefevre <vincent@vinc17.net> - 2017-02-19 11:10 +0100
        Re: Whats the alternative to .xinitrc Brian <ad44@cityscape.co.uk> - 2017-02-19 21:00 +0100
          Re: Whats the alternative to .xinitrc Vincent Lefevre <vincent@vinc17.net> - 2017-02-20 12:10 +0100
            Re: Whats the alternative to .xinitrc <tomas@tuxteam.de> - 2017-02-20 12:50 +0100
              Re: Whats the alternative to .xinitrc <tomas@tuxteam.de> - 2017-02-20 13:40 +0100
                Re: Whats the alternative to .xinitrc Greg Wooledge <wooledg@eeg.ccf.org> - 2017-02-20 14:40 +0100
                  Re: Whats the alternative to .xinitrc Rob Brewer <ipcop-user@grantura.co.uk> - 2017-02-20 15:10 +0100
                  Re: Whats the alternative to .xinitrc Vincent Lefevre <vincent@vinc17.net> - 2017-02-20 16:20 +0100
                Re: Whats the alternative to .xinitrc Rob Brewer <ipcop-user@grantura.co.uk> - 2017-02-20 14:40 +0100
                  Re: Whats the alternative to .xinitrc <tomas@tuxteam.de> - 2017-02-20 15:00 +0100
              Re: Whats the alternative to .xinitrc Vincent Lefevre <vincent@vinc17.net> - 2017-02-20 13:40 +0100
                Re: Whats the alternative to .xinitrc Greg Wooledge <wooledg@eeg.ccf.org> - 2017-02-20 14:30 +0100
                  Re: Whats the alternative to .xinitrc Vincent Lefevre <vincent@vinc17.net> - 2017-02-20 16:10 +0100
                    Re: Whats the alternative to .xinitrc Greg Wooledge <wooledg@eeg.ccf.org> - 2017-02-20 16:20 +0100
                      Re: Whats the alternative to .xinitrc Vincent Lefevre <vincent@vinc17.net> - 2017-02-20 16:40 +0100
                      Re: Whats the alternative to .xinitrc Vincent Lefevre <vincent@vinc17.net> - 2017-02-20 16:50 +0100

#177977 — Whats the alternative to .xinitrc

I am running up to date KDE Sid with SDDM but I need to start the gnome 
keyring at x startup to satisfy Midori dependencies.

The Midori FAQ suggests adding  “export `gnome-keyring-daemon –start`” to 
the historical .xinitrc but this seems to be ignored as does .xsession as 
suggested by the startx man page.

As .xinitrc has worked OK in the past, how do I now set the user environment 
when X starts?

Rob

[toc] | [next] | [standalone]

#177980

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Feb 18, 2017 at 12:56:54PM +0000, Bob Brewer wrote:
> I am running up to date KDE Sid with SDDM but I need to start the gnome 
> keyring at x startup to satisfy Midori dependencies.
> 
> The Midori FAQ suggests adding  “export `gnome-keyring-daemon –start`” to 
> the historical .xinitrc but this seems to be ignored as does .xsession as 
> suggested by the startx man page.
> 
> As .xinitrc has worked OK in the past, how do I now set the user environment 
> when X starts?

My .xsessionrc is functional. The magic happens in
   /etc/X11/Xsession.d/40x11-common_xsessionrc

 +-----------------------
 | # This file is sourced by Xsession(5), not executed.
 | 
 | #Source user defined xsessionrc (locales and other environment variables)
 | if [ -r "$USERXSESSIONRC" ]; then
 |   . "$USERXSESSIONRC"
 | fi
 +-----------------------

Attention: I'm running SysV init -- perhaps things are different in other
settings.

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliormQACgkQBcgs9XrR2ka3sACfYUICUKHA955wfYf3tfBhSC3M
T7AAnAy8UvS5CQnSVLzOptexKu3zNrn2
=Xlbl
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#177982

On Sat 18 Feb 2017 at 12:56:54 +0000, Bob Brewer wrote:

> I am running up to date KDE Sid with SDDM but I need to start the gnome 
> keyring at x startup to satisfy Midori dependencies.
> 
> The Midori FAQ suggests adding  “export `gnome-keyring-daemon –start`” to 
> the historical .xinitrc but this seems to be ignored as does .xsession as 
> suggested by the startx man page.

The advice in startx(1) is sound but nothing stops you using a ,xinitrc.
The command doesn't work in a ,xinitrc? Perhaps it is incorrect or the
DM ignores it.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#177988

On 2017-02-18 20:59:44 +0000, Brian wrote:
> The advice in startx(1) is sound but nothing stops you using a ,xinitrc.
> The command doesn't work in a ,xinitrc? Perhaps it is incorrect or the
> DM ignores it.

AFAIK, .xinitrc is not used by DM's, in particular because X has
already been started.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#178004

On Sun 19 Feb 2017 at 11:00:25 +0100, Vincent Lefevre wrote:

> On 2017-02-18 20:59:44 +0000, Brian wrote:
> > The advice in startx(1) is sound but nothing stops you using a ,xinitrc.
> > The command doesn't work in a ,xinitrc? Perhaps it is incorrect or the
> > DM ignores it.
> 
> AFAIK, .xinitrc is not used by DM's, in particular because X has
> already been started.

I'd agree with the first statement. I am very unsure about the reason
advanced.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#178016

On 2017-02-19 19:52:24 +0000, Brian wrote:
> On Sun 19 Feb 2017 at 11:00:25 +0100, Vincent Lefevre wrote:
> 
> > On 2017-02-18 20:59:44 +0000, Brian wrote:
> > > The advice in startx(1) is sound but nothing stops you using a ,xinitrc.
> > > The command doesn't work in a ,xinitrc? Perhaps it is incorrect or the
> > > DM ignores it.
> > 
> > AFAIK, .xinitrc is not used by DM's, in particular because X has
> > already been started.
> 
> I'd agree with the first statement. I am very unsure about the reason
> advanced.

Indeed. I think that the reason is that the DM runs /etc/X11/Xsession
(which starts the window manager at the end), so that this would clash
with the .xinitrc file, which could do the same thing (the session
files would be run twice). You can see this in the default system
xinitrc file /etc/X11/xinit/xinitrc, which contains:

. /etc/X11/Xsession

IMHO, the doc related to Xsession (its man page and comments in the
script) is a bit wrong by saying that Xsession is used by xinit/startx.
This is true by default due to the above line, but may not be true if
the user has his own .xinitrc file.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#178017

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Feb 20, 2017 at 12:08:00PM +0100, Vincent Lefevre wrote:
> On 2017-02-19 19:52:24 +0000, Brian wrote:
> > On Sun 19 Feb 2017 at 11:00:25 +0100, Vincent Lefevre wrote:
> > 
> > > On 2017-02-18 20:59:44 +0000, Brian wrote:
> > > > The advice in startx(1) is sound but nothing stops you using a ,xinitrc.
> > > > The command doesn't work in a ,xinitrc? Perhaps it is incorrect or the
> > > > DM ignores it.
> > > 
> > > AFAIK, .xinitrc is not used by DM's, in particular because X has
> > > already been started.
> > 
> > I'd agree with the first statement. I am very unsure about the reason
> > advanced.
> 
> Indeed. I think that the reason is that the DM runs /etc/X11/Xsession
> (which starts the window manager at the end), so that this would clash
> with the .xinitrc file, which could do the same thing (the session
> files would be run twice).

No, no, no. Xsession is invoked by the display manager (DM) as you
said (or by startx). Its job is to... uh... get the session running
(window manager, environment, ssh and/or gpg agent, session dbus
(not on my box ;-) that kind of thing -- it used to "do" desktop
environments last time I looked, but that's a while ago)

So far I agree with you :-)

As part of that, it "typically" (that is configurable!) it looks
whether there is a user session RC (typically -- also configurable!)
called ~/.xsessionrc and *sources* it, as part of the session start
up process. The "sourcing" part is important, otherwise you couldn't
set environment variables which get inherited by all your session's
processes.

See man (5) Xsession and poke a bit through the scripts in
/etc/X11/Xsession.d/, then have a look at /etc/X11/Xsession.options,
then at /etc/X11/Xsession.

Regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliq184ACgkQBcgs9XrR2kZ22wCaAjQMiWHci/BVadoxB+JDzB53
YWAAn3MaFbxOrPXwLN6fnszooo5RJktk
=TEAJ
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#178018

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Feb 20, 2017 at 01:32:37PM +0100, Vincent Lefevre wrote:
> On 2017-02-20 12:49:34 +0100, tomas@tuxteam.de wrote:

[...blah...]

> > See man (5) Xsession and poke a bit through the scripts in
> > /etc/X11/Xsession.d/, then have a look at /etc/X11/Xsession.options,
> > then at /etc/X11/Xsession.
> 
> I don't see any contradiction to what I've said. Note that I haven't
> mentioned .xsessionrc at all, only .xinitrc, which is a different
> thing.

Oops. Too fast reading on my part. Apologies.

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliq4u4ACgkQBcgs9XrR2kY9fwCfapySVIal/mVvtkPIABPgxCFW
1FoAnir/0yWpvWJ4HJlWZxWpx+OuE4VW
=Fnhf
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#178021

On Mon, Feb 20, 2017 at 01:13:09PM +0000, Rob Brewer wrote:
> Thank you for your explanations, I must admit that I didn't expect it to be 
> so involved. I seem to remember mapping out the X startup processes a number 
> of years ago but I was running RedHat then, so I suppose it has changed a 
> lot in the meantime.

Debian's Xsession is not the same as Red Hat's.

If you need a home directory that will work consistently across different
operating systems, then I *strongly* suggest you stick with startx and
make .xinitrc a symlink to .xsession for backwards compatibility.  Any
attempt to reverse engineer and consolidate different display manager +
Xsession combos across multiple operating systems is likely to lead to
mental breakdown.

[toc] | [prev] | [next] | [standalone]

#178024

Greg Wooledge wrote:

> Debian's Xsession is not the same as Red Hat's.
> 
> If you need a home directory that will work consistently across different
> operating systems, then I *strongly* suggest you stick with startx and
> make .xinitrc a symlink to .xsession for backwards compatibility.  Any
> attempt to reverse engineer and consolidate different display manager +
> Xsession combos across multiple operating systems is likely to lead to
> mental breakdown.
> 

I'm a committed Debian user these days so no need for any backwards 
compatibility but Red Hat was the first distro I ran (must be 20 years ago 
now) but I can remember mapping out the startx processes but not the 
details.

Thank you for Xsession WIKI, I wish I had found that a few days ago, it 
would explained all I needed to know. 


Rob

[toc] | [prev] | [next] | [standalone]

#178027

On 2017-02-20 08:34:23 -0500, Greg Wooledge wrote:
> If you need a home directory that will work consistently across different
> operating systems, then I *strongly* suggest you stick with startx and
> make .xinitrc a symlink to .xsession for backwards compatibility.

This what I did in the past, but this means that when startx is
used under Debian, the Xsession settings will not be run. This may
or may not be what the user wants. If you want Xsession settings
under Debian, then having a .xinitrc script that contains:

#!/bin/sh
if [ -r $HOME/.xsession ]; then
  STARTUP=$HOME/.xsession
fi
. /etc/X11/Xsession

may be the solution. I have not tried. There might be other things to
do, but you get the idea. On other systems, a symlink to .xsession may
be OK.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#178022

tomas@tuxteam.de wrote:

> 
> On Mon, Feb 20, 2017 at 01:32:37PM +0100, Vincent Lefevre wrote:
>> On 2017-02-20 12:49:34 +0100, tomas@tuxteam.de wrote:
> 
> [...blah...]
> 
>> > See man (5) Xsession and poke a bit through the scripts in
>> > /etc/X11/Xsession.d/, then have a look at /etc/X11/Xsession.options,
>> > then at /etc/X11/Xsession.
>> 
>> I don't see any contradiction to what I've said. Note that I haven't
>> mentioned .xsessionrc at all, only .xinitrc, which is a different
>> thing.
> 

Thank you for your explanations, I must admit that I didn't expect it to be 
so involved. I seem to remember mapping out the X startup processes a number 
of years ago but I was running RedHat then, so I suppose it has changed a 
lot in the meantime.

Regards

Rob

[toc] | [prev] | [next] | [standalone]

#178023

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Feb 20, 2017 at 01:13:09PM +0000, Rob Brewer wrote:
> tomas@tuxteam.de wrote:
> 
> > 
> > On Mon, Feb 20, 2017 at 01:32:37PM +0100, Vincent Lefevre wrote:
> >> On 2017-02-20 12:49:34 +0100, tomas@tuxteam.de wrote:
> > 
> > [...blah...]
> > 
> >> > See man (5) Xsession and poke a bit through the scripts in
> >> > /etc/X11/Xsession.d/, then have a look at /etc/X11/Xsession.options,
> >> > then at /etc/X11/Xsession.
> >> 
> >> I don't see any contradiction to what I've said. Note that I haven't
> >> mentioned .xsessionrc at all, only .xinitrc, which is a different
> >> thing.
> > 
> 
> Thank you for your explanations, I must admit that I didn't expect it to be 
> so involved. I seem to remember mapping out the X startup processes a number 
> of years ago but I was running RedHat then, so I suppose it has changed a 
> lot in the meantime.

Actually, I find it not to be that involved, once the requirements
are laid out:

 - system wide configuration. If you change this, changes arrive at
   the users *unless* they have overridden something

 - per-user configuration (remember: when this was designed,
   several users were using one machine AT THE SAME TIME! Magic!
   Yikes!  That's something modern DEs seem to forget and re-discover
   from time to time, each time piling one more lay... *PLOP*
   uh, yes, Aunt Tillie. I'll take my meds)

Where was I? Ah, yes. You have some config in /etc (which just
started as one shell script, /etc/X11/Xsession -- note you can
just replace this one and be done).

Then you source from this script whatever snippet the user has
put into its own home dir under .xsession (or .xsessionrc, local
flavours vary).

Then you separate out the config variables which users most probably
want to change into Xsession.options. I guess this is a fairly
"modern" thing.

Then you add (in Debian-typical manner) a subdirectory
/etc/X11/Xsession.d for snippets belonging to different packages
with a stake in the session, to help them not to step on each
other's toes. Of course it makes sense to put the user session
snippet loading here.

This is a design pattern you will find over and over again,
with variations (e.g. no user snippet, etc.).

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAliq9QcACgkQBcgs9XrR2ka7uQCeKny8Brza1+3BF1jRQu710Z4N
5e4AniNoIhBpGxwE9zPwbFXwGzwPCWvp
=66Jb
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#178019

On 2017-02-20 12:49:34 +0100, tomas@tuxteam.de wrote:
> On Mon, Feb 20, 2017 at 12:08:00PM +0100, Vincent Lefevre wrote:
> > On 2017-02-19 19:52:24 +0000, Brian wrote:
> > > On Sun 19 Feb 2017 at 11:00:25 +0100, Vincent Lefevre wrote:
> > > 
> > > > On 2017-02-18 20:59:44 +0000, Brian wrote:
> > > > > The advice in startx(1) is sound but nothing stops you using a ,xinitrc.
> > > > > The command doesn't work in a ,xinitrc? Perhaps it is incorrect or the
> > > > > DM ignores it.
> > > > 
> > > > AFAIK, .xinitrc is not used by DM's, in particular because X has
> > > > already been started.
> > > 
> > > I'd agree with the first statement. I am very unsure about the reason
> > > advanced.
> > 
> > Indeed. I think that the reason is that the DM runs /etc/X11/Xsession
> > (which starts the window manager at the end), so that this would clash
> > with the .xinitrc file, which could do the same thing (the session
> > files would be run twice).
> 
> No, no, no. Xsession is invoked by the display manager (DM) as you
> said (or by startx). Its job is to... uh... get the session running
> (window manager, environment, ssh and/or gpg agent, session dbus
> (not on my box ;-) that kind of thing -- it used to "do" desktop
> environments last time I looked, but that's a while ago)
> 
> So far I agree with you :-)
> 
> As part of that, it "typically" (that is configurable!) it looks
> whether there is a user session RC (typically -- also configurable!)
> called ~/.xsessionrc and *sources* it, as part of the session start
> up process. The "sourcing" part is important, otherwise you couldn't
> set environment variables which get inherited by all your session's
> processes.
> 
> See man (5) Xsession and poke a bit through the scripts in
> /etc/X11/Xsession.d/, then have a look at /etc/X11/Xsession.options,
> then at /etc/X11/Xsession.

I don't see any contradiction to what I've said. Note that I haven't
mentioned .xsessionrc at all, only .xinitrc, which is a different
thing.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#178020

On Mon, Feb 20, 2017 at 01:32:37PM +0100, Vincent Lefevre wrote:
> I don't see any contradiction to what I've said. Note that I haven't
> mentioned .xsessionrc at all, only .xinitrc, which is a different
> thing.

OK, short version: forget .xinitrc ever existed.  Use ~/.xsession unless
that doesn't work.  See https://wiki.debian.org/Xsession

Long version:

You can either log in on a text console and run startx to start X,
or you can login through a GUI display manager.  Of which there are
a whole bunch.

Either way, Debian reads ~/.xsessionrc first.  You should use that to set
variables like PATH in the X environment, since display manager logins
don't read your shell dot files.  Don't use .xsessionrc to start window
managers or desktop environments, though.

If you use startx, then AFTER .xsessionrc, Debian will read the
~/.xsession file.  Use that to start your X client programs and then
to exec your window manager.

If you use a display manager, then .xsession may or may not be used.
Who knows.  There are too many of them to keep track.  You can try it,
and if it works, great.  Otherwise, you'll have to figure out which file
to use for your specific DM or your specific desktop environment or your
specific window manager or who knows what.

The original X display manager, cleverly named xdm, reads .xsession.
But people weren't happy with just having one display manager, so they
made more.  Obviously each "desktop environment" needed its own display
manager.  Why?  Why not!  Everyone likes random change for the sake of
change, don't they?!

Anyway, this is why I use startx and fvwm.  It Just Works(tm).
Consistent operation for two decades.  No bizarre surprises.

[toc] | [prev] | [next] | [standalone]

#178025

On 2017-02-20 08:19:28 -0500, Greg Wooledge wrote:
> OK, short version: forget .xinitrc ever existed.

*And* make sure that you do not have a .xinitrc file, otherwise it
can break things (at least when logging in on a text console).

> Use ~/.xsession unless that doesn't work. See
> https://wiki.debian.org/Xsession
> 
> Long version:
> 
> You can either log in on a text console and run startx to start X,
> or you can login through a GUI display manager.  Of which there are
> a whole bunch.
> 
> Either way, Debian reads ~/.xsessionrc first.  You should use that to set
> variables like PATH in the X environment, since display manager logins
> don't read your shell dot files.  Don't use .xsessionrc to start window
> managers or desktop environments, though.
> 
> If you use startx, then AFTER .xsessionrc, Debian will read the
> ~/.xsession file.  Use that to start your X client programs and then
> to exec your window manager.
> 
> If you use a display manager, then .xsession may or may not be used.
> Who knows.

You can see .xsession as a wrapper to a window manager. Depending on
the current configuration, the DM can either execute a window manager
directly or execute .xsession instead. The choice is done via:

  /etc/X11/Xsession.d/20x11-common_process-args

or

  /etc/X11/Xsession.d/50x11-common_determine-startup

More precisely, if I understand correctly,

1. The DM can request some window manager (for instance, the user has
   the choice between several ones, and he may also choose the default
   session file, or whatever has been used last). If a choice has been
   done, then /etc/X11/Xsession.d/20x11-common_process-args will define
   $STARTUP based on this choice.

2. If there wasn't a specific request, then when
   /etc/X11/Xsession.d/50x11-common_determine-startup is sourced,
   $STARTUP is still empty. In this case, $STARTUP is defined there
   in the following way.

2a. If /etc/X11/Xsession.options contains allow-user-xsession (which
    isn't the default, AFAIK), then $STARTUP is set to the user
    session file, normally "$HOME/.xsession", as /etc/X11/Xsession
    contains: USERXSESSION=$HOME/.xsession
    The window manager should be started from this script.

2b. Otherwise, the following executables are tried in succession:
      /usr/bin/x-session-manager
      /usr/bin/x-window-manager
      /usr/bin/x-terminal-emulator

Other configuration files from /etc/X11/Xsession.d may modify $STARTUP.
For instance, with gtk3-nocsd installed,
/etc/X11/Xsession.d/70gtk3-nocsd-propagate-LD_PRELOAD does:

  STARTUP="env LD_PRELOAD=$LD_PRELOAD $STARTUP"

Finally, /etc/X11/Xsession.d/99x11-common_start does:

exec $STARTUP

Note: since window managers can also start X clients on start up,
a .xsession file may not be useful for everyone.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#178026

On Mon, Feb 20, 2017 at 04:02:50PM +0100, Vincent Lefevre wrote:
> More precisely, if I understand correctly,
> 
> 1. The DM can request some window manager (for instance, the user has
>    the choice between several ones, and he may also choose the default
>    session file, or whatever has been used last). If a choice has been
>    done, then /etc/X11/Xsession.d/20x11-common_process-args will define
>    $STARTUP based on this choice.
> 
> 2. If there wasn't a specific request, then when
>    /etc/X11/Xsession.d/50x11-common_determine-startup is sourced,
>    $STARTUP is still empty. In this case, $STARTUP is defined there
>    in the following way.
> 
> 2a. If /etc/X11/Xsession.options contains allow-user-xsession (which
>     isn't the default, AFAIK), then $STARTUP is set to the user
>     session file, normally "$HOME/.xsession", as /etc/X11/Xsession
>     contains: USERXSESSION=$HOME/.xsession
>     The window manager should be started from this script.
> 
> 2b. Otherwise, the following executables are tried in succession:
>       /usr/bin/x-session-manager
>       /usr/bin/x-window-manager
>       /usr/bin/x-terminal-emulator

I believe this is what I documented on https://wiki.debian.org/Xsession
If the wiki doesn't reflect your understanding of the scripts, then it's
possible that one of misread them, and we can work on getting the wiki
into a more accurate (or more clear) state.

I also used the Debian reference manual, linked from that page, and
"man Xsession", while trying to figure out how this stuff works.  I did
not go through the extra steps of installing and removing various display
managers and desktop environments in order to reverse engineer them.
My dedication to this cause has limitations.

> Note: since window managers can also start X clients on start up,
> a .xsession file may not be useful for everyone.

It's a crazy mixed-up world.

[toc] | [prev] | [next] | [standalone]

#178028

On 2017-02-20 10:15:16 -0500, Greg Wooledge wrote:
> On Mon, Feb 20, 2017 at 04:02:50PM +0100, Vincent Lefevre wrote:
> > More precisely, if I understand correctly,
> > 
> > 1. The DM can request some window manager (for instance, the user has
> >    the choice between several ones, and he may also choose the default
> >    session file, or whatever has been used last). If a choice has been
> >    done, then /etc/X11/Xsession.d/20x11-common_process-args will define
> >    $STARTUP based on this choice.
> > 
> > 2. If there wasn't a specific request, then when
> >    /etc/X11/Xsession.d/50x11-common_determine-startup is sourced,
> >    $STARTUP is still empty. In this case, $STARTUP is defined there
> >    in the following way.
> > 
> > 2a. If /etc/X11/Xsession.options contains allow-user-xsession (which
> >     isn't the default, AFAIK),

Actually it is the default (I got confused with something else).

> >     then $STARTUP is set to the user
> >     session file, normally "$HOME/.xsession", as /etc/X11/Xsession
> >     contains: USERXSESSION=$HOME/.xsession
> >     The window manager should be started from this script.
> > 
> > 2b. Otherwise, the following executables are tried in succession:
> >       /usr/bin/x-session-manager
> >       /usr/bin/x-window-manager
> >       /usr/bin/x-terminal-emulator
> 
> I believe this is what I documented on https://wiki.debian.org/Xsession

I hadn't read https://wiki.debian.org/Xsession when I wrote that, but
I think that this document is a bit wrong (or incomplete). It says:

  If a specific session was selected in gdm3, run it.

but this doesn't seem to be specific to gdm3 or any other DM.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#178029

On 2017-02-20 10:15:16 -0500, Greg Wooledge wrote:
> On Mon, Feb 20, 2017 at 04:02:50PM +0100, Vincent Lefevre wrote:
> > Note: since window managers can also start X clients on start up,
> > a .xsession file may not be useful for everyone.
> 
> It's a crazy mixed-up world.

I'd say that it's better to start X clients from the window manager's
startup file because the window manager may have rules to place
windows and things like that. If an X client is started from the
.xsession file, the WM won't have a chance to see it early enough
(there may also be race conditions so that the behavior may not be
reproducible).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web