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

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

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.

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

Contents

  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 <tonybaldwin@gmx.com> - 2016-09-21 15:50 +0200
    Re: Failed to execute child process (no such file or directory) ... "Thomas Schmitt" <scdbackup@gmx.net> - 2016-09-21 16:00 +0200
    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 <wooledg@eeg.ccf.org> - 2016-09-21 16:10 +0200
      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 <tonybaldwin@gmx.com> - 2016-09-21 16:50 +0200
        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 <wooledg@eeg.ccf.org> - 2016-09-21 17:10 +0200
          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 <baldwinlinguas@gmx.com> - 2016-09-21 21:30 +0200
            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 <deblis@lionunicorn.co.uk> - 2016-09-22 04:30 +0200
              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 <wooledg@eeg.ccf.org> - 2016-09-22 15:20 +0200
                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@tuxteam.de> - 2016-09-22 15:30 +0200
                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 <wooledg@eeg.ccf.org> - 2016-09-22 16:00 +0200
                  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> - 2016-09-22 16:30 +0200
                  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 <wayward4now@gmail.com> - 2016-09-22 18:30 +0200
                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> - 2016-09-22 16:00 +0200
                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 <tixy@yxit.co.uk> - 2016-09-22 16:20 +0200
                  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 <wooledg@eeg.ccf.org> - 2016-09-22 17:00 +0200
                    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 <mailinglist@darac.org.uk> - 2016-09-22 17:20 +0200
                      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> - 2016-09-22 18:40 +0200
                      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 <wooledg@eeg.ccf.org> - 2016-09-22 22:20 +0200
                        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 <dominicknight@gmx.com> - 2016-09-23 01:30 +0200
                          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 <curty@free.fr> - 2016-09-23 11:00 +0200
                            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@tuxteam.de> - 2016-09-23 11:40 +0200
                              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@tuxteam.de - 2016-09-23 11:50 +0200
                        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> - 2016-09-23 18:40 +0200
                          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> - 2016-09-24 21:40 +0200
                            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> - 2016-09-25 20:00 +0200
                              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> - 2016-09-26 23:20 +0200
                                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 <wooledg@eeg.ccf.org> - 2016-09-26 23:50 +0200
                                  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 <seeker5528@comcast.net> - 2016-09-27 07:50 +0200
                                    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 <wooledg@eeg.ccf.org> - 2016-09-27 14:30 +0200
                                  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> - 2016-09-27 16:20 +0200
                                    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 <wooledg@eeg.ccf.org> - 2016-09-27 16:40 +0200
                                      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> - 2016-09-27 18:00 +0200
                                        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 <wooledg@eeg.ccf.org> - 2016-09-27 18:10 +0200
                                          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> - 2016-09-27 21:00 +0200
                                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" <neal.p.murphy@alum.wpi.edu> - 2016-09-27 00:00 +0200
                                  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 <wooledg@eeg.ccf.org> - 2016-09-27 14:30 +0200
                    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> - 2016-09-22 18:00 +0200
                    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 <tixy@yxit.co.uk> - 2016-09-22 21:00 +0200
                  Resolved: 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 <tonybaldwin@gmx.com> - 2016-09-22 17:30 +0200
                    Re: Resolved: 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 <seeker5528@comcast.net> - 2016-09-22 18:10 +0200
                      Re: Resolved: 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 <wooledg@eeg.ccf.org> - 2016-09-22 18:20 +0200
                        Re: Resolved: 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> - 2016-09-22 19:50 +0200
                          Re: Resolved: 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 <seeker5528@comcast.net> - 2016-09-23 03:30 +0200
                            Re: Resolved: 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 <seeker5528@comcast.net> - 2016-09-23 19:10 +0200
                              Re: Resolved: 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> - 2016-09-23 19:30 +0200
                                Re: Resolved: 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 <seeker5528@comcast.net> - 2016-09-24 08:40 +0200
                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> - 2016-09-22 21:10 +0200
                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> - 2016-09-22 21:50 +0200
            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 <seeker5528@comcast.net> - 2016-09-22 18:20 +0200
    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 <mailinglist@darac.org.uk> - 2016-09-21 16:10 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#172700 — 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.

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

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

[...]

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

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

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

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

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

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

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

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

#172701 — 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.

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

On Fri, Sep 23, 2016 at 11:31:20AM +0200, tomas@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-----

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

#172712 — 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.

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.

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

#172753 — 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.

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.

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

#172773 — 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.

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.

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

#172821 — 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.

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.

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

#172822 — 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.

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?

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

#172834 — 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.

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

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

#172848 — 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.

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.

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

#172853 — 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.

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.

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

#172854 — 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.

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.

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

#172860 — 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.

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.

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

#172862 — 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.

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.

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

#172867 — 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.

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.

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

#172824 — 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.

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

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

[Thread fork...]

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

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

#172849 — 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.

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.

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

#172655 — 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.

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.

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

#172684 — 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.

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

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

#172650 — Resolved: 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.

On 09/22/2016 10:15 AM, Tixy wrote:
> 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
>

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

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

#172656 — Re: Resolved: 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.

On 9/22/2016 8:25 AM, Tony Baldwin wrote:
> On 09/22/2016 10:15 AM, Tixy wrote:
>> 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
>>
>
> 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:
>

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

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web