Exec parsing issues/Wrong shell being used about j4-dmenu-desktop HOT 4 CLOSED

This should be fixed in develop now. I am planning to make a r3.0 release in the foreseeable future which would include the fix.

from j4-dmenu-desktop.

Thanks for your feedback!

Are you using version r2.18 or HEAD? If you are using HEAD, I'd like to warn you that it's pretty unstable¹ at the moment. I am working on a pretty massive update coming soon.

Maybe it would be better to only use /bin/sh? It looks like the XDG desktop standard does not specify any kind of shell to be used, it seems like the intention is to execute programs directly.

It doesn't specify it, but it is pretty clear that the standard has been designed with a shell execution in mind when you "read between the lines". The standard specifies escaping things that do not have any special meaning in desktop files, but are oddly similar to characters which have a special meaning in the shell. I have spoken with people on the XDG mailing list about a year ago and we agreed that this implementation is valid. There's nothing stopping j4dd from doing word-splitting, unquoting and unescaping itself, but this is the simpler implementation.

However, if any kind of shell is invoked, I'd say it's better to be conservative and only invoke /bin/sh.

Thanks for catching this bug. I use $SHELL often (instead of /bin/sh) because the user might want to use some complex commands that might be shell specific. To quote from the README:

I want it to display normal binaries, too, yes?

You can put this in a script file and use it instead of calling j4dd directly:

j4-dmenu-desktop --dmenu="(cat ; (stest -flx $(echo $PATH | tr : ' ') | sort -u)) | dmenu"

Exchanging the cat and (stest ... sort -u) parts will swap the two parts (j4dd's output and the list of binaries).

This shows some rather exotic usage of the --dmenu flag. There's also a (I believe) little known and poorly documented feature in j4dd that could be influenced by this. When you type a response to the dmenu prompt which doesn't correspond to a desktop file, j4dd treats it as a "raw" command and tries to execute it. People could therefore be using some advanced shell specific things in this prompt and expect it to work. But it wouldn't surprise me if only I and enkore know this thing exists (and a sane person would use a terminal instead of doing this in j4dd), so breaking it shouldn't cause harm.

These "raw" commands and desktop files lead to the same execution path, so $SHELL is used for both. This behavior is incorrect for desktop files as you have discovered (and it wouldn't hurt changing the "raw" command shell to /bin/sh too).

from j4-dmenu-desktop.

Are you using version r2.18 or HEAD?

I'm using 2.18 from the Arch Linux repos.

When you type a response to the dmenu prompt which doesn't correspond to a desktop file, j4dd treats it as a "raw" command and tries to execute it. People could therefore be using some advanced shell specific things in this prompt and expect it to work.

That is interesting. Can't speak for others, but personally I use j4-dmenu-desktop for applications that I want to "just work" out-of-the-box, so I don't need the shell syntax. Like many dmenu users, I do write my own scripts, but then I also script dmenu usage myself, too. I never thought about mixing it in alongisde .desktop applications, to me personally that sounds messy.

j4-dmenu-desktop --dmenu="(cat ; (stest -flx $(echo $PATH | tr : ' ') | sort -u)) | dmenu"

I guess technically this could still be achieved by doing --no-exec, and then wrapping the whole thing in sh -c "$(...)". That's also messy, but now the mess is more explicit. :D

from j4-dmenu-desktop.

Here is an example of this behavior:

User input is using arrays, a non-POSIX feature which isn't supported by dash. This is partly the reason the user specified shell is used in a lot of places (although this isn't really a "feature", it's more of a weird side effect; breaking this by using /bin/sh shouldn't do much harm).

from j4-dmenu-desktop.