1

Until now I've been using the alias to xdg-open.

alias o='xdg-open $@ 2> /dev/null'

The default behaviour for xdg-open is to start the process in the foreground of the currently selected terminal so e.g. opening files associated with vim (via xdg-mime) resulted in having the editor being opened in the terminal from which the command was entered.

The issue was that while opening terminal based programs like mutt and vim worked correctly, the e.g. .html files opened in the default browser while my terminal window became unusable because of the process running in the foreground and waiting for the file to be closed.

I have created the function below so that I could open files from the currently used terminal and still be able to work in the same window.

function o(){ xdg-open $@ 2> /dev/null & }

It fixed my problem but now opening e.g. files associated with vim results in showing me the PID and I have to enter $ fg to access the editor.

I tried to edit vim.desktop entry so that it would at least start in a new terminal but I think this is a pretty bad workaround. Could somebody give me a nudge on how to resolve this properly? Thank you in advance.

1

xdg-open is designed to run a viewer program and wait for it to complete. It's not designed to be run in the background, and as you've found out, it's not likely to work very well. You would have the same problem with the older mailcap system, which also runs programs in the foreground.

It's possible to change your shell function to always open in a new terminal, but that will likely cause you to have a large number of useless terminals. What you could do, to make your function more useful and work more like you want, is to do something like this:

o () {
    for i in "$@"
    do
        mimetype=$(xdg-mime query filetype "$i")
        prog=$(xdg-mime query default "$mimetype")
        if grep -qs Terminal=true "/usr/share/applications/$prog"
        then
            xdg-open "$i"
        else
            xdg-open "$i" >/dev/null 2>/dev/null &
        fi
    done
}

This will look to see if your program requires a terminal, and if so, will invoke it in the foreground; otherwise, it will invoke it in the background. However, this doesn't currently handle URLs or custom applications, and you'd need to edit it suitably for your system to handle that. It is, nevertheless, a starting point which you can build on.

| improve this answer | |
  • I use aliases for most of the cli applications so that's not a realy big issue for me. Honestly I was just curious of the possible solution to this problem. Your idea is very good, I'll have that in mind. Thank you. – user395656 Apr 3 at 22:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy