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 <rlha...@smart.net> wrote: > > > > On Apr 15, 2023, at 15:57, Kenneth Wolcott <kennethwolc...@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. >
