Dmenu Processes Forked by Bash?

Question

I was looking at the output of pstree, and realised that processes that I started using dmenu seem to fork from bash.

What is the reasoning behind this? And is there any way I can make dmenu behave like gmrun and other application launchers and only launch the process?

EDIT: The dmenu manpage says that the shell execution behavior is correct for dmenu_run. Figuring out how to not make the shell persist after launching the program is what I am still looking for.

score 2 · Answer 1 · answered Jun 26 '13 at 08:29

I assume you're looking at dmenu_run. The list of applications is populated by using the shell, and is passed back to it in determining what to run -- dmenu doesn't launch anything, it just passes back what you selected to whatever is listening, and that acts upon it. The shell is doing the heavy lifting, which is why it is required.

score 1 · Answer 2 · answered Jun 26 '13 at 08:36

1

dmenu doesn't start processes, it just prints the selected item to stdout. It's up to something else - probably your window manager - to actually execute the program you selected.

You will need to provide more information on what is calling dmenu for anyone to help further.

answered Jun 26 '13 at 08:36

David Baggerman

2,154
20
11

Both DWM's Alt+Enter and launching dmenu_run from `urxvt` or `gmrun` will cause bash to be a parent process of whatever is started by `dmenu`. Hopefully this is what you were asking about. Is there any way to, for example, prepend `exec` to all commands launched by dmenu so that `bash` is no a parent afterward? – Jun 27 '13 at 06:31
My version of `dmenu_run` (4.0 +xft patch) doesn't show the same behavior. Bypassing `dmenu_run` and running `exec $(dmenu_path | dmenu)` may be a quick fix. If you have an older version, updating might be another fix. – David Baggerman Jun 27 '13 at 07:49
I am using the Arch Linux package of dmenu-4.5, so it isn't a problem of an old package. I'll try installing `dmenu` from source and see if anything changes. – Jun 27 '13 at 08:31
There wasn't any real way to configure the installation from source code, so I'm at a loss as to why behavior is different than yours. – Jun 27 '13 at 08:48
I'm using the `dmenu-xft` [AUR package](https://aur.archlinux.org/packages/dmenu-xft/). Just updated to 4.5-1, and still can't reproduce the behavior. – David Baggerman Jun 27 '13 at 09:08

score 1 · Accepted Answer · answered Aug 10 '13 at 14:58

I ended up asking about it on the ArchLinux forum after a little while.

Here is what /usr/bin/dmenu_run should look like:

#!/bin/sh
cachedir=${XDG_CACHE_HOME:-"$HOME/.cache"}
if [ -d "$cachedir" ]; then
    cache=$cachedir/dmenu_run
else
    cache=$HOME/.dmenu_cache # if no xdg dir, fall back to dotfile in ~
fi
exec $(
    IFS=:
    if stest -dqr -n "$cache" $PATH; then
        stest -flx $PATH | sort -u | tee "$cache" | dmenu "$@"
    else
        dmenu "$@" < "$cache"
    fi
)

That still kept `dmenu_run` as a parent process. What I did was to replace `exec` with `app=`. And after that do a `exec $app &; disown %1` which detaches the application, so it has no other parent than the system. — mhitza, Sep 22 '13 at 00:35

Dmenu Processes Forked by Bash?

3 Answers3