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

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