> This is a bit tangent, but does anyone know how to block an app from ever deciding to become a file handler on macOS?

The information below does not "block an app" from taking over file handler associations. It may be beneficial on its own and/or provide a starting point for further exploration.

> Every time I install Chrome on my machine (for testing purposes), macOS decides that Chrome is going to be the default file handler for a bunch of file associations, including HTML, WebP, and so on… and I have to figure out which was which for all of the mappings (which is super frustrating).

The following command can display current file extension associations for a user account:

  plutil -convert xml1 \
    ~/Library/Preferences/com.apple.LaunchServices.plist \
    -o -

In the XML output of the above should be the associations. As for determining changes, if Time Machine has been enabled, then changes to this plist can be identified.

Also regarding a Chrome OS-X/macOS installation - it installs plists for unconditional background updates. This may not be a desirable feature.

MacOS doesn't give any way to block an association from happening, I'm assuming they're using the same API's under the hood that Duti is using, and the only way you could block that from being accessed is by disabling the Launch services API.

In the next release of Infat, I'm introducing listing the openers from the plist (As you're doing now). If you record these values, then get their set defaults through infat, you could put those into your config and load from you config whenever they're overriden!

Best I got... Shameless promotion

I don't use nixpkgs personally but would love to give it a shot, check the repo in a day or two to give me some time to learn to ropes! I'll shoot you an email if I need any help :)

There is not, infat is subject to the limitations of Apple's API for setting handlers, which do not support passing in any data that an application could work with. If you wanted to, and have the time, I would recommend setting up a wrapper with https://github.com/sveinbjornt/Platypus with applescript. Then you could make an alternate for whichever mode you please and set it as an opener using infat. Clunky but functional.

No dependencies for install, just is the command runner I use to keep things organized, it's a replacement for make(1). If it hurts to download just, you can build using SPM:

swift build -c release

mv .build/PLATFORM/release/infat /usr/local/bin

just is a great command runner[1], not a shell script. Looks like it is needed if you build from source or install from Github releases. Alternatively, use `brew install philocalyst/tap/infat`(haven't done it myself but I bet it has just as a dependency anyway) [1] https://github.com/casey/just

Okay, confusing -- just tried to replicate on my machine and couldn't get that error. When you say touch, you mean creating a file with that extension, or any interaction period?

Could you please try to replicate with verbosity enabled (-v) and email me the output or file an issue at the repo with the results and full summary? It's helpful for tracking. Sorry this isn't a quick fix :(

Yep! Just added a clarification in the README.

After running `infat set IINA mov`: https://jezq5q9mfh.ufs.sh/f/Ii8qBn67qEOu1ZUKDXSn3BIE8fDuiWay...

It wouldn't be possible with the current interface, but I have a feeling it's possible. I'm thinking it's part of a new configuration option "type" that allows you to define openers for categories of files (text,video,etc.)

I can get it out in a week ;)

Have an idea of how I would do this already, give me until the end of the week. To be clear, an interface like this?

Infat list [--identifier] [--application] Where identifier and application are mutually exclusive, and application lists the openers it is capable of opening by default? Merging the application flag for simplicities sake, so either returns a list with both their possibilities *and* the assigned apps.

Thoughts?