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 <ad44@cityscape.co.uk>]

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.