BBColors does its thing by reading and writing to BBEdit’s preferences using the
defaults system. The defaults man page says:
Tuesday, 10 October 2006
Those that are 'obtained from' Apple, the Mac App Store, or an 'Identified Developer' are much more likely to be available in 64-bit for macOS Catalina, even if the app is 32-bit on macOS Mojave.
Since applications do access the defaults system while they’rerunning, you shouldn’t modify the defaults of a runningapplication. If you change a default in a domain that belongs to arunning application, the application won’t see the change andmight even overwrite the default.
So, as a precaution, the
bbcolors tool won’t load a new color scheme if BBEdit (or TextWrangler, if that’s your bag) is currently running. But so how do you test if an application is currently running?
BBColors is written in Perl, but the simplest good way I know of to test if an app is running is this bit of AppleScript:
Where “R*ch” is BBEdit’s four-character creator type.
If BBEdit isn’t running, it returns 0; if it is running, it returns 1 (or a larger integer, if, for whatever reason, you’re running more than one copy of BBEdit).
Using the creator type is a bit geeky — plus, some processes don’t have creator types (most such apps are background “helper” apps, but even some normal apps, Console for example, don’t have creator types). So, you can also just ask for the name:
and you should get the same results, with the added benefit of being able to identify any process — not every process has a creator type, but they all have names.
Radio tuner app windows 10. There’s also the
displayed name property, which is different than the just plain name :
That might work, but it won’t if you have the Finder’s preference to always display file extensions turned on (as I do). In that case, an application’s
displayed name contains the “.app” extension, so you’d have to write:
“
Names ” and “displayed names ” can differ in other ways, as well. You can determine if Quicksilver is running using its name :
And because the string comparison is case-insensitive, you can mis-capitalize it “QuickSilver” or “quicksilver” or “QUICKSILVER” and it’ll still work. But if you want to identify it by
displayed name , you’ve got to use the clever Unicode-laden spelling that you see atop its application menu:
So in a nut: the
creator type and name properties are good bets; the displayed name property is not, because it changes depending on the user’s Finder preference for displaying file extensions.
![]() Doing It From Perl and the Shell
Now as I wrote earlier, BBColors is written in Perl, not AppleScript. I suppose what most Unixheads would do is pipe the results of
ps -aux through grep , but it’s easy to call AppleScript from Perl, or any other shell scripting language: just use the osascript command-line tool. From the Terminal, you could type:
Here’s a Perl subroutine that takes a creator type as a parameter, and returns the result of our AppleScript (i.e. the number of processes running with that creator):
Except this code has a few subtle bugs: it won’t work if it’s passed a creator type string containing either a literal double-quote or a backslash character. I’m not aware of any creator type codes that use these characters, but they’re legal.
![]()
So here’s a fixed version that backslash escapes single quotes, double quotes, and literal backslashes. We need one level of backslashing for Perl, and another level for the shell when we call the
osascript tool:
Starting with Mac OS X 10.4, the system’s default Perl installation includes a Perl module called
MacPerl (which started life way back in the classic Mac OS era). Gemini 2 app mac. MacPerl contains a routine called DoAppleScript() , which does what you think it does; it takes as input a string containing AppleScript code, runs the script, and returns the result as a string. We can use this instead of calling out to the osascript shell tool, like this:
The only real advantage to this technique is that you don’t have to worry about escaping single quotes — just double quotes and literal backslashes.
DoAppleScript is also a little bit faster than shelling out to osascript , but both techniques are pretty fast.
You can also use the
Mac::Processes module, which is part of the Mac::Carbon bundle of modules, and is also included by default in Mac OS X 10.4’s default Perl installation. We could rewrite our is_app_running() subroutine to use Mac::Processes like so:
We can also identify apps by name using
Mac::Processes , by using the processName property instead of processSignature ; these names are the same as those returned by the name property in our AppleScript examples (i.e. not displayed name ). Repetitive typing app mac free.
The advantage to using
Mac::Processes is that you don’t have to mix any AppleScript into your Perl. The disadvantage, though, is that the version of the Mac::Carbon modules that ships by default with Intel-based Macs contains a bunch of endian-related bugs. One such bug is that the creator types returned by the processSignature property appear backwards: instead of “R*ch” for BBEdit, you get “hc*R”; instead of “MACS” for the Finder, you get “SCAM”.1
Check Which App Is Running Machines
That might strike you as a really weird bug. The short explanation is that creator types aren’t really four-character strings; they’re four-byte integers, and treating each of the bytes as a MacRoman-encoded character is just a shortcut that makes them more readable and memorable. (Such four-byte “OSTypes” are used throughout Carbon.) The problem is that the PowerPC and 680 × 0 architectures are big endian, and the x86 (a.k.a. “Intel”) architecture is little endian, which means the bytes comprising an integer appear in the reverse order on Intel.
Show Running App Mac
Chris Nandor — who maintains the entire
Mac::Carbon suite of modules — fixed these Intel compatibility bugs back in June, but, alas, the fixed versions don’t yet ship with the OS. So if you’re writing a script for your own use and have upgraded to the latest version of Mac::Carbon from CPAN, you have no worries. But, if you’re hoping to distribute your script to other Mac users who probably have the default (buggy on Intel) version of Mac::Carbon installed, as I was with BBColors, you’re stuck dealing with the buggy version. The best way to do that is to identify apps by name — which works with the default version of Mac::Processes on all Macs running 10.4 — rather than by creator type.
Check Which App Is Running Mac Desktop
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |