Soap (xdg-open replacement)

I’ve had a fork of soap for quite a while now and have made some nice additions to it, to the point where I feel it’s time let others see if they want to use it.

Getting it working is easy as copying the config.def.h to config.h, edit it to open applications you want, then run sudo make install

It replaces xdg-open (many applications have this hardcoded) so you should still have it installed, it will copy the original to a fallback and use it when there are no rules defined for the filetype.
EDIT: See below for recent changes to replacing /usr/bin/xdg-open, it’s now handled better.

Any questions or issues please let me know.


Thanks for the share man.

How does it work, would it take over xdg entirely? I mean for example for a file type that I don’t have listed on Soap but is still set on xdg, will it open as before? Do I need to comment out the “catch-all default”?

Perhaps install soap to /usr/local/bin/xdg-open so that /usr/bin/xdg-open doesn’t have to be re-named? The re-naming would be reverted whenever xdg-open is updated.

I totally agree and have tried to do just this in the past but ran into problems.

Here’s what I tried

  • Remove any changes from default xdg-open and reinstall it

  • Install soap as /usr/local/bin/xdg-open

  • echo $PATH yields /home/nate/bin:/home/nate/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl so I know the local bin is higher in the path than bin

after which xdg-open still gives /usr/bin/xdg-open.

It’s easy enough to edit the makefile for individuals. In the last year or so of using it I haven’t had any issues with xdg-utils being updated as I don’t think it changes much. I did write a few pacman hooks to do the swapping on update/install if anyone is interested?

1 Like

Yes it moves /usr/bin/xdg-open to /usr/bin/xdg-open_ and replaces it.

You would need to comment the “catch all” for it to fallback on the actual xdg-open, otherwise that regex will always match something and run. This is a bit of a failing point tbh, I don’t do filetype checking so any files without extensions or structured naming (web pages and other URIs) will not match and get handled by xdg-open without the catch all.

I really just wanted an easy way to launch terminal programs as defaults for some applications that rely on xdg-open. A good example is steam when browsing local files of an installed game, I just want it to open a terminal with my file manager but since I haven’t been able to get .desktop files to work this was a good solution.

Perhaps in the future I’ll look into filetype detection and “improve” it further but for now I’ve really enjoyed how simple and easy it is to get things opened how I want.

1 Like

I don’t really need the filetype checking, just wanted to know how it works, if I remove the chatchall and it continues to rely on xdg-open that works for me. I love the simplicity and will deffinetly use it. Thank you for sharing!

Was /usr/local/bin/xdg-open marked executable?

From my Arch system:

empty@archie:~ $ doas tee /usr/local/bin/xdg-open >/dev/null <<!
> #!/bin/sh
> echo hello
> !
empty@archie:~ $ doas chmod +x /usr/local/bin/xdg-open                                   
empty@archie:~ $ which -a xdg-open
empty@archie:~ $ xdg-open
empty@archie:~ $

@Head_on_a_Stick Yea it was executable. I think I’m just dumb I was using an old shell to run which and it still gives the old path, reloading or running in a new shell solves that and it’s as expected.

I’ve pushed an update, anyone using the old version should do a sudo make uninstall before pulling or you’ll be left with all the changes to /usr/bin.

My new approach is as HoaS suggested and using /usr/local/bin, the executable is no longer renamed to xdg-open to avoid confusion and allow calling it directly. A symlink is created at /usr/local/bin/xdg-open and points to /usr/local/bin/soap. When falling back to xdg-open it uses the full path /usr/bin/xdg-open to avoid ambiguity.