I'm starting to experiment with Crunchbang (which is based on Debian, and uses terminator) as a web development environment, and one of the things I am struggling with is the behaviour of xdg-open. I come from an OSX background, so forgive me if this question comes off as dense.

I would like to be able to open a url with xdg-open http://www.google.com and then continue to use the same terminal window to work (it's how open functions in OSX). Right now, using xdg-open occupies the current tab/session until I close browser window, or manually end things with ctrl + c. I'd much prefer it start a new process, that way I can open up a URL, refer to data on the page, and use it in the same tab/window without needing to open an additional one.


Strange, it works like that out of the box on my Debian. Try running it in the background:

xdg-open http://www.google.com &

You can make this into a function by adding these lines to your ~/.bashrc file:

function open () {
    xdg-open "$*" &

You can then simply run open http://www.google.com and it will run in the background.

  • 1
    This works great. I was hoping to have a simple alias to to open, (i.e. open='xdg-open') is there a way to get the functionality of xdg-open <url> & without using a shell function? – Nick Tomlin May 7 '13 at 19:27
  • @NickTomlin Not as far as I know, no, but what have you got against functions? As you can see in my updated answer it is almost as simple as an alias. – terdon May 7 '13 at 20:07
  • Not a particular bias, I was hoping to avoid a function since I am trying to use (and reuse) the same alias for both Mac OS and *nix flavors. – Nick Tomlin May 7 '13 at 20:20
  • No reason why you couldn't. Functions depend on the shell, as long as you use bash in all systems in question it should work perfectly well. – terdon May 7 '13 at 20:23
  • It works out of the box on Fedora 20 too. – Cristian Ciupitu Jul 30 '14 at 18:47

If you want to detach the process from the current shell rather than starting it as a background job with xdg-open http://www.google.com &, I like the detach utility:

detach xdg-open http://www.google.com

One could create an alias for this. I like detach over nohup as closes stdin stdout and stderr by default so its invocation is cleaner.

  • 3
    Alas, detach does not seem to exist in my distro. nohup launches the process, but still occupies the terminal window. – Nick Tomlin May 7 '13 at 19:25
  • detach is not in my distro either; but python can handle opening URLs and detaching: python -m webbrowser -t "http://example.com". This should work out-of-the box on almost all somewhat-recent distros of linux. – Krets Jul 10 '17 at 11:21
  • Although detach is not even in the AUR, it proved easy to install from source and furthermore was the only program that achieved what I wanted. (the alternatives listed here and on the detach website don't allow closing the shell as long as xdg-open is running, or at least detach did not make my shell complain one bit) – rien333 Aug 13 '18 at 13:40

xdg-open waits for the program to finish. This is by design. If the program is a text mode program, it has to stay in the foreground in the terminal. Even if the program is a GUI one, this behavior is useful in case xdg-open is used from a script and the script wants to perform something after the file has been edited (e.g. send the new version somewhere or otherwise make something with the new version).

If you don't want to wait, run xdg-open in the background. You can run any shell command in the background by putting an ampersand at the end.

xdg-open http://www.google.com &

With some programs, xdg-open returns immediately. What happens is actually that the program that xdg-open invokes returns immediately. This typically happens with GUI programs that open all files in a single instance: when you start them a second time, they send a message the running instance to tell it to open the file, and exit immediately.

  • how do such applications implement single instance policy? DBus is one way i know of but is there 'xdg' way of implementing this? – PnotNP Mar 16 '16 at 4:17
  • @NulledPointer Lock files, X11 window messages, D-Bus, … I suppose D-Bus is the “standard” Freedesktop way but I don't know if there is a formal specification for this. – Gilles Mar 16 '16 at 10:10
  • 1
    On my Ubuntu 16.04 system, xdg-open always returns immediately. For my current application, I would actually prefer that it blocks. Where does your "xdg-open waits for the program to finish. This is by design." information come from? – Charl Botha Feb 24 '17 at 11:10
  • @CharlBotha xdg-open returns immediately (I can confirm that on Ubuntu 16.04), but the program it invokes may move to the background. For example, on my system, xdg-open invokes Evince for PDF files; evince foo.pdf blocks until you close the PDF file, unless the PDF is already open, in which case the second evince process started by xdg-open focuses the existing instance and exits. xdg-open has no control over that, unless there's a way to make the program keep a running process. – Gilles Feb 24 '17 at 13:07

Try this:

DISPLAY=:0.0; xdg-open '<url>'

I use this technique to en-queue magnet:// URLs into my Bit Torrent client Vuze.

ssh someserver "DISPLAY=:0.0; xdg-open 'http://www.google.com/'"

The single quotes help to protect the contents of the URLs so that the shell doesn't attempt to interpret them.

  • This still keeps the process running in the current terminal window. Let me know if I need to clarify my question. – Nick Tomlin May 7 '13 at 19:29
  • Yeah, if you want it to go background immediately then just put it to the background with a ampersand "&". Isn't that @terdon's answer said to do? – slm May 7 '13 at 19:37
  • The issue here isn't xdg-open, see @Gilles answer, he explains why xdg-open is being held up, it's the GUI you're sending the URL to which is causing xdg-open to wait. – slm May 7 '13 at 19:47
  • What browser are you sending the URL to? Is there a dialog box or anything else being popped when you send the URLs w/ xdg-open? Seems like several of the answerers here have indicated that the normal behavior is that control is returned to the terminal after some period of time. – slm May 7 '13 at 19:52
  • thanks for the clarification. I've reviewed the answers and I understand this better now. The browser is iceweasal. – Nick Tomlin May 7 '13 at 19:55

If you need to open web pages from command line (loop), you can just open the browser before starting the script.

In this case it doesn't wait for browser to be closed after the first link, but opens them all in new tabs.


As today, none of those options did work for me. I am total aware that the OP said "use xdg-open", sorry in advance.

I've ended up doing a dead-simple chrome https://google.es --new-window || chromium https://google.es --new-window || firefox https://google.es.

If you don't have any of those 3 browsers, then just feel free to use the right ones with your preference of order.

Note: Firefox did open a new window without add anything. Case doesn't work seamessly for you, use firefox https://google.es -new-instance -new-window. Note that is just one - for firefox flags.


disown is the right command for this.

I use 2 functions for this, in order to keep it more readable.

   xdg-open "$1" &

   f_x "$*" > /dev/null 2>&1
  • What, you believe that a function that calls another function is easier to read and understand than a single function that’s three lines long? – G-Man May 13 at 6:09

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.