[HN Gopher] X11 Universal File Opener and XDG Mess
___________________________________________________________________
X11 Universal File Opener and XDG Mess
Author : vermaden
Score : 39 points
Date : 2021-04-22 20:14 UTC (2 hours ago)
(HTM) web link (vermaden.wordpress.com)
(TXT) w3m dump (vermaden.wordpress.com)
| forgotmypw17 wrote:
| I'm grateful for this article, and hope I will one day figure out
| how to change my URL opener for xdg-open :)
| vermaden wrote:
| Thanks.
|
| I use BROWSER environment variable for that.
|
| It seems to even override XDG settings. %
| xdg-settings set default-web-browser firefox.sh.desktop
| xdg-settings: $BROWSER is set and can't be changed with xdg-
| settings % echo ${BROWSER} firefox
|
| Hope that helps.
|
| _EDIT:_ You also got me nice idea - to add http(s): // and
| ftp:// support for mine _see.sh_ opener :)
| stonesweep wrote:
| Each DE can have slightly different paths, but in general find
| the file mimeapps.list. It's typically looked for in the
| traditional manner of /etc/, /usr/share/ and /usr/local/share/
| and $HOME to find global, local and personal configurations. In
| your $HOME it's usually something like this:
| ~/.local/share/applications/mimeapps.list
| ~/.config/mimeapps.list
|
| In here you find the MIME type pointing at a .desktop file (app
| launcher), it's a matter of changing that. Mine for example
| related to using Firefox: [Default
| Applications] x-scheme-handler/http=firefox.desktop
| x-scheme-handler/https=firefox.desktop
|
| Find the .desktop file you want to launch and just update that
| bad boy. Most DEs have a GUI tool to manage this for you
| without having to resort to manual editing...
| flobosg wrote:
| This reminds me of Plan 9's plumber:
| https://9p.io/wiki/plan9/using_plumbing/index.html
| ttyprintk wrote:
| For a command-line relative, note that you can write a custom
| .lessfilter to decide the beginning of your paging pipeline. When
| syntax-highlighting, be sure to call less with -R.
| vermaden wrote:
| Thanks - I will check that out.
| klodolph wrote:
| I've run into too many problems with .lessfilter and I've had
| to disable it. It's hard to write one that works on anything.
| madars wrote:
| One should be careful around lesspipe -- many of the tools it
| invokes by default have less than stellar record of handling
| untrusted input. https://news.ycombinator.com/item?id=8650952
| ttyprintk wrote:
| That's a good point. I wonder if xdg-open relies on any of
| the same routines.
| anthk wrote:
| https://git.2f30.org/soap
| malkia wrote:
| Lol I was frustrated by this with my xfce4, where I could not
| setup the "Browser" options correctly (had to tweak DPI/scale
| options for chrome, and this was only doable through command-
| line). Then I've found out about "exo-open" apart from "xdg-open"
| and seems like more -
| https://twitter.com/__malkia__/status/1383898991864147974
| TD-Linux wrote:
| Is the OP's install missing a bunch of MIME entries or something?
| I can't reproduce the examples given for xdg-mime on Fedora 34,
| e.g. $ xdg-mime query filetype file.docx
| application/vnd.openxmlformats-
| officedocument.wordprocessingml.document $ xdg-mime query
| filetype file.xls application/vnd.ms-excel
| vermaden wrote:
| Fedora 34 is as bleeding edge desktop as it can be.
|
| Maybe you have more recent xdg-utils version?
|
| I run 1.1.3 here.
| TD-Linux wrote:
| I also have 1.1.3.
|
| Maybe what's missing is the libreoffice package? It seems
| like all these types are provided by
| /usr/share/mime/packages/libreoffice.xml on my system (which
| is read by update-mime-types).
|
| Arguably this is a common enough format that you shouldn't
| really need libreoffice installed to have it, though I would
| think any other office program would have it. I think
| /etc/mime.types serves as the ultimate fallback, though it
| doesn't have entries for libreoffice file extensions on my
| system.
| vermaden wrote:
| I will look into that, thanks.
| zokier wrote:
| File associations are certainly an area where I feel desktop
| systems in general have failed a bit. Both magic sniffing and and
| file extensions are very crude ways of managing the associations.
| Mime type in xattrs (or similar) is slightly better, but does
| anyone actually use that? And of course they are very platform
| specific and well hidden in general.
| jandrese wrote:
| I miss the old Mac system of explicit file type and associated
| application fields in every file metadata.
| klodolph wrote:
| The system is still there, but it's a bit vestigial.
| causality0 wrote:
| That may be true in terms of possibility but not relatively.
| Compare it to the situation on mobile, where you're lucky if
| you get any choice at all about what programs open which files.
| symlinkk wrote:
| I honestly don't see a problem with using file extensions to
| detect file type. Windows gets a lot of shit from Linux users
| for this but I don't know why.
| [deleted]
| shawnz wrote:
| I don't think storing the mime type separately is better: That
| requires every system which you might use to transfer or store
| your documents to support storing the mime type separately as
| well.
| klodolph wrote:
| This is already how HTTP works.
|
| Storing the MIME type separately is definitely a good thing.
| This isn't the _only_ way you do it. You start by checking
| the MIME type and then fall back to one of our crude
| detection mechanisms, like guessing what the file type is
| based on extension.
|
| We already store plenty of metadata with files--permissions
| and timestamps for starters. The metadata is sometimes lost
| when you transfer to another system. That's OK... you can
| repair the metadata.
|
| Given that this metadata is already present in the HTTP
| protocol, it's present in files embedded in email messages,
| and given that extended attributes are supported by many
| different filesystems, I think this solution is completely
| workable. You could make the argument that since we spend so
| much time interacting with files over HTTP, that having a
| MIME type in the metadata is actually the common way to do
| things.
| chmln wrote:
| Having lived through the same frustrations I've released
| https://github.com/chmln/handlr a year ago. It comes with lots of
| nifty scripting tools and significant improvements over xdg-open
| vermaden wrote:
| Thanks - will look into that.
| mjsir911 wrote:
| Here's my attempt at solving the same kind of problem for just
| URIs, I try to defer to .mailcap for file based auto-opening.
|
| Never had much luck with xdg-open
|
| https://github.com/mjsir911/browser
| vermaden wrote:
| I like that (browser).
|
| Will definitely dig into it to either use it directly or at
| least try to implement it in mine see.sh.
|
| Also IMHO you should add short 'youtu.be' regex handler :)
|
| Regards.
| kzrdude wrote:
| I use xdg-open (alias xo) and it works for me. If file
| associations are not right, I can set them in the file manager
| (or in the launcher I use).
| _jal wrote:
| Next time I start thinking it might be time to see if any of the
| 'desktop' guis have gotten any better, I'll reread this and save
| myself the time.
| psanford wrote:
| xdg-open is so frustrating. Its defaults are wrong and its a pain
| to reconfigure. I replaced xdg-open with this shell script that
| simply copies the url and posts a desktop notification saying it
| did so (I got the idea from a post on twitter). I'm much happier
| to make the decision on my own what to do with external file
| handlers. #!/bin/sh echo -n "$1" |
| xclip -selection primary; notify-send "URL Copied" "$1"
| elcritch wrote:
| The XDG scripts are strange. Some are really simple while some
| aren't. A while back I wanted "dropbox shortcuts" to work on
| Linux. So I copied the xdg-open examples and wrote a Nim utility
| to parse and then open the file [1]. Then it was easy to set KDE
| File browser to use the program it for dropbox shortcuts. It's
| nice having a simple language that can compile to a little static
| binary or be run as a shell script.
|
| 1: https://github.com/elcritch/open_on_dropbox
| wiredfool wrote:
| The original Mac really had something with the type and creator
| codes.
|
| Applications could register to open a type, I think it would
| default to the creator.
|
| Of course, that wound up with things like resource forks, and
| that didn't really play well with anyone else's file system.
| Someone wrote:
| Types and creator codes were stored in the file system, not in
| resource forks.
|
| What was stored in a resource fork (of each application) was
| the declaration "I am [four byte creator code]; I can open
| these [four byte file types]. That's the information that the
| Finder built its databases from (https://www.folklore.org/Story
| View.py?project=Macintosh&stor...)
|
| That easily could have been moved into the file proper (as
| AppleSingle (https://en.wikipedia.org/wiki/AppleSingle_and_Appl
| eDouble_fo...) did, but another (and IMO better for this
| purpose) option would have been to move that info into a
| special code segment in the data fork (in Unix parlor; old-
| style Mac OS programs stored their code in code segments in the
| resource fork)
|
| Also, I think Mac OS still uses
| https://en.wikipedia.org/wiki/Uniform_Type_Identifier, which
| are an improvement over file types and creator codes (you can,
| for example, express the fact that every html file is a text
| file with it)
___________________________________________________________________
(page generated 2021-04-22 23:00 UTC)