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.

  • 1
    What web browser are you using? Jul 30, 2014 at 18:46
  • If the browser is already open, there shouldn't be any blocking. At least for Firefox on Ubuntu (GNOME). Conversely, if Firefox is not running, it does block (until Firefox is exited/closed). Oct 9, 2022 at 20:20

8 Answers 8


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? May 7, 2013 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, 2013 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. May 7, 2013 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, 2013 at 20:23
  • It works out of the box on Fedora 20 too. Jul 30, 2014 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.

  • 4
    Alas, detach does not seem to exist in my distro. nohup launches the process, but still occupies the terminal window. May 7, 2013 at 19:25
  • 1
    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, 2017 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, 2018 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, 2016 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. Mar 16, 2016 at 10:10
  • 2
    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? Feb 24, 2017 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. Feb 24, 2017 at 13:07
  • @Gilles I think you misunderstood Charl Botha. Your answer states "xdg-open waits for the program to finish. This is by design.". But then your comment says "xdg-open returns immediately"... which are contradictory. Jul 19, 2019 at 22:29

By combining terdon's answer and Dan D.'s discussion of nohup I created a function which does exactly what I want:

  1. Opens the file in the chosen app without any writing to the terminal at all.
  2. Detaches the process so the terminal window can be closed.
  3. Doesn't write any errors the app produces to the terminal.

I added this to my .bashrc/.zshrc file:

function open () {
  nohup xdg-open "$*" > /dev/null 2>&1

For an explanantion of /dev/null 2>&1 see this discussion about hiding stdout and stderr.


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. May 7, 2013 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, 2013 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, 2013 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, 2013 at 19:52
  • thanks for the clarification. I've reviewed the answers and I understand this better now. The browser is iceweasal. May 7, 2013 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? May 13, 2019 at 6:09
  • disown doesn't prevent errors being sent to the terminal.
    – LondonRob
    Jun 11, 2019 at 10:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .