off-topic question: Apple open command and/or apps in /Applications are half-broken now
Kenneth Wolcott
kennethwolcott at gmail.com
Sat Apr 15 23:14:23 UTC 2023
Hi Richard;
Thank you so much for your very helpful assistance. Between what
your wrote and the article you referred me to, I did the following
command, which seemed to work for Preview and Reader apps, but not
Highlight (another pdf app), I'm not sure why. I will continue to
experiment and apply.
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
-kill -r -v -apps u
I'll try to apply your suggestions on how to refer to applications using open.
Thanks,
Ken
On Sat, Apr 15, 2023 at 2:12 PM Richard L. Hamilton <rlhamil at smart.net> wrote:
>
>
>
> On Apr 15, 2023, at 15:57, Kenneth Wolcott <kennethwolcott at gmail.com> wrote:
>
> Hi;
>
> off-topic question: Apple open command and/or apps in /Applications
> are half-broken now
>
> I'm asking the question here because I think that there are lots of
> people who might know either the answer to my question and/or can help
> me find the answer by describing my problem more accurately/precisely.
>
> I don't think anything MacPorts did to my Mac via a port
> installation caused this problem.
>
> The problem:
>
> example problem:
>
> /usr/bin/open -F -a /Applications/Reader.app/Contents/MacOS/Reader some_file.pdf
>
>
> The usual way is NOT to give the binary to "open", but the app name (without path or .app suffix if there's only one match among the places apps are searched for, but you might need the suffix if you give a full path, and if there's spaces or other problematic characters in the name, you need to quote the app name or full path of the app bundle), like this:
>
> /usr/bin/open -F -a Reader
> or
> /usr/bin/open -F -a /Applications/Reader.app
>
> Whatever library call "open" uses knows about the structure of app bundles and how to find the binary and how to invoke it correctly.
>
> Have you tried rebuilding the launch services database? Sometimes it gets screwed up, which causes problems launching applications correctly. Google for that phrase, or here's one reasonably good description:
> https://eclecticlight.co/2017/08/11/launch-services-database-problems-correcting-and-rebuilding/
>
> Note that the details may depend on your OS version; I don't have handy nor can quickly find a list of OS versions and the exact command(s) for each one, but you should be able to figure it out. I do have two versions in scripts, the older one
>
> sudo /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain system -domain user
>
> and the newer one
>
> /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user
>
> The longer path is the real one, but at least on non-ancient macOS versions there's a symlink, so either will work. I don't recall whether the sudo was necessary more recently, either (maybe never, I don't know).
>
> I don't think lsregister does the work itself, but it communicates what to do to another process (one or more of the instances of lsd? of which there's one as root, one for the logged in user, and maybe others left over for other user ids that have used launch services). That implies that the reset of the per user data only applies to the current user.
>
> There's no man page, but running the lsregister command without arguments gives a usage message. On Monterey,
>
> sh-3.2$ /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
> lsregister: [OPTIONS] [ <path>... ]
> [ -apps <domain>[,domain]... ]
> [ -libs <domain>[,domain]... ]
> [ -all <domain>[,domain]... ]
>
> Paths are searched for applications to register with the Launch Service database.
> Valid domains are "system", "local", "network" and "user". Domains can also
> be specified using only the first letter.
>
> -delete Delete the Launch Services database file. You must then reboot!
> -kill Reset the Launch Services database before doing anything else
> -seed If database isn't seeded, scan default locations for applications and libraries to register
> -lint Print information about plist errors while registering bundles
> -lazy n Sleep for n seconds before registering/scanning
> -r Recursive directory scan, do not recurse into packages or invisible directories
> -R Recursive directory scan, descending into packages and invisible directories
> -f force-update registration even if mod date is unchanged
> -u unregister instead of register
> -v Display progress information
> -gc Garbage collect old data and compact the database
> -dump [table] Display full database contents after registration
> -h Display this help
>
> With -dump you can get a dump of the database in textual form; it's huge and may be tricky to parse, but if you're geeky enough it might be interesting. You can dig out the version of a particular app, for instance.
>
More information about the macports-users
mailing list