Failed to execute child process (no such file or directory), but the script DOES exist in $HOME/bin, openbox users, especially take a look, please.

[Tony Baldwin]

Greetings, friends,

I have various scripts in $HOME/bin, many of which I have put in my
.config/openbox/rc.xml so I can fire them off with a keybinding combo, like
<keybind key="W-b">
<action name="Execute">
<startupnotify>
<enabled>true</enabled>
<name>bid</name>
</startupnotify>
<command>bid</command>
</action>
</keybind>


(This particular one does cat ~/Documents/bid | xclip -selection c)
bid.txt being a template letter for bidding on translation projects.
I use this to quickly copy the file and then paste it into an e-mail,
then do any relevant edits.
I'my lazy and like to automate things as much as possible where I can
slap a few keys (Alt-m brings up icedove, Ctrl N to compose a new
message, then W-b/Ctrl-v to copy and paste my bid template),
These things used to work perfectly in Wheezy, and even in a previous
Jessie installation, but working in a new Jessie installation,
when I press W-b, and some others I get this:
Failed to execute child process (no such file or directory)
But the script IS in ~/bin/
$ which bid
/home/tony/bin/bid
and that dir IS in my $PATH:
$ echo $PATH
/home/tony/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
and it IS executable:
$ ls -la bin/ | grep bid
-rwxr-xr-x 1 tony tony 142 Oct 4 2012 bid
I can execute these scripts from a terminal without any problem but not
via the shortcuts in my rc.xml, nor with grun (shortcut W-r brings that
up fine), nor with dmenu (W-p also working fine)
, and other stuff
Shortuts for stuff in /bin/ or /usr/bin/ (such as for icedove and
iceweasel) seem to work fine, I can lock my screen (W-x engages slock);
it's just my own scripts and stuff in ~/bin that are giving me trouble..

Why?

tia,
tony



--
http://tonybaldwin.me
all tony, all the time

[Thomas Schmitt]

Hi,

Tony Baldwin wrote:
> .config/openbox/rc.xml
> <command>bid</command>

Well, a short while ago with cron it helped to tell the clueless
software where the script is by an absolute path.
Probably:

<command>/home/tony/bin/bid</command>

> Shortuts for stuff in /bin/ or /usr/bin/ [...] seem to work fine

What user started the software ? And when ?
Was PATH already set to the value you are seeing in the shell ?


Have a nice day :)

Thomas

[Greg Wooledge]

On Wed, Sep 21, 2016 at 09:43:15AM -0400, Tony Baldwin wrote:
> I have various scripts in $HOME/bin, many of which I have put in my
> .config/openbox/rc.xml so I can fire them off with a keybinding combo, like

How do you login? With a display manager? Which one?

> when I press W-b, and some others I get this:
> Failed to execute child process (no such file or directory)

And you believe it's because of a PATH mismatch. OK. I don't have
experience with whichever desktop or window manager this is.

> But the script IS in ~/bin/
> $ which bid
> /home/tony/bin/bid
> and that dir IS in my $PATH:
> $ echo $PATH
> /home/tony/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Now here's the real issue: this is the PATH variable of some interactive
shell. But your window manager (or whatever is reacting to your key
events) may have a *different* PATH.

For example, it is possible that your wm has some PATH determined by
the files that are read upon login, and then you launch a terminal
from your wm, and the terminal launches a shell, and the shell reads
~/.bashrc or whatever, and ~/.bashrc changes the PATH of the shell
so that your commands work.

But the poor wm is still stuck with the PATH that it got when you logged
in, which presumably does not read ~/.bashrc or any other shell dot files.

That's why you have to understand whichever login method you use, and
how to configure it.

I have a dream that one day, Debian developers will wake the hell up
and document these things. (I've been too lazy so far to dedicate a
few hours/days to installing and removing display managers and desktop
environments in order to reverse engineer each combination and try to
figure out what dot files they use. But the thought has crossed my
mind. That's how blightedly BAD the situation is.)

[Darac Marjal]

On Wed, Sep 21, 2016 at 09:43:15AM -0400, Tony Baldwin wrote:

Does the file start with a valid "shebang" line? When you tell some
program to run a file "foo", typically what happens is that the program
invokes a standard call (Actually, I'm not sure if this behaviour is in
the kernel or in libc, either way, it's a "system function") that says
"execute this file". Now, if the file is actually executable (e.g.
something that you compiled), then you should be good to go, but if it's
a script file, then... well the processor doesn't know how to interpret
"echo Hello world".

However, if the first two characters of the file are "#!"
(Pound/octothorpe/hash followed by exclamation-mark/bang... Hash-Bang...
haSH-BANG... shebang), then the system identifies this file as a script.
The remainder of that line (i.e. everything between the bang and the
newline) is taken to be the actual command line to be run. So, that
command is run instead and your script is passed to it on stdin.

So in summary, a script should start with something like:

#!/bin/sh

echo hello world

It should follow, though, that you don't HAVE to add the shebang line IF
you call a proper executable and pass it the name of your script. That
is:

$ ~/bin/bid # Needs a shebang
$ /bin/sh ~/bin/bid # Doesn't need a shebang, but it won't hurt

Also, a few final things to be aware of:

* Not all programs expand ~
* ~ will expand to the home directory of the calling user (so watch out
in cron jobs)
* Not all programs bother to search the PATH

So, if you're asking a program other than a full shell to execute
something for you, it's best to give an absolute path.

>
>tia,
>tony
>
>
>
>--
>http://tonybaldwin.me
>all tony, all the time
>

--
For more information, please reread.

[Tony Baldwin]

On 09/21/2016 10:01 AM, Greg Wooledge wrote:
> On Wed, Sep 21, 2016 at 09:43:15AM -0400, Tony Baldwin wrote:
>> I have various scripts in $HOME/bin, many of which I have put in my
>> .config/openbox/rc.xml so I can fire them off with a keybinding combo, like
> How do you login? With a display manager? Which one?

it seems that I am using lightdm.

>
>> when I press W-b, and some others I get this:
>> Failed to execute child process (no such file or directory)
> And you believe it's because of a PATH mismatch. OK. I don't have
> experience with whichever desktop or window manager this is.

This is why my subject included a call-out to openbox users
(not that I don't appreciate others trying to help).

>
>> But the script IS in ~/bin/
>> $ which bid
>> /home/tony/bin/bid
>> and that dir IS in my $PATH:
>> $ echo $PATH
>> /home/tony/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> Now here's the real issue: this is the PATH variable of some interactive
> shell. But your window manager (or whatever is reacting to your key
> events) may have a *different* PATH.

That suddenly occurred to me, that my shell is using the path set in the
.bashrc, but openbox may not; but these things used to work fine, so I
can't figure out what changed to make it any different now.

>
> For example, it is possible that your wm has some PATH determined by
> the files that are read upon login, and then you launch a terminal
> from your wm, and the terminal launches a shell, and the shell reads
> ~/.bashrc or whatever, and ~/.bashrc changes the PATH of the shell
> so that your commands work.
>
> But the poor wm is still stuck with the PATH that it got when you logged
> in, which presumably does not read ~/.bashrc or any other shell dot files.
>
> That's why you have to understand whichever login method you use, and
> how to configure it.
>
> I have a dream that one day, Debian developers will wake the hell up
> and document these things. (I've been too lazy so far to dedicate a
> few hours/days to installing and removing display managers and desktop
> environments in order to reverse engineer each combination and try to
> figure out what dot files they use. But the thought has crossed my
> mind. That's how blightedly BAD the situation is.)

[Greg Wooledge]

On Wed, Sep 21, 2016 at 10:49:13AM -0400, Tony Baldwin wrote:
> it seems that I am using lightdm.

I know of absolutely no documentation for configuring lightdm as a
user. I suspect that the software *has* no user configuration at all,
because every search I've ever done has come up with nothing.

(For example, https://wiki.debian.org/LightDM has zero instances of
"home" or "~" or "dot".)

So then we enter the murky waters of "what happens after lightdm".
Here I can only find hints and conjectures and anecdotes.

https://lists.debian.org/debian-user/2014/10/msg02242.html
https://lists.debian.org/debian-user/2013/12/msg00775.html
https://faq.i3wm.org/question/2483/howto-debian-wheezy-lightdm-i3.1.html
...

[Thomas Schmitt]

Hi,

Anthony Baldwin wrote:
> giving the full path in the rc.xml doesn't seem to make
> any difference.

Are you sure openbox is aware of the change ?
(Did you restart it ? Does it react immediately on newly added
key combinations ?)


> Yes, the $PATH is set in my .bashrc...
> Wait.. Is this why I can start them in a terminal, but openbox can't?

Possibly.

It depends on when and by what entity the openbox window manager was
started and whether it uses PATH to find commands.
If the starter was some kind of shell, then it probably has forwarded
its own PATH variable to openbox. If it was something more fancy, then
behavior depends on the mood of its developers.

You could put a script into /usr/bin (where it will be found, i hope),
let it print the PATH to a file, bind it to a key combination, and
look what it writes into the file:
#!/bin/sh
echo "$PATH" >/tmp/my_openbox_test_for_PATH

But if PATH was to blame, then an absolute program path should have
helped. If it came into effect, that is.

[Anthony Baldwin]

Sorry that you're getting this twice again, Thomas,
but I keep flummoxing the list-reply function (old age + brain tumor).

Tony

On 09/21/2016 09:54 AM, Thomas Schmitt wrote:
> Hi,
>
> Tony Baldwin wrote:
>> .config/openbox/rc.xml
>> <command>bid</command>
>
> Well, a short while ago with cron it helped to tell the clueless
> software where the script is by an absolute path.
> Probably:
>
> <command>/home/tony/bin/bid</command>

I just tried, and giving the full path in the rc.xml doesn't seem to
make any difference.
>

>> Shortuts for stuff in /bin/ or /usr/bin/ [...] seem to work fine
>
> What user started the software ? And when ?

I'm the only user on this system.
Does when really matter?
Every time/any time I get these errors now.

> Was PATH already set to the value you are seeing in the shell ?

Yes, the $PATH is set in my .bashrc...
Wait.. Is this why I can start them in a terminal, but openbox can't?

Because the path is being set in my .bashrc, and, thus, only for shells
I open?
When I switch to su, echo $PATH, of course, gives a different response
(includes /sbin/ stuff, but not $HOME anything),
If this is the problem, how to I get my $HOME/bin permanently in the
path so openbox can run stuff from there, too?

>
>
> Have a nice day :)
>
> Thomas
>

--
http://www.baldwinlinguas.com
translations, localization,
multilingual web development
EN, ES, FR, PT

--
http://www.baldwinlinguas.com
translations, localization,
multilingual web development
EN, ES, FR, PT

[Greg Wooledge]

On Wed, Sep 21, 2016 at 05:20:31PM +0200, Thomas Schmitt wrote:
> You could put a script into /usr/bin (where it will be found, i hope),
> let it print the PATH to a file, bind it to a key combination, and
> look what it writes into the file:
> #!/bin/sh
> echo "$PATH" >/tmp/my_openbox_test_for_PATH

Or you can use ps eww -p "$(pgrep openbox)" (or directly substitute
the PID you want in case that command substitution is wrong; it works
for me with fvwm). The PATH should be visible in the process's
environment as displayed by ps. There may be a lot of noise to filter
out, of course.

[Anthony Baldwin]

On 09/21/2016 11:20 AM, Thomas Schmitt wrote:
> Hi,
>
> Anthony Baldwin wrote:
>> giving the full path in the rc.xml doesn't seem to make
>> any difference.
>
> Are you sure openbox is aware of the change ?
> (Did you restart it ? Does it react immediately on newly added
> key combinations ?)

Normally, yes, OBx would, indeed reload, the configurations in its
rc.xml file upon a --restart and immediately implement any changes.

>
>
>> Yes, the $PATH is set in my .bashrc...
>> Wait.. Is this why I can start them in a terminal, but openbox can't?
>
> Possibly.
>
> It depends on when and by what entity the openbox window manager was
> started and whether it uses PATH to find commands.
> If the starter was some kind of shell, then it probably has forwarded
> its own PATH variable to openbox. If it was something more fancy, then
> behavior depends on the mood of its developers.
>
> You could put a script into /usr/bin (where it will be found, i hope),
> let it print the PATH to a file, bind it to a key combination, and
> look what it writes into the file:
> #!/bin/sh
> echo "$PATH" >/tmp/my_openbox_test_for_PATH
>
> But if PATH was to blame, then an absolute program path should have
> helped. If it came into effect, that is.

So it's not likely a path problem it seems..

Thanks,
Tony

>
>
> Have a nice day :)
>
> Thomas
>

[Anthony Baldwin]

On 09/21/2016 11:05 AM, Greg Wooledge wrote:
> On Wed, Sep 21, 2016 at 10:49:13AM -0400, Tony Baldwin wrote:
>> it seems that I am using lightdm.
>
> I know of absolutely no documentation for configuring lightdm as a
> user. I suspect that the software *has* no user configuration at all,
> because every search I've ever done has come up with nothing.
>
> (For example, https://wiki.debian.org/LightDM has zero instances of
> "home" or "~" or "dot".)

Oddly this page states, with it's bare face hanging out:
[lightdm] was built as a relatively light-weight and *highly
customizable* alternative to GDM.

./tony

>
> So then we enter the murky waters of "what happens after lightdm".
> Here I can only find hints and conjectures and anecdotes.
>
> https://lists.debian.org/debian-user/2014/10/msg02242.html
> https://lists.debian.org/debian-user/2013/12/msg00775.html
> https://faq.i3wm.org/question/2483/howto-debian-wheezy-lightdm-i3.1.html
> ...
>

[David Wright]

On Wed 21 Sep 2016 at 15:07:09 (-0400), Anthony Baldwin wrote:
> On 09/21/2016 11:05 AM, Greg Wooledge wrote:
> >On Wed, Sep 21, 2016 at 10:49:13AM -0400, Tony Baldwin wrote:
> >>it seems that I am using lightdm.
> >
> >I know of absolutely no documentation for configuring lightdm as a
> >user. I suspect that the software *has* no user configuration at all,
> >because every search I've ever done has come up with nothing.
> >
> >(For example, https://wiki.debian.org/LightDM has zero instances of
> >"home" or "~" or "dot".)

I'm not a DE or DM user, so I'm know very little about them. But I
don't understand the concept of "user configuration" for a DM.
Wouldn't that be like a user configuring /etc/issue, the login prompt
or /etc/motd ?

> Oddly this page states, with it's bare face hanging out:
> [lightdm] was built as a relatively light-weight and *highly
> customizable* alternative to GDM.

Is this what is being described at
https://www.freedesktop.org/wiki/Software/LightDM/CommonConfiguration/
?
Is that the sort of configuration you would expect, or would you
want something different? Are you perhaps talking about which file,
like .xsession, .xsessionrc, .Xsession, .xinitrc, etc gets executed
when you login through the DM?

Cheers,
David.

[Greg Wooledge]

On Wed, Sep 21, 2016 at 09:19:11PM -0500, David Wright wrote:
> But I don't understand the concept of "user configuration" for a DM.
> Wouldn't that be like a user configuring /etc/issue, the login prompt
> or /etc/motd ?

By user configuration, I mean "which files can the user edit, without
superuser privileges, to alter the behavior of the program".

> Are you perhaps talking about which file,
> like .xsession, .xsessionrc, .Xsession, .xinitrc, etc gets executed
> when you login through the DM?

Yes, precisely this question. What can an end user, who uses one of
the various display managers and desktop environments in Debian, do
to configure their own environment? Hell, just start with the $PATH
variable. That's what 90% of the people asking this question want to
modify -- well, that or some other environment variable with the word
PATH or HOME in it, like JAVA_HOME.

Why is it *so impossible* to find out how to set an environment variable?

Everything is so much simpler when you don't use a display manager.
You login on the console (getty + login), which sets some variables,
all of them well documented in man pages, and then executes your shell as
defined in passwd(5) with a leading '-' to mean "this is a login shell".
Then, the behavior of the shell when argv[0] begins with '-' is well
documented in the shell's man page. Everyone knows how it works, and
everyone knows how to change its behavior. I can describe *every single
process* in the chain, and I know what *every one* of them does and which
files it reads; or if I don't have every configuration file memorized,
then at least I know which document I can read to find the list of them.

With lightdm (for example), nobody knows how to change its behavior,
or even how to *understand* its behavior. There's no starting point in
any piece of documentation that tells you what's happening, or how and
where you can intervene in the chain of events.

What's worse is none of the experts who are typically able to answer
questions about this kind of thing knows how to answer. We don't *use*
these things! And where we would normally be able to crack open a
man page to find the answer, there are no answers! When we do Google
searches, there are *still* no answers! This creates a gap between the
expert users and the novice users, and it's getting worse every year.

At this point, when a user running *dm and *DE asks some question about
their login environment, they might as well be running Microsoft Windows
for all the help I can give them. All I can do is sit there and watch,
hoping that some day, *someone else* will come along with a magic starting
point from which answers can be determined. It hasn't happened yet.

> I'm not a DE or DM user, so I'm know very little about them.

Yes, THIS is the problem! You, and I, and everyone else on the guru side
are just completely stumped.

When the answer to "how do I run a thing at login" changes from "put
foobar& in your .xsession shell script before the exec wm" to "somewhere in
your home directory is a whole new kind of file with a .desktop extension
which isn't a shell script but a totally new thing that you have to
learn from scratch..." the immediate response is "to hell with that,
I'm going back to startx + fvwm". So we stick with the old, simple
things that work and are understandable and don't take up 700 MB of
disk space, and nobody with a *brain* learns the new stuff.

When the answer to "how do I set an environment variable at login" changes
from "put export FOO=bar in your .bash_profile" to "uh... well... there's
nothing in man lightdm, so let's check google... oh, no, I... just don't
see how to do it" then something is completely *broken*.

Don't believe me? I know none of us has lightdm installed, so here is
a man page, allegedly from Debian wheezy:

http://www.unix.com/man-page/debian/1/lightdm/

It takes several tries for me even to find *that*, probably because the
manual is so ashamed of itself that it runs and hides when the Google
crawler approaches. Behold this glorious tome of wisdom:

NAME
lightdm - a display manager

SYNOPSIS
lightdm [ OPTION ]

DESCRIPTION
lightdm is a display manager.

That's it! That is the *entire documentation*, apart from a list of
options (none of which can be modified by an end user, of course),
and then a list of three configuration files:

FILES
/etc/lightdm/lightdm.conf
Configuration

/etc/lightdm/users.conf
User list configuration (if not using Accounts Service)

/etc/lightdm/keys.conf
XDMCP keys

This is what we're dealing with. "lightdm is a display manager."
What does that MEAN? What does it DO? People type their passwords into
this thing, and *this* is its official user manual? Is this a *joke*?
What happens AFTER you type your username and password? What files does
it read AFTER the password, not before! Who CARES what it does before!
What PROCESSES does it execute? When does it switch effective UID from
root to user?

[to...@tuxteam.de]

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

On Thu, Sep 22, 2016 at 09:11:53AM -0400, Greg Wooledge wrote:

[...]

To be fair, the display manager just hands the ball to the X session
management (which makes sense, because then you can keep your session
setup when changing the DM and remember: in the good ol' times DM
and X proper didn't have to run on the same box). Here's one of those
typical Xsession files (I hacked it to give me, as a user, the power
to configure my environment):

tomas@rasputin:~$ cat /etc/X11/Xsession.d/80x11xmodmap
# 2015-01-10 tomas: why did they steal my xmodmap?
# Snarfed from <http://forums.debian.net/viewtopic.php?t=77008>

# This file is sourced by Xsession(5), not executed.

SYSMODMAP="/etc/X11/Xmodmap"
USRMODMAP="$HOME/.Xmodmap"

if [ -x /usr/bin/X11/xmodmap ]; then
if [ -f "$SYSMODMAP" ]; then
xmodmap "$SYSMODMAP"
fi

if [ -f "$USRMODMAP" ]; then
xmodmap "$USRMODMAP"
fi
fi

That's the typical way such things are set up. Then I, as user can edit
my ~/.Xmodmap. Similar things can be done for the environment, for the
SSH agent, and so on.

I'm pretty sure that those things still work with more modern desktop
environments (though I'm happy I haven't to cope with them).

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

iEYEARECAAYFAlfj3GEACgkQBcgs9XrR2kZlVgCaArjxZyRl8lB9bha4lhoRWtR/
R4EAn39XVsJVDMA3isWA8vZmVz219sRK
=W/Cx
-----END PGP SIGNATURE-----

[Brian]

On Thu 22 Sep 2016 at 09:11:53 -0400, Greg Wooledge wrote:

> Don't believe me? I know none of us has lightdm installed, so here is
> a man page, allegedly from Debian wheezy:
>
> http://www.unix.com/man-page/debian/1/lightdm/
>
> It takes several tries for me even to find *that*, probably because the
> manual is so ashamed of itself that it runs and hides when the Google
> crawler approaches. Behold this glorious tome of wisdom:

To read the manual

apt-get download lightdm

works every time.

Online there is the useful

https://manpages.debian.org/

Except it isn't working at the moment.

[Greg Wooledge]

On Thu, Sep 22, 2016 at 02:50:30PM +0100, Brian wrote:
> To read the manual
>
> apt-get download lightdm
>
> works every time.

Hmm, well.

$ cd /tmp
$ apt-get download lightdm
$ ls, man dpkg, ...
$ dpkg -x lightdm_1.10.3-3_amd64.deb ldm
$ gzip -dc ldm/usr/share/man/man1/lightdm.1.gz | nroff -man | less

Turns out there is a whole new section in the man page since wheezy!

SEE ALSO
dm-tool(1)

That is the only addition.

$ man dm-tool
No manual entry for dm-tool

Yes, I could do a bunch of crap to try to figure out which package
contains that manual page, extract it, etc. But it doesn't seem like
a useful investment of time, as I would not expect it to describe how
a DM works, or what happens after it has accepted and verified a password.

[Tixy]

On Thu, 2016-09-22 at 09:11 -0400, Greg Wooledge wrote:
> On Wed, Sep 21, 2016 at 09:19:11PM -0500, David Wright wrote:
> > But I don't understand the concept of "user configuration" for a DM.
> > Wouldn't that be like a user configuring /etc/issue, the login
> prompt
> > or /etc/motd ?
>
> By user configuration, I mean "which files can the user edit, without
> superuser privileges, to alter the behavior of the program".
>
> > Are you perhaps talking about which file,
> > like .xsession, .xsessionrc, .Xsession, .xinitrc, etc gets executed
> > when you login through the DM?
>
> Yes, precisely this question. What can an end user, who uses one of
> the various display managers and desktop environments in Debian, do
> to configure their own environment?

I edit ~/.xsessionrc to have a single line:

. /home/tixy/.profile

Which makes X sessions include the same profile as standard login
shells.

And my .profile has (or I added?)

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi

--
Tixy

[Brian]

On Thu 22 Sep 2016 at 09:59:07 -0400, Greg Wooledge wrote:

> On Thu, Sep 22, 2016 at 02:50:30PM +0100, Brian wrote:
> > To read the manual
> >
> > apt-get download lightdm
> >
> > works every time.
>
> Hmm, well.

Worked, didn't it? A two second operation.

> $ cd /tmp
> $ apt-get download lightdm
> $ ls, man dpkg, ...
> $ dpkg -x lightdm_1.10.3-3_amd64.deb ldm
> $ gzip -dc ldm/usr/share/man/man1/lightdm.1.gz | nroff -man | less

mc does pretty well in opening the .deb and getting to the man page.
Another two seconds.

> Turns out there is a whole new section in the man page since wheezy!
>
> SEE ALSO
> dm-tool(1)
>
> That is the only addition.
>
> $ man dm-tool
> No manual entry for dm-tool

Software improves; that is why we use Debian. Try testing/unstable.

NAME
dm-tool - a tool to control the display manager
SYNOPSIS
dm-tool [ OPTIONS ] COMMAND [ ARGS ]
DESCRIPTION
dm-tool is a tool to communicate with the LightDM display manager.

> Yes, I could do a bunch of crap to try to figure out which package
> contains that manual page, extract it, etc. But it doesn't seem like
> a useful investment of time, as I would not expect it to describe how
> a DM works, or what happens after it has accepted and verified a password.

"Search the contents of packages" at

https://www.debian.org/distrib/packages

A ten second investment of your time.

[Greg Wooledge]

On Thu, Sep 22, 2016 at 03:15:40PM +0100, Tixy wrote:
> I edit ~/.xsessionrc to have a single line:
>
> . /home/tixy/.profile

Which program reads ~/.xsessionrc and how did you learn about it?
Which man page describes it? Does its existence merely "add on" to some
system-wide default script, or does it fully replace a system-wide script?

> Which makes X sessions include the same profile as standard login
> shells.

Bash's initialization is a bit more complex than that. It will look
for three different files (.bash_profile or .bash_login or .profile),
in that order, and uses the first one it finds. I'd imagine zsh does
something similar, though I don't use zsh. For pure POSIX sh or ksh,
you would be correct.

[Darac Marjal]

On Thu, Sep 22, 2016 at 10:56:49AM -0400, Greg Wooledge wrote:
>On Thu, Sep 22, 2016 at 03:15:40PM +0100, Tixy wrote:
>> I edit ~/.xsessionrc to have a single line:
>>
>> . /home/tixy/.profile
>
>Which program reads ~/.xsessionrc and how did you learn about it?
>Which man page describes it? Does its existence merely "add on" to some
>system-wide default script, or does it fully replace a system-wide script?

Apparently, this is the "New Method" as detailed in the Debian Reference
Manual:
https://www.debian.org/doc/manuals/debian-reference/ch07.en.html#_customizing_the_x_session_new_method

>
>> Which makes X sessions include the same profile as standard login
>> shells.
>
>Bash's initialization is a bit more complex than that. It will look
>for three different files (.bash_profile or .bash_login or .profile),
>in that order, and uses the first one it finds. I'd imagine zsh does
>something similar, though I don't use zsh. For pure POSIX sh or ksh,
>you would be correct.
>

[Tony Baldwin]

Thank you, Tixy,

This worked perfectly.
I created the .xsessionrc file (didn't previously have one),
and found that my .proile already had the needed part in it (possibly
because I'd already added the same to my .bashrc ?)
Logged out and back in, and now my keybinding are working to fire off my
scripts. such as this one, which I fire off qwith the print screen key:

#!/bin/bash

filedate=$(date +%m%d%y%H%M%S)

cd /home/tony/pix/screenshots

scrot $filedate.jpg

gthumb $filedate.jpg

exit

just snapped this: http://tonybaldwin.me/images/092216112353.jpg

Tony

[Brian]

On Thu 22 Sep 2016 at 10:56:49 -0400, Greg Wooledge wrote:

> On Thu, Sep 22, 2016 at 03:15:40PM +0100, Tixy wrote:
> > I edit ~/.xsessionrc to have a single line:
> >
> > . /home/tixy/.profile
>
> Which program reads ~/.xsessionrc

X.

> and how did you learn about it?

Don't know about Tixy but the knowledge came to me in a dream.

> Which man page describes it?

Xsession(5).

> Does its existence merely "add on" to some
> system-wide default script, or does it fully replace a system-wide script?

Neither. Please see /etc/X11/Xsession.d/40x11-common_xsessionrc.

--
Brian.

[Seeker]

A little late, but personally I would have tried using '~/.xprofile'
first.

I believe the information about this from the Arch Wiki applies equally
to Debian.

https://wiki.archlinux.org/index.php/xprofile

Later, Seeker

[Greg Wooledge]

On Thu, Sep 22, 2016 at 09:00:11AM -0700, Seeker wrote:
> A little late, but personally I would have tried using '~/.xprofile'
> first.
>
> I believe the information about this from the Arch Wiki applies equally
> to Debian.
>
> https://wiki.archlinux.org/index.php/xprofile

wooledg@wooledg:~$ grep -r xprofile /etc/X11
wooledg@wooledg:~$

Apparently Debian's "X session" is heavily customized, as described in
https://www.debian.org/doc/manuals/debian-reference/ch07.en.html#_starting_the_x_window_system

Arch's customizations are different and don't appear to be the same
as Debian's.

What I was missing was a simple pointer from lightdm's joke of a man page
to either Xsession(5), with some indication that lightdm *runs* a Debian
X session, or directly to the debian-reference web page.

At some point I may take a stab at fixing up the wiki page(s) now that
we have some actual, useful information. (I should also point out that
my Google searches for "debian man lightdm" etc. tended to favor the
Debian wiki page, which at this precise moment is just about as useless
as the lightdm man page is.)

[Seeker]

On 9/21/2016 12:07 PM, Anthony Baldwin wrote:
> On 09/21/2016 11:05 AM, Greg Wooledge wrote:
>> On Wed, Sep 21, 2016 at 10:49:13AM -0400, Tony Baldwin wrote:
>>> it seems that I am using lightdm.
>>
>> I know of absolutely no documentation for configuring lightdm as a
>> user. I suspect that the software *has* no user configuration at all,
>> because every search I've ever done has come up with nothing.
>>
>> (For example, https://wiki.debian.org/LightDM has zero instances of
>> "home" or "~" or "dot".)
>
> Oddly this page states, with it's bare face hanging out:
> [lightdm] was built as a relatively light-weight and *highly
> customizable* alternative to GDM.
>

Highly customizable is not the same as highly configurable.

3 greeters that customize the lightdm login screen lightdm-gtk-greeter,
lightdm-kde-greeter, razorqt-lightdm-greeter.

https://packages.debian.org/search?keywords=lightdm+greeter&searchon=names&suite=stable&section=all

Later Seeker

[Ric Moore]

Suppose all you get is a black screen and a mouse pointer?? <howls> Ric


--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html

[Brian]

On Thu 22 Sep 2016 at 16:10:01 +0100, Darac Marjal wrote:

> On Thu, Sep 22, 2016 at 10:56:49AM -0400, Greg Wooledge wrote:
> >On Thu, Sep 22, 2016 at 03:15:40PM +0100, Tixy wrote:
> >>I edit ~/.xsessionrc to have a single line:
> >>
> >> . /home/tixy/.profile
> >
> >Which program reads ~/.xsessionrc and how did you learn about it?
> >Which man page describes it? Does its existence merely "add on" to some
> >system-wide default script, or does it fully replace a system-wide script?
>
> Apparently, this is the "New Method" as detailed in the Debian Reference
> Manual: https://www.debian.org/doc/manuals/debian-reference/ch07.en.html#_customizing_the_x_session_new_method

"Customizing the X session (new method)" should be seen as describing
additional customisation features rather than a hint to do without
~/.xsession. The intention of ~/.xsessionrc is to source environment
variables but it can be (ab)used for other purposes.

For example, it could start a terminal:

gnome-terminal &

The advantage over ~/.xsession is that the window manager or desktop
session would be started from the alternatives system whereas
~/.xsession also has to start a window manager or desktop session. You
would have to have

gnome-terminal &
exec gnome-session

--
Brian.

[Brian]

On Thu 22 Sep 2016 at 12:10:35 -0400, Greg Wooledge wrote:

> On Thu, Sep 22, 2016 at 09:00:11AM -0700, Seeker wrote:
> > A little late, but personally I would have tried using '~/.xprofile'
> > first.
> >
> > I believe the information about this from the Arch Wiki applies equally
> > to Debian.
> >
> > https://wiki.archlinux.org/index.php/xprofile
>
> wooledg@wooledg:~$ grep -r xprofile /etc/X11
> wooledg@wooledg:~$

Good catch! You can have a ~/.xprofile but none of the files in /etc/X11
will look for it. startx uses only the files in /etc/X11; it will ignore
whatever is in such a file.

That does not mean nothing else will look for ~/.xprofile and source it
if it exists. It's one of the wonders of Debian; just when you think you
have a total grasp of the situation something extra comes to light. Time
for some not very onerous detective work. (Clue: DM).

> Apparently Debian's "X session" is heavily customized, as described in
> https://www.debian.org/doc/manuals/debian-reference/ch07.en.html#_starting_the_x_window_system
>
> Arch's customizations are different and don't appear to be the same
> as Debian's.

I'm going to say there is nothing in Arch's setup and documentation
which helps with customising Debian's X. In particular, Debian does not
use ~/.xinitrc. Advice on this file is splattered all over the web and
has lead many a Debian user down a dead end road.

> What I was missing was a simple pointer from lightdm's joke of a man page
> to either Xsession(5), with some indication that lightdm *runs* a Debian
> X session, or directly to the debian-reference web page.

It has to execute an Xsession, either by using the existing one in
/etc/X11 or offering its own. Or a combination of both. Or something
else nobody has mentioned yet.

You could prevent people rolling in the aisles by providing patches for
the manual which would make the situation clearer if your intention is
to improve the documentation. kdm's approach is:

DESCRIPTION
kdm is the KDE display manager also known as login manager. It shows a
graphical login screen for username and password. After authenticating
the user it starts a session.

kdm can be configured for remote login via XDMCP. XDMCP is the "X Dis‐
play Manager Control Protocol" which is used to set up connections
between remote systems over the network.

kdm is a derivative of xdm. man 1 xdm may provide useful information
(requires installed xdm). For X-related problems try man 7x X and man 1
startx.

[Tixy]

On Thu, 2016-09-22 at 10:56 -0400, Greg Wooledge wrote:
> On Thu, Sep 22, 2016 at 03:15:40PM +0100, Tixy wrote:
> > I edit ~/.xsessionrc to have a single line:
> >
> > . /home/tixy/.profile
>

> [...] how did you learn about it?

Reading the debian-user list for many years :-)

--
Tixy

[Brian]

On Thu 22 Sep 2016 at 09:11:53 -0400, Greg Wooledge wrote:

> On Wed, Sep 21, 2016 at 09:19:11PM -0500, David Wright wrote:
>
> > I'm not a DE or DM user, so I'm know very little about them.
>
> Yes, THIS is the problem! You, and I, and everyone else on the guru side
> are just completely stumped.

No, the problem is you snipped most of what David Wright said and the
essence of his point as I (a non-guru) understood it was lost. So, here
it is again:

> I'm not a DE or DM user, so I'm know very little about them. But I

> don't understand the concept of "user configuration" for a DM.
> Wouldn't that be like a user configuring /etc/issue, the login prompt
> or /etc/motd ?

Logging in on a terminal involves a getty and login prompt. This is not
user configurable. You fit in with what is offered or you do not get to
log in. It doesn't matter if you have a deep understanding of the
process or not.

A DM offers the same options of username and password. A user cannot
configure that offering in any other way. What's the difference?

You might have a legitimate complaint about a DM's documentation but
that is a different issue which can be rectified with co-operation
between DM developers and users.

--
Brian.

[Brian]

On Thu 22 Sep 2016 at 09:11:53 -0400, Greg Wooledge wrote:

> On Wed, Sep 21, 2016 at 09:19:11PM -0500, David Wright wrote:
> > But I don't understand the concept of "user configuration" for a DM.
> > Wouldn't that be like a user configuring /etc/issue, the login prompt
> > or /etc/motd ?
>
> By user configuration, I mean "which files can the user edit, without
> superuser privileges, to alter the behavior of the program".

Some of them are listed in the next quoted piece of text. Which ones are
not acted on when a DM is used? .xsession? ,xsessionrc? Do you evidence
this is not the case?

(Forget about .xinitrc. It is an abomination and of no use on Debian).

> > Are you perhaps talking about which file,
> > like .xsession, .xsessionrc, .Xsession, .xinitrc, etc gets executed
> > when you login through the DM?

--
Brian.

[Greg Wooledge]

I've edited https://wiki.debian.org/LightDM and written
https://wiki.debian.org/Xsession from scratch. I hope this helps other
people who were as lost and confused as I was.

If you're still wondering what kind of documentation I was looking for,
you may use https://wiki.debian.org/Xsession as the answer. That's
what I wanted to see. I will be able to point users to this page in
the future.

Thanks to all who provided information.

[Dominic Knight]

There also used to be .Xresources to store information on fonts,
colours, window sizes and positions along with dpi, this I believe
was/is read by .Xsession. Unsure whether it is still used and/or
relevant?

Dom

[Seeker]

On 9/22/2016 10:45 AM, Brian wrote:
> On Thu 22 Sep 2016 at 12:10:35 -0400, Greg Wooledge wrote:
>
>> On Thu, Sep 22, 2016 at 09:00:11AM -0700, Seeker wrote:
>>> A little late, but personally I would have tried using '~/.xprofile'
>>> first.
>>>
>>> I believe the information about this from the Arch Wiki applies equally
>>> to Debian.
>>>
>>> https://wiki.archlinux.org/index.php/xprofile
>>
>> wooledg@wooledg:~$ grep -r xprofile /etc/X11
>> wooledg@wooledg:~$
>
> Good catch! You can have a ~/.xprofile but none of the files in /etc/X11
> will look for it. startx uses only the files in /etc/X11; it will ignore
> whatever is in such a file.
>
> That does not mean nothing else will look for ~/.xprofile and source it
> if it exists. It's one of the wonders of Debian; just when you think you
> have a total grasp of the situation something extra comes to light. Time
> for some not very onerous detective work. (Clue: DM).
>

Way back I used to use '~/.profile'. Somewhere along the way, maybe
because I stopped using GDM, that quit working. The indication at that
time was it was not a bug and the recommendation seemed to be to use
'~/.xprofile'.

I'm running unstable by the way.

It's been a while since I needed to set variables during login.

I do see a '/etc/X11/Xsession.d/60xprofile' file that looks like it
should cause '/etc/xprofile' and '~/.xprofile' to get sourced, but that
doesn't seem to be happening on my system.

I'm using lightdm for my display manager, lxqt for my desktop, with
openbox for the window manager most of the time.

Will have to look at lxde and kde to see if it is a desktop thing or
something else.

Later, Seeker

[Curt]

Nicolas Georges gave some interesting information once when I said that
.Xdefaults was "deprecated" concerning what is read by what where and
why (went over my head, of course).

Here it is:

Well, I was gonna give the link but it's short enough to quote:

(responding to my claim that .Xdefaults is deprecated)

It is a bit more complicated than that.

~/.Xresources is loaded into the resources database of the X11 server by
/etc/X11/Xsession.d/30x11-common_xresources. The resource database is a
property of the root window, you can observe it roughly with "xprop -root",
see the RESOURCE_MANAGER entry; "xrdb -query" is the dedicated tool to
observe it.

~/.Xdefaults and ~/.Xdefaults-$HOSTNAME are read by the X11 libraries
directly.

It makes a big difference for remote applications, since they will see the
.Xresources from the server but the .Xdefaults from the client.

--
“It is enough that the arrows fit exactly in the wounds that they have made.”
Franz Kafka

[to...@tuxteam.de]

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

On Fri, Sep 23, 2016 at 08:57:18AM +0000, Curt wrote:

[...]

> Nicolas Georges gave some interesting information once when I said that
> .Xdefaults was "deprecated" concerning what is read by what where and
> why (went over my head, of course).
>
> Here it is:
>
> Well, I was gonna give the link but it's short enough to quote:
>
> (responding to my claim that .Xdefaults is deprecated)
>
> It is a bit more complicated than that.
>
> ~/.Xresources is loaded into the resources database of the X11 server

> [...]

> ~/.Xdefaults and ~/.Xdefaults-$HOSTNAME are read by the X11 libraries
> directly.
>
> It makes a big difference for remote applications, since they will see the
> .Xresources from the server but the .Xdefaults from the client.

Yes, here is a pretty good overview, with many links:

http://superuser.com/questions/243914/xresources-or-xdefaults

To grok all that it's important to remember that the program (under X)
doesn't have to run on the same machine as the display (and you sometimes
want to tune the display part depending on the capabilities of the
display, not the machine where the program is running, e.g. imagine
a program showing one window in a low-res colour display (e.g. a GUI) and
another on a hi-res black-and-white (e.g. a hi-res X ray image). You'll
want different fonts on each, for example.

regards
- -- t

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

iEYEARECAAYFAlfk9mgACgkQBcgs9XrR2kYuHwCcD3VKBx2ctFZCJE6h54B+uUpP
rE4An1yNBWSVc1zjM+8vfU+T3NxzeXLV
=6T34
-----END PGP SIGNATURE-----

[to...@tuxteam.de]

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

On Fri, Sep 23, 2016 at 11:31:20AM +0200, to...@tuxteam.de wrote:

[...]

> > It makes a big difference for remote applications, since they will see the
> > .Xresources from the server but the .Xdefaults from the client.

Forgot to say that typically, .Xdefaults overrides .Xresources, so if you
want to take advantage of .Xresources, you better avoid .Xdefaults. But in
the widespread one-machine-does-all approach it makes little difference.

You'll notice it in a situation like this: imagine a Raspi back there in
the closet, with a lo-res display (say, 320x240). You'll want pretty small
fonts on that, to fit anything on screen. Now you ssh -X into that from
your workstation (1600x1200). The fonts used in the Raspi will be unreadable.

The graphical app running on the Raspi should "honour" your workstation's
font choice, otherwise you'd need a magnification glass. How? Well, the
X server on your workstation is the one doing the display work anyway,
and has its own set of .Xresources. Had you set an .Xdefaults on the
Raspi, the X library would override that -- most likely not what you
want (but if you choose wisely what to set, you might put that to good
use, perhaps coluring the windows differently to give you a hint of
where the app is running, I don't know).

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

iEYEARECAAYFAlfk+NcACgkQBcgs9XrR2kbWeACfZLV80sFo5Bp8BzblWizm/01Q
NGYAniTbQkeNf9QjxKyWvhfZzXm/ap4X
=90Rv
-----END PGP SIGNATURE-----

[Brian]

Yes, I know it is a wiki and I can edit it but it is off my agenda for
the time being, so I will just content myself with a few comments which
might be acted on.

> User configuration should be done by creating a ~/.xsessionrc.....

User configuration may be carried out in ~/.xsessionrc but it can also
be done in ~/.xsession, the startup program. Or both can be used.

If a window manager or desktop session is to be executed in ~/.xsession
('exec fvwm', for example) then one may as well put everything else
(environment variables, programs to start etc) there too. Nothing is
gained by spreading the load and its maintenance across two files or
putting it all in ~/.xsessionrc. Having everything in ~/.xsession fits
the traditional way of doing things and, importantly, it fits the startx
and Xsession documentation.

~/.xsessionrc was introduced in 2007 in response to a perceived problem.
If the choice of DE (or WM) and terminal is left in the care of the
system's x-session-manager, x-window-manager and x-terminal-emulator
nothing need be put in ~/.xsession. In fact, it lloks like nothing can
go in ~/.xsession because it requires 'exec fvwm' or some such line. (I
suppose if x-window-manager was fvwm and ~/.xsession had 'exec fvwm'
50x11-common_determine-startup would cope with it. The relevance of
~/.xsessionrc to the startup procedure would then become questionable).

Anyway, this was seen to leave nowhere to put environment variables or,
for that matter, other configuration snippets. That is why we have
~/.xsessionrc. It is not a replacement for ~/.xsession; it is not a more
modern approach; but it does allow for a ~/.xsession without an exec
line. Could a user use it for configuration? Of course she could.
*Should* all users be directed to use it? That doesn't fit in with the
documentation and the file's intended purpose of exporting variables to
the whole X session.

> If you selected a GNOME session, additional configuration will be
> read from the ~/.gnomerc file, if it exists.

GDM3 users (who needn't be GNOME users) have ~/.xprofile for their use.

> You may dot in.....

A bit of jargon? I'd remove it (them) and replace with an example and a
mention of sourcing a file.

--
Brian.

[Seeker]

In spite of the existence of 60xprofile and the fact that '~/.xprofile'
did get sourced in the ast, I'm not finding any information on when you
might expect xprofile/.xprofile to get sourced or not sourced.

So it looks like '~/.xsessionrc' is way to go.

I guess the next question would be....

Can we expect this to continue working over the long haul with a Wayland
session or will we have to start putting things into
'~/.config/autostart/'?

Later, Seeker

[Brian]

To the very best of my knowledge ~/.xprofile has never been a feature of
Debian's X configuration files in /etc/X11. However, it is acted on by
gdm3 in *its* Xsession script.

What does

dpkg -S /full/path/to/60xprofile

give you?

> So it looks like '~/.xsessionrc' is way to go.

For what? In what circumstance?

> I guess the next question would be....
>
> Can we expect this to continue working over the long haul with a Wayland
> session or will we have to start putting things into
> '~/.config/autostart/'?

Pass.

--
Brian.

[Seeker]

On 9/23/2016 10:28 AM, Brian wrote:
> On Fri 23 Sep 2016 at 10:07:43 -0700, Seeker wrote:
>
>> On 9/22/2016 6:18 PM, Seeker wrote:

<Snip>

>> In spite of the existence of 60xprofile and the fact that '~/.xprofile' did
>> get sourced in the ast, I'm not finding any information on when you
>> might expect xprofile/.xprofile to get sourced or not sourced.
>
> To the very best of my knowledge ~/.xprofile has never been a feature of
> Debian's X configuration files in /etc/X11. However, it is acted on by
> gdm3 in *its* Xsession script.
>
> What does
>
> dpkg -S /full/path/to/60xprofile
>
> give you?
>

It tells me 'no path found matching pattern'

Looks like a leftover from something possibly non-debian. Last modified
date 2007 if you trust that to mean anything.

Running cruft on the system now to see what it has to report.

The list of unexaplained files is big, but outside of 60xprofile and
stuff in '/usr/src' it mostly looks like autogenerated stuff.

I still have a directory in /usr/src for the 2.4.23 kernel and google
tells me that was released Nov 2003, so it's been sometime before that
since I've done a clean install. Following unstable the whole time and
making the transition from 32bit to 64bit the hard way somewhere along
the way. I have had my binge and 'dpkg --purge --force-depends' moments
along the way where I looked for and deleted related orphaned stuff
before re-installing some or all of the purged packages, but it seems
reasonable to expect I didn't get all the orphaned stuff along the way.

>> So it looks like '~/.xsessionrc' is way to go.
>
> For what? In what circumstance?
>

For me personally, I only ever remember using .profile/.xprofile to set
environment variables (my memory is terrible). The path mainly, but
other things come up once in a while. Seemed like it was short lived,
but there was a variable that could be set to make
'Ctrl'+'Alt'+'Backspace' work in your X session. I had a locale issue
at one point, so was setting the locale in .profile/.xprofile (whatever
worked at the time) for a while, 'till I got that real issue sorted out.

These are the things I would use '~/.xsessionrc' for.

>> I guess the next question would be....
>>
>> Can we expect this to continue working over the long haul with a Wayland
>> session or will we have to start putting things into
>> '~/.config/autostart/'?
>
> Pass.
>

It has it's uses.

If I want a program to run independently of what desktop session I am
running, I create a .desktop file or grab an existing one and modify it,
then put it in '~/.config/autostart/'.

https://linuxcritic.wordpress.com/2010/04/07/anatomy-of-a-desktop-file/

I made a copy of '/etc/xdg/autostart/pulseaudio.desktop' in my
'~/.config/autostart/' and changed 'Exec=start-pulseaudio-x11' to
'Exec=' so pulse doesn't start automatically but is still available.
KDE did have it's own .desktop file for starting pulseaudio, but I
don't currently see one in '/etc/xdg/autostart' there may or may not
still be one in a KDE specific directory, I do have a
pulseaudio-kde.desktop file in my autostart that also has the target of
the 'Exec=' line removed.

Later, Seeker

[Brian]

On Fri 23 Sep 2016 at 17:36:11 +0100, Brian wrote:

> ~/.xsessionrc was introduced in 2007 in response to a perceived problem.
> If the choice of DE (or WM) and terminal is left in the care of the
> system's x-session-manager, x-window-manager and x-terminal-emulator
> nothing need be put in ~/.xsession. In fact, it lloks like nothing can
> go in ~/.xsession because it requires 'exec fvwm' or some such line. (I
> suppose if x-window-manager was fvwm and ~/.xsession had 'exec fvwm'
> 50x11-common_determine-startup would cope with it. The relevance of
> ~/.xsessionrc to the startup procedure would then become questionable).

Having seen that ~/xsessionrc does nothing particularly special for
starting an X session (apart from what has been described earlier) we
can move on to

> There are typically two kinds of commands you may wish to use
> in this file:

Only two? Where does that leave

xterm &
setroot -solid blue
xbindkeys

Where would they go?

> You may place environment variable definitions here, directly:
> export SOME_VAR="some value"

You may; but any advantage it gives is not explained. One may as well be
reading the lightdm manual for guidance about what a session manager
does.

> You may dot in some other POSIX shell configuration file:
> if [ -r > ~/.profile ]; then . ~/.profile; fi

This (like environment variable definitions) can be put in ~/.xsession.
Substituting ~/xsession for ~/.xinitrc in the first two paragraphs of
this Arch wiki page

https://wiki.archlinux.org/index.php/Xinit

reinforces the the concept.

I don't think I shall be pointing a user to this wiki page in its
present state.

--
Brian.

[Brian]

~/.xessionrc as the primary file for configuring startup of X is not
only not necessary but has a disadvantage from an administrator's
point of view.

> System-wide configuration of the Debian X session consists
> mainly of options inside the /etc/X11/Xsession.options file,
> and scripts inside the /etc/X11/Xsession.d directory. These
> scripts are all dotted in by a single /bin/sh shell, in the
> order determined by sorting their names. Administrators may
> edit the scripts, though caution is advised if you are not
> comfortable with shell programming.

Correct, but it neglects an aspect of ~/.xessionrc integration into
Debian's X which renders any editing of Xsession.options by an
adminstrator ineffective. Essentionally, 50x11-common_determine-startup
has

if [ -z "$STARTUP" ]; then
if has_option allow-user-xsession; then
for STARTUPFILE in "$USERXSESSION" "$ALTUSERXSESSION"; do

There is no corresponding restriction in 40x11-common_xsessionrc and a
user can put what she wants in ~/.xessionrc. Security is first designed
in and then designed out.

To be fair, the documentation is hazy on this and it is probably a bug.
But surely the purpose of a wiki page is not only to fit and explain the
official documentation but, where necessary, expand on it and even
correct it.

The existence of ~/.xessionrc appears to cause more problems than it
purportedly solves.

--
Brian.

[Brian]

On Sun 25 Sep 2016 at 18:55:03 +0100, Brian wrote:

> The existence of ~/.xessionrc appears to cause more problems than it
> purportedly solves.

And it still won't lie down and die. It is determined to take over the
traditional role of ~/.xsession and prove its worth. However, kudos for
the editing of

https://wiki.debian.org/Xsession

to help Debian users.

But now we have

> User configuration may be done in a few different ways. The simplest
> way is to create a ~/.xsessionrc file,.....

The pedantic side of me asks - why is it the simplest way? And in what
cirumstances? The technical side of me answers that a long-lived process
does not have to be specified in it; the alternatives system can be
relied on to bring up the window or session manager.

That's not a bad reason to use it exclusively (which you would have to
in the absence of ~/.xsession) but it basically caters for the user who
is reluctant or too lazy or, more likely, doesn't know to put 'exec
x-session-manager' in ~/.xsession.

There is also no mention of ~/.xessionrc as a different way of user
configuration in the documentation. Quite the opposite. startx(1) says
.xsession is the file to use. 50x11-common_determine-startup more or
less says the same thing.

~/.xsessionrc doesn't have magical properties within Debian's X. If it
disappeared tomorrow X would be none the worse for it. Programs could
still be started, environment variables set, window managers brought up
etc. Believe in ~/.xsession; ignore all imitations; it is the one and
only true X configuration file for users.

Carrying on with the wiki:

> A more advanced alternative is to use the ~/.xsession file. This
> file, if it exists, is used instead of the system-wide default
> x-session-manager or x-window-manager. Therefore, if you use it,
> you must ensure that it launches your desired window manager (WM)
> or desktop environment (DE).

~/.xsession is now raised to the status of a "more advanced alternative"
to ~/.xsessionrc. This is a special view of the situation not borne out
by any documentation. The remainder of the paragraph is not quite
correct. If ~/.xsession exists it is used and will start whatever is on
an 'exec' line. This could be a particular WM or DE ('exec fvwm', 'exec
gnome-session', for example). 'exec x-window-manager' is a valid line.
All you have to ensure is that it starts a process which does not
complete. (As a matter of interest, 'exec xterm' would be ok).

> Finally, note that the ~/.xsession file is only read if you
> are using a Debian X session. If you login with gdm3 and
> choose a GNOME session, the ~/.xsession file will be ignored
> completely. (But you may still use ~/.xsessionrc.)

Not observed in testing. /etc/gdm3/Xsession also has a stanza beginning
"SESSIONFILES=$(run_parts $(SYSSESSIONDIR)" which also appears to
contradict this statement. SYSSESSIONDIR is /etc/X11/Xsession.d.

--
Brian.

[Greg Wooledge]

On Mon, Sep 26, 2016 at 10:19:27PM +0100, Brian wrote:
> But now we have
>
> > User configuration may be done in a few different ways. The simplest
> > way is to create a ~/.xsessionrc file,.....
>
> The pedantic side of me asks - why is it the simplest way? And in what
> cirumstances?

Because it's *additive*. It's just some stuff that happens in addition
to the system launching your default WM/DE, and whatever else the
system does by default (setting up an ssh-agent? I don't even know).
You don't have to do all of those things yourself.

Just counting lines of code in the most ridiculously oversimplified
cse, it should be obvious that

PATH=~/bin:$PATH

is simpler than

PATH=~/bin:$PATH
exec x-session-manager

Two is more than one.

> > Finally, note that the ~/.xsession file is only read if you
> > are using a Debian X session. If you login with gdm3 and
> > choose a GNOME session, the ~/.xsession file will be ignored
> > completely. (But you may still use ~/.xsessionrc.)
>
> Not observed in testing. /etc/gdm3/Xsession also has a stanza beginning
> "SESSIONFILES=$(run_parts $(SYSSESSIONDIR)" which also appears to
> contradict this statement. SYSSESSIONDIR is /etc/X11/Xsession.d.

If I've made factual errors, please correct them. I'm trying my best to
piece together how gdm3 works based on the existing documentation (written
by Overfiend over a decade ago), and other, older wiki pages which may
themselves be incorrect, and my extremely limited past knowledge of gdm.
Note that I do not *use* gdm3 myself, nor lightdm, nor xdm, or any other
display manager, but I did briefly experiment with gdm many years back.

I leave you with this (perhaps) amusing excerpt from a ~/.xsession file,
a remnant of those experimental days. Make of this what you will.

=========================================================================
# If we're running under gdm, then we do *not* want gnome-session to be
# spawned when this script exits. I learned this hack by reading the
# /etc/gdm/Sessions/Gnome file (IIRC).
DEBUG_GNOME_SESSION='Let me the hell out!'
=========================================================================

Back then, under gdm, if you had an .xsession file, it would be read, but
then after you exited from your chosen window manager, you'd get GNOME!
Or at least that's how I remember it. And setting this shell variable
caused that not to happen. And it was all completely undocumented,
because why would a user with gdm installed ever want anything *other*
than GNOME?

[Neal P. Murphy]

On Mon, 26 Sep 2016 22:19:27 +0100
Brian <ad...@cityscape.co.uk> wrote:

> On Sun 25 Sep 2016 at 18:55:03 +0100, Brian wrote:
>
> > The existence of ~/.xessionrc appears to cause more problems than it
> > purportedly solves.
>
> And it still won't lie down and die. It is determined to take over the
> traditional role of ~/.xsession and prove its worth. However, kudos for
> the editing of
>
> https://wiki.debian.org/Xsession
>
> to help Debian users.

[Thread fork...]

A semantic observation (probably unrelated to the aforementioned editing):
"... dot in ..." might be more clearly stated as "... source ( or '.') in ..." because the action is to source the script into the current shell (thus retaining the defined vars), as opposed to executing the script in another shell or in a subshell (thus the var definitions are lost when the shell or subshell exits).

[Seeker]

On 9/26/2016 2:44 PM, Greg Wooledge wrote:
> On Mon, Sep 26, 2016 at 10:19:27PM +0100, Brian wrote:
>> But now we have
>>
>> > User configuration may be done in a few different ways. The simplest
>> > way is to create a ~/.xsessionrc file,.....
>>
>> The pedantic side of me asks - why is it the simplest way? And in what
>> cirumstances?
>
> Because it's *additive*. It's just some stuff that happens in addition
> to the system launching your default WM/DE, and whatever else the
> system does by default (setting up an ssh-agent? I don't even know).
> You don't have to do all of those things yourself.
>
> Just counting lines of code in the most ridiculously oversimplified
> cse, it should be obvious that
>
> PATH=~/bin:$PATH
>
> is simpler than
>
> PATH=~/bin:$PATH
> exec x-session-manager
>
> Two is more than one.

If you use a display manager and only one desktop, it's not really an issue.

If you boot to the console and log in you can have .xsession.desktop1,
.xsession.desktop2, .xsession.desktop3, etc...

And do

mv .xsession.desktopX .xsession

before starting your xsession, so not much of an issue there either.

>
>> > Finally, note that the ~/.xsession file is only read if you
>> > are using a Debian X session. If you login with gdm3 and
>> > choose a GNOME session, the ~/.xsession file will be ignored
>> > completely. (But you may still use ~/.xsessionrc.)
>>
>> Not observed in testing. /etc/gdm3/Xsession also has a stanza beginning
>> "SESSIONFILES=$(run_parts $(SYSSESSIONDIR)" which also appears to
>> contradict this statement. SYSSESSIONDIR is /etc/X11/Xsession.d.
>
> If I've made factual errors, please correct them. I'm trying my best to
> piece together how gdm3 works based on the existing documentation (written
> by Overfiend over a decade ago), and other, older wiki pages which may
> themselves be incorrect, and my extremely limited past knowledge of gdm.
> Note that I do not *use* gdm3 myself, nor lightdm, nor xdm, or any other
> display manager, but I did briefly experiment with gdm many years back.
>

I have a .xsession file, it's set up to start fluxbox on the exec line.

The .xsession file only gets read when I have the default/debian
xsession selected.

Currently I'm using lightdm, before that kdm, before that gdm3, so it's
been a while since I used gdm3. Occasionally I would switch to wdm if
something weird was happening and wanted to see if it happened with a
different display manager.

It's possible that something changed with gdm3 after I stopped using it,
or that it's been long enough I just don't remember, but I don't
remember any of these in recent years using the .xsession file if you
use a session other than the default session.

I only verified use of .xsessionrc to set variables using lightdm as my
display manager and lxqt as my X session. Putting a line in .xsessionrc
to export a variable works.

Later, Seeker

[Greg Wooledge]

On Mon, Sep 26, 2016 at 10:46:07PM -0700, Seeker wrote:
> It's possible that something changed with gdm3 after I stopped using it,
> or that it's been long enough I just don't remember, but I don't
> remember any of these in recent years using the .xsession file if you
> use a session other than the default session.

OK, good. That matches what the debian-reference documentation says,
and what I wrote on the wiki.

I also have this file, from back in my experimenting-with-gdm days:

titan:~$ ls -l .gnomerc
-rw-r--r-- 1 greg greg 36 Jun 28 2002 .gnomerc
titan:~$ cat .gnomerc
[ -f ~/.xsession ] && . ~/.xsession

So that might be why my ~/.xsession was being read -- because it was
dotted in from ~/.gnomerc, which was read by either gdm or whatever
gdm executed.

It was 14 years ago, so I don't remember every detail.

[Greg Wooledge]

On Mon, Sep 26, 2016 at 05:58:59PM -0400, Neal P. Murphy wrote:
> A semantic observation (probably unrelated to the aforementioned editing):
> "... dot in ..." might be more clearly stated as "... source ( or '.') in
> ..." because the action is to source the script into the current shell (thus
> retaining the defined vars), as opposed to executing the script in another
> shell or in a subshell (thus the var definitions are lost when the shell or
> subshell exits).

I explicitly avoided the word "source" because it is a bash extension,
and thus will not work in the POSIX sh that reads these files.

If you could go back in time to ~1978 and put the "source" command into
the Bourne shell, so that it would be a recognized command in all of
the Bourne family shells today, then we wouldn't have this confusion.

[Brian]

On Mon 26 Sep 2016 at 17:44:17 -0400, Greg Wooledge wrote:

> On Mon, Sep 26, 2016 at 10:19:27PM +0100, Brian wrote:
> > But now we have
> >
> > > User configuration may be done in a few different ways. The simplest
> > > way is to create a ~/.xsessionrc file,.....
> >
> > The pedantic side of me asks - why is it the simplest way? And in what
> > cirumstances?
>
> Because it's *additive*. It's just some stuff that happens in addition
> to the system launching your default WM/DE, and whatever else the
> system does by default (setting up an ssh-agent? I don't even know).
> You don't have to do all of those things yourself.
>
> Just counting lines of code in the most ridiculously oversimplified
> cse, it should be obvious that
>
> PATH=~/bin:$PATH
>
> is simpler than
>
> PATH=~/bin:$PATH
> exec x-session-manager
>
> Two is more than one.

We learn something new every day. :)

Ok, let's go along with ~/.xsessionrc being the simplest way for a user
to configure his X session. I'll follow the advice on the wiki and have

PATH=~/bin:$PATH
xterm &
iceweasel &
exec fvwm

That will work. The programs and WM will start and the variable will be
set. As a new user I should be a happy bunny. Except..... what I do not
really appreciate is that the fvwm process does not exit; none of the
scripts after 40x11-common_xsessionrc will be used.

Putting 'exec fvwm' in ~/.xsession is the solution, of course; it's your
best friend, so may as well put everything else there. What price this
upstart ~/.xsessionrc? Does it ever get anything right? The only thing
it is good for is getting round restrictions set by the administrator.

> > > Finally, note that the ~/.xsession file is only read if you
> > > are using a Debian X session. If you login with gdm3 and
> > > choose a GNOME session, the ~/.xsession file will be ignored
> > > completely. (But you may still use ~/.xsessionrc.)
> >
> > Not observed in testing. /etc/gdm3/Xsession also has a stanza beginning
> > "SESSIONFILES=$(run_parts $(SYSSESSIONDIR)" which also appears to
> > contradict this statement. SYSSESSIONDIR is /etc/X11/Xsession.d.
>
> If I've made factual errors, please correct them. I'm trying my best to
> piece together how gdm3 works based on the existing documentation (written
> by Overfiend over a decade ago), and other, older wiki pages which may
> themselves be incorrect, and my extremely limited past knowledge of gdm.
> Note that I do not *use* gdm3 myself, nor lightdm, nor xdm, or any other
> display manager, but I did briefly experiment with gdm many years back.

There is a need for the sort of wiki page you have created but at its
present stage of development I would see it as ill-mannered and
presumptious to leap in and alter it. It might have been discerned that
my focus would be on ~/.xsession. Something on ~/.xsessionrc would be
there. I might not be the best person to write it as my view of the file
is inclining to advocating eliminating it from Debian.

There should be entry on how the DMs interoperate with X. I wouldn't
like to guess how involved the research would be.

--
Brian.

[Greg Wooledge]

On Tue, Sep 27, 2016 at 03:15:54PM +0100, Brian wrote:
> Ok, let's go along with ~/.xsessionrc being the simplest way for a user
> to configure his X session. I'll follow the advice on the wiki and have
>
> PATH=~/bin:$PATH
> xterm &
> iceweasel &
> exec fvwm

No, this is not what I advised. You don't start a window manager from
this file.

> Putting 'exec fvwm' in ~/.xsession is the solution, of course; it's your
> best friend, so may as well put everything else there. What price this
> upstart ~/.xsessionrc? Does it ever get anything right? The only thing
> it is good for is getting round restrictions set by the administrator.

You are not a beginner. You're advanced.

A beginner would just install *one* window manager, and this
would be executed automatically by the Debian X session (via the
/usr/bin/x-window-manager symlink ultimately). (S)he would use
a ~/.xsessionrc file only to set the PATH variable, or JAVA_HOME, or
whatever the original question is.

You don't need a ~/.xsession file until you get to the point where
you want to install multiple WMs at the same time and choose among
them. And even then, at that point, many beginners will still prefer
update-alternatives (as root) over editing a ~/.xsession file in their
own home directory. This may shock you, since you have a strong
Linux or Unix background, but I see it all the time. These are the
same people who think putting a colored PS1 prompt in /etc/bash.bashrc
is a Really Awesome Idea.

[Brian]

On Tue 27 Sep 2016 at 10:29:44 -0400, Greg Wooledge wrote:

> On Tue, Sep 27, 2016 at 03:15:54PM +0100, Brian wrote:
> > Ok, let's go along with ~/.xsessionrc being the simplest way for a user
> > to configure his X session. I'll follow the advice on the wiki and have
> >
> > PATH=~/bin:$PATH
> > xterm &
> > iceweasel &
> > exec fvwm
>
> No, this is not what I advised. You don't start a window manager from
> this file.

You advised ~/.xsessionrc as the best user route to configuration.
Starting a WM is a crucial part of configuration.

> > Putting 'exec fvwm' in ~/.xsession is the solution, of course; it's your
> > best friend, so may as well put everything else there. What price this
> > upstart ~/.xsessionrc? Does it ever get anything right? The only thing
> > it is good for is getting round restrictions set by the administrator.
>
> You are not a beginner. You're advanced.

I was trying to put myself in the same position as one. The target
audience matters.

> A beginner would just install *one* window manager, and this
> would be executed automatically by the Debian X session (via the
> /usr/bin/x-window-manager symlink ultimately). (S)he would use
> a ~/.xsessionrc file only to set the PATH variable, or JAVA_HOME, or
> whatever the original question is.

Most people (beginners or not) install GNOME, KDE etc and that's it.
They see no need to go beyond that. Nothing wrong there. They are not
your audience.

> You don't need a ~/.xsession file until you get to the point where
> you want to install multiple WMs at the same time and choose among
> them. And even then, at that point, many beginners will still prefer
> update-alternatives (as root) over editing a ~/.xsession file in their
> own home directory. This may shock you, since you have a strong
> Linux or Unix background, but I see it all the time. These are the
> same people who think putting a colored PS1 prompt in /etc/bash.bashrc
> is a Really Awesome Idea.

We are talking about a wiki which concentrates on user configuration;
what root can do is immaterial.

You need a ~/.xsession file when you need a ~/.xsession file. Isn't it
one purpose of the wiki to explain how it fits into the traditional X
configuration and why one might be useful. Instead, we appear to have
~/.xsessionrc promoted as the One True Way; how did you come to that
conclusion?

--
Brian.
Who is sometimes bemused but very rarely shocked.

[Greg Wooledge]

On Tue, Sep 27, 2016 at 04:52:34PM +0100, Brian wrote:
> You need a ~/.xsession file when you need a ~/.xsession file. Isn't it
> one purpose of the wiki to explain how it fits into the traditional X
> configuration and why one might be useful. Instead, we appear to have
> ~/.xsessionrc promoted as the One True Way; how did you come to that
> conclusion?

Because it is the only thing that *actually works* no matter which
display manager and which session type the user is running. If the
user is running gdm3 and using a GNOME session and wants to add a
directory to PATH, ~/.xsessionrc can do that. If the user is running
startx, ~/.xsessionrc still works. If the user is running lightdm
with a Debian X session, ~/.xsessionrc still works.

In fact, that's why Debian *created* it. They wanted something that
would Just Work. There was no existing tool that could fill that role.

If you prefer ~/.xsession because you've already learned never to run
gdm3, great. Go ahead and use that. I use ~/.xsession myself. I
didn't even know about ~/.xsessionrc until I started down this path
and someone linked to the debian-reference web page. That's where I
learned about it. Its purpose was immediately clear to me.

Now I have an answer for the end-user questions that have been stumping
me for years... at least in #debian. #bash is another story.

[Brian]

On Tue 27 Sep 2016 at 12:05:37 -0400, Greg Wooledge wrote:

> On Tue, Sep 27, 2016 at 04:52:34PM +0100, Brian wrote:
> > You need a ~/.xsession file when you need a ~/.xsession file. Isn't it
> > one purpose of the wiki to explain how it fits into the traditional X
> > configuration and why one might be useful. Instead, we appear to have
> > ~/.xsessionrc promoted as the One True Way; how did you come to that
> > conclusion?
>
> Because it is the only thing that *actually works* no matter which
> display manager and which session type the user is running. If the
> user is running gdm3 and using a GNOME session and wants to add a
> directory to PATH, ~/.xsessionrc can do that. If the user is running
> startx, ~/.xsessionrc still works. If the user is running lightdm
> with a Debian X session, ~/.xsessionrc still works.

It is not the only thing that works. ~/.xsession also works. gdm3, kdm,
lightdm and xdm source the files in Xsession.d. All this can be tested
and found to be in conformance with what the packages claim to do.

> In fact, that's why Debian *created* it. They wanted something that
> would Just Work. There was no existing tool that could fill that role.

"Just Works" is a very dangerous principle to advocate or follow. It can
lead to all sorts of things. With ~/.xsessionrc it leads to completely
breaking Xsession.options. Is this the sort of OS we want? Something
useful at the expense of something else.

(Shell programmers know all about the "Just Works" idea).

The existing file at the time which worked was ~/.xsession. But (it has
been said before) it requires an exec line. If you had said "there was
was no existing tool that could fill the role of setting variables
without an exec line in ~/.xsession" I wouldn't have had to write this.

Precision of expression matters. We have had "should" and "simplest" on
the wiki to promote a particular file. How about going one step further
and trying not to grind *any* axes (which is how this wiki page came
into existence)? Detachment is never a bad thing with technical writing.
A section which said:

~/.xsessionrc is intended for environment variables. For example
export SOME_VAR="some value"

would meet no criticism. It is factual and fits in with the official
documentation. You could even go on to mention the ~/.profile problem
and how gdm3, kde and lightdm tackles it. Facts and more facts; not
something which relies on the writer's interpretation.

It doesn't matter whether there are people who think a ~/.xsessionrc is
a security hole or a waste of time. The wiki is not a place for opinion
or for trying to turn a rant into a useful resource.

> If you prefer ~/.xsession because you've already learned never to run
> gdm3, great. Go ahead and use that. I use ~/.xsession myself. I
> didn't even know about ~/.xsessionrc until I started down this path
> and someone linked to the debian-reference web page. That's where I
> learned about it. Its purpose was immediately clear to me.

You had a "Road to Damascus" experience? It would have been better to
have read #636108. (Which is what the initial post in this thread was
all about). The ensuing discusssion might have been more fruitful.

> Now I have an answer for the end-user questions that have been stumping
> me for years... at least in #debian. #bash is another story.

Are you serving your own needs or the needs of users? It is necessary to
be careful about this and it is not easy.

--
Brian.