How to see (and/or hear) the names of every process in macOS that starts or stops

[Airy]

Did you ever wonder what processes in macOS are starting or stopping in the background while you work? For example, what processes are starting up when you start an application? Or what processes are shut down when you close an application? Or what processes are starting up when you perform an action in an app (such as exporting a video)?

There are a lot more hidden processes starting and stopping that you probably imagine. If you want to learn what they are, then you need this macro. This macro will use Notifications and spoken audio messages to tell you whenever a process starts or stops. It's quite fun and educational. (You can disable either the Notifications or the spoken audio messages by disabling those actions near the end of this macro.)

This macro needs to store two files in your file structure. Therefore, you can either create a folder in your home directory called "data" (which is what I recommend) or you can specify your own files by modifying the purple actions inside this macro. You must do one of these things before running this macro for the first time.

You can disable the audio messages by disabling the two orange actions near the end of this macro. Or you can disable the Notification messages by disabling the two green actions near the end of this macro.

The magenta action in this macro is helpful to filter out process names that you don't want to be reported. There are currently six names in this action which are being filtered out because they are triggered too often. Four of these names are "bash, grep, sort, sed" which are processes that are created during the running of this macro and therefore should remain intact. The others you can remove or supplement as you see fit. (There is a small chance of a false negative. For example, if a process contains "sh" then it won't be reported. I'll fix this for version 1.1 later.)

The real reason I had to write this macro is that I needed to know if any apps in macOS were launching hidden processes. This is important because the existence of such processes can tell me a lot about the state of the running application. Rather than using Find Image to detect whether some application is in a particular state, I can instead check if a particular process is running. This is probably more efficient and more reliable than using Find Image.

Since it's nearly the end of the month again, I'm nominating myself for "macro of the month" again.

Speak New and Deleted Process names Macro (v11.0.3)

Speak New and Deleted Process names.kmmacros (20 KB)

Oh! I forgot to mention, the macOS voice called "Daniel" is used to name newly created processes, while the female voice named "Samantha" is used to name newly deleted processes. This works well for me. You can change that if you want.

EDIT: (4 hours later) I've made cosmetic changes and a very small bug fix but I won't upload any new versions until I hear some feedback on this macro.

[_jims]

@Airy

I hear some feedback on this macro

Hi, @Airy. This is a very creative and useful macro. Thanks for sharing.

As written, there are a few issues:

• The macro does not function correctly if the folder ~/data does not exist. Consider using mkdir -p. Also I recommend creating the folder in ~/Documents, or better yet, /tmp.

• There is a shell script with the hardcoded path /Users/myname/....

• I added top, less, and history to the exclusion list.

• After the Execute a Macro action I recommend adding a Cancel This Macro action. It might not be critical, but I think it is good form.

After those changes, I think the macro works as you intended.

There is one other form change that I recommend. In If Then Else or Switch/Case actions, if you have conditions that are blank, I suggest inserting a comment: Intentionally blank.

If this isn't done, you (or someone else) might think that you had forgotten to address that condition.

[Airy]

I'm so grateful for your feedback (and it was positive!) At least one of your ideas is already implemented in v1.1, which I haven't uploaded yet. As for the hardcoded path, I did mention in bold text in my original post that people must either create a folder called data or change the purple actions which contain hardcoded paths. I could take your idea and use mkdir, but I wanted people to be cognizant of the permanent path/file that this macro requires.

[_jims]

@Airy

As for the hardcoded path, I did mention in bold text in my original post that people must either create a folder called data or change the purple actions which contain hardcoded paths.

Oops, how did I miss that?

@Airy

I wanted people to be cognizant of the permanent path/file that this macro requires.

Curious why?

To me, seems like /tmp is the way to go.

[Airy]

@_jims

Curious why? To me, seems like /tmp is the way to go.

I don't think I can use /tmp because the file must not be automatically deleted by macOS, otherwise my macro will generate about 1400 notifications and spoken messages. That would be horrible. Since macOS deletes files in that folder on its own initiative, I don't think it's safe to place a file there. But if you are certain that macOS won't delete that file, I guess I can put it there.

[Nr.5-need_input]

I also must say that /temp is not a good place for the permanent storing for the needed file … @Airy youre totally right about the behavior of deletes of that needed file though the OS.

I think a global Variable is the best solution here to be set by the Macro‘s User.

Greetings from Germany

Tobias

[Airy]

@Nr.5-need_input

I think a global Variable is the best solution here to be set by the Macro‘s User.

I already tried that, but it didn't work because of the requirements of the diff shell command. But if you want to try to get the diff command to work with variables, I'm eager to see your solution.

[_jims]

@Airy

I don't think I can use /tmp because the file must not be automatically deleted by macOS, otherwise my macro will generate about 1400 notifications and spoken messages.

Hum, maybe I'm missing something but I made the change to /tmp and haven't seen a problem. I've even used rm ProcessesOld.txt to try and break the logic.

BTW, macOS will not remove files in /tmp that have been updated recently; they will be deleted when you reboot, however.

[Airy]

@_jims

macOS will not remove files in /tmp that have been updated recently; they will be deleted when you reboot, however.

Okay, then that should be safe for me to use. I will update my macro to remove paths into the user's home folder. Thanks.

[Nr.5-need_input]

@Airy

I already tried that, but it didn't work because of the requirements of the diff shell command. But if you want to try to get the diff command to work with variables

Hmm …

sounds like there is something strange about shell commands like the diff command - which comes only with the interpreter and one or two parameters that are devided by a space from each other. Maybe for commands like them the Execute Shellscript Action is the wrong thing to choose.

Have you thought about using the Execute an AppleScript Action and building the whole command string with the quoted form syntax rule ?!

I believe this way it might possibly work well with using variables because you’re concenating the command based on its single parts into the whole command string it has to be before being executed.

I think I’m remembering that I’ve had something similar to do on one or two of my macros and it worked right out of the box - just after smashing my head against the wall a long time trying to figure out why the Shellscript action was failing every time.

Greetings from Germany

Tobias

[griffman]

If the problem was not getting the results you want from diff when run in a shell script action, it might be because of how diff codes its replies and Keyboard Maestro interpreting that as an error. I say this because I ran into this very problem myself a couple years back…

Bizarre failure of shell script 'diff'

I'm trying to run a very simple shell script: cd /tmp echo "$KMVAR_var1" > file1.txt echo "$KMVAR_var2" > file2.txt diff file1.txt file2.txt > diff_result.txt I don't actually want the diff results in a file, I want them in a variable returned by the shell script action. But because that was failing, I tried the above to write it to a file instead. But it still failed (with the generic failed in shell script message). It works fine if I run those commands directly in Terminal. But here's wher…

-rob.

[Nr.5-need_input]

Thanks for pointing to your issue …

I think the secret Soup that @Airy and I also weren’t aware of is the process substitution method… so the diff command can be used with variables.

But the bummer is that there is the limitation of (at least when using bash shell) having the bash shell installed via Homebrew from what I understood.

Anyway - many thanks for this piece of information. Again something very relevant learned today.

Greetings from Germany

Tobias

[Airy]

@griffman

If the problem was not getting the results you want from diff when run in a shell script action

No, that was not my problem. My problem was that the diff command requires two files. As I said above to Nr5, if you can "get the diff command to work with KM Variables," instead of files, I'm eager to see your solution.

[griffman]

@Airy

if you can "get the diff command to work with KM Variables," instead of files, I'm eager to see your solution.

See @Nr.5-need_input's reference above to process substitution, which though not the problem I was having, is discussed in that same thread by @drdrang:

@drdrang

By the way, you can avoid temporary files by using process substitution which is available in zsh and later versions of bash (e.g., the bash you can get from Homebrew). A shell script like

#!/bin/zsh
diff <(echo "$KMVAR_InstanceVar1") <(echo "$KMVAR_InstanceVar2")

will diff the contents of the two KM variables with no need to create and clean up temp files.

-rob.

[Airy]

@griffman

See @Nr.5-need_input's reference above to process substitution, which though not the problem I was having, is discussed in that same thread by @drdrang:

I actually did try process substitution, and I was getting an error in the Execute Shell script action when I tried doing that. If you managed to get it to work, please show me how. I just assumed process substitution did not work in the Execute Shell script action.

[Nige_S]

@Airy

I actually did try process substitution, and I was getting an error in the Execute Shell script action when I tried doing that.

Did you include the zsh shebang as the first line?

It won't work without as, by default, you'll be executing in the sh shell (actually macOS bash in sh compatibility mode). And, as noted, it won't work in macOS bash either, you'd need to use v4 via homebrew or similar.

[Airy]

@Nige_S

Did you include the zsh shebang as the first line?

Ahh, that must be why it failed for me. Thanks. I didn't notice it in its greyed out state in the quote above.

If this works, as I suspect, I will be able to remove all files from my script.