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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

[Neal P. Murphy]

On Mon, 26 Sep 2016 22:19:27 +0100
Brian  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).

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

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

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

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

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

[Brian]

On Sat 24 Sep 2016 at 20:38:50 +0100, Brian wrote:

> On Fri 23 Sep 2016 at 17:36:11 +0100, Brian wrote:
> 
> I don't think I shall be pointing a user to this wiki page in its
> present state.

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

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

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

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

[Brian]

On Thu 22 Sep 2016 at 16:19:26 -0400, Greg Wooledge wrote:

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

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.

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

[tomas]

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

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

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Sep 23, 2016 at 08:57:18AM +, 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-

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

[Curt]

On 2016-09-22, Dominic Knight  wrote:
> On Thu, 2016-09-22 at 16:19 -0400, Greg Wooledge wrote:
>> 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.
>
> 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?

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

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

[Dominic Knight]

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

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

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

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

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

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

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

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

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

[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

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

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

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

[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=names=stable=all

Later Seeker

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

[Ric Moore]

On 09/22/2016 09:59 AM, 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.

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


Suppose all you get is a black screen and a mouse pointer??  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

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

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

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

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



--
For more information, please reread.


signature.asc
Description: PGP signature

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

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

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

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

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

[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

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

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

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

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

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

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Sep 22, 2016 at 09:11:53AM -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:
> 
> 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 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 
  
  # 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-

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

[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 

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

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

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

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




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

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

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

Re: 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]

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



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

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

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

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

[Darac Marjal]

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

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


 
   
 true
 bid
   
   bid
 
   


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


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.


signature.asc
Description: PGP signature