Subject: 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.

From: Tony Baldwin <[email-masked]>
Date: Wed, 21 Sep 2016 09:43:15 -0400

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

---

From: Greg Wooledge <[email-masked]>
Date: Wed, 21 Sep 2016 10:01:23 -0400

> .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?

> 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.

> /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.)

---

From: Tony Baldwin <[email-masked]>
Date: Wed, 21 Sep 2016 10:49:13 -0400

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

it seems that I am using lightdm.
> 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).
> 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.

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

---

From: Greg Wooledge <[email-masked]>
Date: Wed, 21 Sep 2016 11:05:51 -0400

> 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
...

---

From: Anthony Baldwin <[email-masked]>
Date: Wed, 21 Sep 2016 15:07:09 -0400

> (For example, https://wiki.debian.org/LightDM has zero instances of

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

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

---

From: Seeker <[email-masked]>
Date: Thu, 22 Sep 2016 09:16:39 -0700

> 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

---

From: David Wright <[email-masked]>
Date: Wed, 21 Sep 2016 21:19:11 -0500

> >(For example, https://wiki.debian.org/LightDM has zero instances of

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 ?

> 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.

---

From: Greg Wooledge <[email-masked]>
Date: Thu, 22 Sep 2016 09:11:53 -0400

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.

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,

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?

---

From: Brian <[email-masked]>
Date: Thu, 22 Sep 2016 20:41:50 +0100

> 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).

-- 
Brian.

---

From: Brian <[email-masked]>
Date: Thu, 22 Sep 2016 20:05:17 +0100

> 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

 > Wouldn't that be like a user configuring /etc/issue, the login prompt

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.

---

From: Tixy <[email-masked]>
Date: Thu, 22 Sep 2016 15:15:40 +0100

On Thu, 2016-09-22 at 09:11 -0400, Greg Wooledge wrote:
> 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

---

From: Tony Baldwin <[email-masked]>
Date: Thu, 22 Sep 2016 11:25:33 -0400

>         if [ -d "$HOME/bin" ] ; then

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

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

---

From: Seeker <[email-masked]>
Date: Thu, 22 Sep 2016 09:00:11 -0700

> scripts. such as this one, which I fire off qwith the print screen key:

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

---

From: Greg Wooledge <[email-masked]>
Date: Thu, 22 Sep 2016 12:10:35 -0400

> 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.)

---

From: Brian <[email-masked]>
Date: Thu, 22 Sep 2016 18:45:50 +0100

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

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). 

> Arch's customizations are different and don't appear to be the same

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.
 
> 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.

---

From: Seeker <[email-masked]>
Date: Thu, 22 Sep 2016 18:18:08 -0700

> 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

---

From: Seeker <[email-masked]>
Date: Fri, 23 Sep 2016 10:07:43 -0700

> Will have to look at lxde and kde to see if it is a desktop thing or
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

---

From: Brian <[email-masked]>
Date: Fri, 23 Sep 2016 18:28:12 +0100

On Fri 23 Sep 2016 at 10:07:43 -0700, Seeker wrote:

> 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

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?
 
> session or will we have to start putting things into

Pass.

-- 
Brian.

---

From: Seeker <[email-masked]>
Date: Fri, 23 Sep 2016 23:33:19 -0700

>> On 9/22/2016 6:18 PM, Seeker wrote:

<Snip>

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

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.

> 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.

>> session or will we have to start putting things into

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

---

From: Greg Wooledge <[email-masked]>
Date: Thu, 22 Sep 2016 10:56:49 -0400

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

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

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.

---

From: Tixy <[email-masked]>
Date: Thu, 22 Sep 2016 19:53:13 +0100

On Thu, 2016-09-22 at 10:56 -0400, Greg Wooledge wrote:
> [...] how did you learn about it?

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

-- 
Tixy

---

From: Brian <[email-masked]>
Date: Thu, 22 Sep 2016 16:54:11 +0100

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

> 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

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

-- 
Brian.

---

From: Darac Marjal <[email-masked]>
Date: Thu, 22 Sep 2016 16:10:01 +0100

>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

-- 
For more information, please reread.

---

From: Greg Wooledge <[email-masked]>
Date: Thu, 22 Sep 2016 16:19:26 -0400

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.

---

From: Brian <[email-masked]>
Date: Fri, 23 Sep 2016 17:36:11 +0100

> what I wanted to see.  I will be able to point users to this page in

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.

---

From: Brian <[email-masked]>
Date: Sat, 24 Sep 2016 20:38:50 +0100

> ~/.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.

---

From: Dominic Knight <[email-masked]>
Date: Fri, 23 Sep 2016 00:09:58 +0100

> Thanks to all who provided information.

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

---

From: Curt <[email-masked]>
Date: Fri, 23 Sep 2016 08:57:18 +0000 (UTC)

> was/is read by .Xsession. Unsure whether it is still used and/or

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

---

From: Brian <[email-masked]>
Date: Thu, 22 Sep 2016 17:32:16 +0100

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

> 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.

---

From: Brian <[email-masked]>
Date: Thu, 22 Sep 2016 14:50:30 +0100

> 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.

---

From: Greg Wooledge <[email-masked]>
Date: Thu, 22 Sep 2016 09:59:07 -0400

> 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.

---

From: Ric Moore <[email-masked]>
Date: Thu, 22 Sep 2016 12:26:09 -0400

> a DM works, or what happens after it has accepted and verified a password.

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

---

From: Brian <[email-masked]>
Date: Thu, 22 Sep 2016 15:29:19 +0100

> On Thu, Sep 22, 2016 at 02:50:30PM +0100, Brian wrote:

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

> $ 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.
 
> 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.

> 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.

---

From: Darac Marjal <[email-masked]>
Date: Wed, 21 Sep 2016 15:00:53 +0100

On Wed, Sep 21, 2016 at 09:43:15AM -0400, Tony Baldwin wrote:
>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
>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?

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.

---

From: "Thomas Schmitt" <[email-masked]>
Date: Wed, 21 Sep 2016 15:54:30 +0200

Hi,

Tony Baldwin wrote:
> .config/openbox/rc.xml

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