20

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.

Nick Tomlin
  • 442
  • 1
  • 4
  • 10
  • 1
    What web browser are you using? – Cristian Ciupitu Jul 30 '14 at 18:46
  • If the browser is ***already open***, there shouldn't be any blocking. At least for Firefox on [Ubuntu](https://en.wikipedia.org/wiki/Ubuntu_version_history#Ubuntu_18.04_LTS_.28Bionic_Beaver.29) ([GNOME](https://en.wikipedia.org/wiki/GNOME)). Conversely, if Firefox is not running, it does block (until Firefox is exited/closed). – Peter Mortensen Oct 09 '22 at 20:20

8 Answers8

20

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.

terdon
  • 234,489
  • 66
  • 447
  • 667
  • 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 &`` without using a shell function? – Nick Tomlin May 07 '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 07 '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 07 '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 07 '13 at 20:23
  • It works out of the box on Fedora 20 too. – Cristian Ciupitu Jul 30 '14 at 18:47
  • Is there some reason for this to be `"$*"`?   Normally I would expect `"$@"`.   Now it looks like (today’s incarnation of) `xdg-open` takes only one parameter, but then why not use `"$1"`?   But, of course, both `"$*"` and `"$1"` will pass an empty argument to the program if the function is invoked with no args.   It really seems like this should use `"$@"`. – G-Man Says 'Reinstate Monica' May 13 '19 at 06:16
10

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.

Dan D.
  • 583
  • 1
  • 5
  • 14
  • 4
    Alas, ``detach`` does not seem to exist in my distro. ``nohup`` launches the process, but still occupies the terminal window. – Nick Tomlin May 07 '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
4

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.

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
  • 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 04: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 'SO- stop being evil' Mar 16 '16 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? – 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 'SO- stop being evil' Feb 24 '17 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. – cheshirekow Jul 19 '19 at 22:29
2

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.

LondonRob
  • 279
  • 4
  • 15
0

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.

polym
  • 10,672
  • 9
  • 41
  • 65
Valia Walsk
  • 1
  • 1
0

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.

m3nda
  • 168
  • 1
  • 7
0

disown is the right command for this.

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

f_x()
{
   xdg-open "$1" &
   disown
}

x()
{
   f_x "$*" > /dev/null 2>&1
}
user352672
  • 1
0

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.

slm
  • 363,520
  • 117
  • 767
  • 871
  • This still keeps the process running in the current terminal window. Let me know if I need to clarify my question. – Nick Tomlin May 07 '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 07 '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 07 '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 07 '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 07 '13 at 19:55
  • Yeah that's essentially Firefox so just backgrounding the xdg-open should do the job. Is that not working as you expected? Also did you get your question resolved about "not doing this w/o using a shell function?" Wasn't sure entirely what you meant by that comment. – slm May 07 '13 at 19:59