<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 15, 2023, at 15:57, Kenneth Wolcott <<a href="mailto:kennethwolcott@gmail.com" class="">kennethwolcott@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi;<br class=""><br class="">off-topic question: Apple open command and/or apps in /Applications<br class="">are half-broken now<br class=""><br class="">I'm asking the question here because I think that there are lots of<br class="">people who might know either the answer to my question and/or can help<br class="">me find the answer by describing my problem more accurately/precisely.<br class=""><br class=""> I don't think anything MacPorts did to my Mac via a port<br class="">installation caused this problem.<br class=""><br class=""> The problem:<br class=""><br class="">example problem:<br class=""><br class="">/usr/bin/open -F -a /Applications/Reader.app/Contents/MacOS/Reader some_file.pdf<br class=""></div></div></blockquote><br class=""></div><div>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:</div><div><br class=""></div><div>/usr/bin/open -F -a Reader</div><div>or</div><div>/usr/bin/open -F -a /Applications/Reader.app</div><div><br class=""></div><div>Whatever library call "open" uses knows about the structure of app bundles and how to find the binary and how to invoke it correctly.</div><div><br class=""></div><div>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:</div><div><a href="https://eclecticlight.co/2017/08/11/launch-services-database-problems-correcting-and-rebuilding/" class="">https://eclecticlight.co/2017/08/11/launch-services-database-problems-correcting-and-rebuilding/</a></div><div><br class=""></div><div>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</div><div><br class=""></div><div>sudo /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain system -domain user</div><div><br class=""></div><div>and the newer one</div><div><br class=""></div><div>/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user</div><div><br class=""></div><div>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).</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>There's no man page, but running the lsregister command without arguments gives a usage message. On Monterey,</div><div><br class=""></div><div><div>sh-3.2$ /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister</div><div>lsregister: [OPTIONS] [ <path>... ]</div><div> [ -apps <domain>[,domain]... ]</div><div> [ -libs <domain>[,domain]... ]</div><div> [ -all <domain>[,domain]... ]</div><div><br class=""></div><div>Paths are searched for applications to register with the Launch Service database.</div><div>Valid domains are "system", "local", "network" and "user". Domains can also</div><div>be specified using only the first letter.</div><div><br class=""></div><div> -delete Delete the Launch Services database file. You must then reboot!</div><div> -kill Reset the Launch Services database before doing anything else</div><div> -seed If database isn't seeded, scan default locations for applications and libraries to register</div><div> -lint Print information about plist errors while registering bundles</div><div> -lazy n Sleep for n seconds before registering/scanning</div><div> -r Recursive directory scan, do not recurse into packages or invisible directories</div><div> -R Recursive directory scan, descending into packages and invisible directories</div><div> -f force-update registration even if mod date is unchanged</div><div> -u unregister instead of register</div><div> -v Display progress information</div><div> -gc Garbage collect old data and compact the database</div><div> -dump [table] Display full database contents after registration</div><div> -h Display this help</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div></body></html>