4

Sometimes I xdg-open somefile.ext from a terminal session, but then I want to be able to close the application or viewer that opened, later on. I was hoping there might be something like an xdg-close, which examines the existing windows to see which of them reports having somefile.ext open, and close/kill that application.

Does something like this exist under a different name?

  • 1
    No, there is no such thing. If you think about it for a few minutes, it wouldn't make sense to have such an utility. – Satō Katsura Oct 4 '17 at 10:55
  • kill $(psof xdg-open) ? – djsmiley2k Oct 4 '17 at 11:11
  • 1
    @SatōKatsura: I thought about it for more than a few minutes, and it still make sense. Perhaps you could elaborate. – einpoklum Oct 4 '17 at 11:20
  • 1
    You want xdg-close somefile.ext to kill the app that xdg-open would use to open somefile.ext, right? Assume that app is running, but it wasn't started by xdg-open. You probably don't want to kill it in that case, so you need xdg-open to keep states about what it runs. And since UNIX is a multi-tasking environment, that state would need locking. And since you want it fast, it has to be a database. And since you won't run xdg-close every time, you need some cron job to clean up old entries. Then all xdg-<mumble> need to use it as well, or you'd get conflicting behaviour. – Satō Katsura Oct 5 '17 at 4:22
  • 1
    (cont.) I'm not even addressing any permission issues, or issues related to killing apps without the proper cleanup. Congratulations: you have just re-invented Windows registry, only without the advantages. :) – Satō Katsura Oct 5 '17 at 4:25
2

Assuming that the file you opened isn't deleted, the following will forcibly close all applications that have it open:

fuser -k -TERM FILE

Replace FILE with the name of the file in question.

Note that this is potentially very dangerous if you are not careful. If you accidentally pass in your home directory for example, it will terminate all current login sessions you have on the system (both graphical and textual), as well as killing most of your background processes.

Assuming you know which application opened the file, there are other somewhat safer desktop environment specific methods to do this, but I don't know enough about them to give you good advice here.

Now, as to why there is no xdg-close command:

xdg-open exists so that tools like file managers or web-browsers can make sure the user's preferred application gets invoked when they try to open a given file. In other words, it originated so that you don't have to go through every application on your system when you want to change what is used to open a file, but can instead set defaults in one place, and the applications don't have to care what desktop environment you're using when they want to open something in another application. It can be called from the command-line by hand, but that's not really what it's designed for.

Automating closing applications that opened a specific file is not exactly something that's all that user friendly. Your web browser has no business closing the PDF viewer you opened to view the PDF you downloaded, so why does it need a tool that lets it do so? Additionally though, your desktop environment doesn't track what applications have what files open (the OS tracks it as what processes (which do not map 1:1 to applications) have what files open), so there's not really any easy way to implement this either.

For what it's worth, the only reason xdg-open exists as a command at all is because it originated before DBus became part of the FreeDesktop.org specification, otherwise it would almost certainly be a DBus API call provided by yet another unnecessary background process.

  • Well, that's useful if the application is keeping the file open; but many viewers/players don't (e.g. PDF files, audio files, images). +1 for this though. – einpoklum Oct 4 '17 at 15:40
  • Also - I need this for scenarios in which I alter a file and then want to launch a viewer for the new version. In some cases I would like the existing viewer to shut down so as not to have two of them and/or not to have the viewer try to track the changes as they occur. – einpoklum Oct 4 '17 at 15:42
  • @einpoklum Depending on the particular viewer software, there may be an option to automatically refresh when the file is updated (although it's often buried pretty deep when it does exist). It may be simplest though to just write a wrapper for the viewer yourself instead of using xdg-open. Most big desktop applications have a DBus API these days that you can poke at to do stuff like this. – Austin Hemmelgarn Oct 4 '17 at 15:45

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.