I3 keybinding for appimage not working

I’m on i3. I downloaded an appimage and managed it with Appimage Launcher to create a .desktop file.
Rofi launches the app normally, but I can’t launch it via a keybind. Namely, this won’t work:

bindsym $mod+o exec pgrep obsidian && i3-msg '[class="obsidian"]' || obsidian

nor this:

bindsym $mod+o obsidian

The class name is correct.
The .desktop file is:
and I have that directory in my $PATH.
Any ideas?

obsidian will never launch because pgrep obsidian && i3-msg will always exit with success status. I understand that you don’t want the keybinding to launch obsidian if there is already an instance of obsidian running, but that’s not the right way to do it. pgrep will not exit with a non-zero exit code even though it fails to find any process that matches your criteria. Similarly, even though [class=“obsidian”] doesn’t do anything in this case, the call made to i3-msg will still return successfully (it will return an empty list).

What you need to do instead is to just write a shell-script, launch-obsidian.sh

pid="$(pgrep obsidian)"
if [ -z "$pid" ]
     obsidian &      

Then, in your i3 config:

bindsym $mod+o exec  ~/path/to/launch-obsidian.sh

Extra info:

That’s not how you use a command criteria. What is it that you’re asking i3 to execute? Specifying a command criteria without giving it a command does nothing.

Generally, command criterias work like this:

[class=obsidian] some_i3_command

Using i3-msg:

i3-msg '[class="obsidian"] some_i3_command'

Also, do consider using command chaining. If you want a keybinding to execute a chain of command (Command_A, Command_B, Command_C), you can do it like this:

bindsym $mod+o Command_A ; Command_B ; Command_C

If you want a command criteria to apply to a multiple commands, use a comma instead

bindsym $mod+o [class="obsidian"] Command_A ; Command_B

Command_A only applies to windows of class “obsidian”

bindsym $mod+o [class="obsidian"] Command_A, Command_B

Both Command_A and Command_B applies to windows of class “obsidian”


I made a typo here.

Should be

bindsym $mod+o exec ~/path/to/launch-obsidian.sh

Edited in the original post.

Thanks @anthony93, I understand the pgrep issue now. But Obsidian still would not launch, there’s something else going on.

Current situation:

bindsym $mod+o exec ~/scripts/launch-obsidian.sh

launch-obsidian.sh script:

pid="$(pgrep obsidian)"
if [ -z "$pid" ]
     obsidian &      

The above script is not working for Obsidian, it works for any other app, the only difference is that Obsidian in this case is an appimage (Rofi launches it normally, though, which means that the .desktop file is not the issue here, right?).

First of all, find out whether there is an executable file called obsidian in your path. If there is no such executable, then you have to find out the exact path of the executable to launch obsidian. After you do that, change the script to:

pid="$(pgrep obsidian)"
if [ -z "$pid" ]
     /path/to/your/obsidian/exec &      

Also, make sure you have made the shell script executable.

chmod +x ~/scripts/launch-obsidian.sh

Since you could launch it via rofi, I’m assuming that you already have a .desktop file. The path to the executable can be found inside the .desktop file.

I’ve never used AppImages before, but I’m fairly certain that there is a way to make executables out of AppImages. The script just needs a valid executable to work.

Will this article help?


The desktop file should be fine. Can you open the desktop file and check the Exec entry? That should tell you which executable is used.

Hopefully, this helps. I currently have the following for launching FreeTube

bindsym $mod+Y exec --no-startup-id $HOME/Appz/freetube_0.18.0_amd64.AppImage

Maybe try a similar string to see if that works.

I uninstalled appimagelauncher, trashed the Obsidian appimage & .desktop, downloaded a fresh appimage, created manually a .desktop (for Rofi) and specified a keybinding using the full appimage path (class name only wouldn’t work):

bindsym $mod+o exec ~/appimages/Obsidian-1.3.7.AppImage

So in the end appimagelauncher was interfering somehow by renaming things its own way I guess (?).

Yes, it does rename things. And I just realised that because I am on i3, like you, I don’t actually use AppImage Launcher as much. So, my filenames don’t get changed anymore.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.