1

I have a script that prints the bundle ids for all apps with open windows. When an Electron app is open (for example VSCode) the script asks "Where is Electron" and it shows all apps in the Applications folder except Electron apps. How to fix this behavior?

The Code:

set bundles to {}
tell application "System Events"
   set names to get the name of every process whose visible is true
end tell
repeat with name in names
   set bundles to bundles & id of application name
end repeat
1

You need to use a different name for your repeat statement’s loop variable - the term name is an AppleScript property and is also in System Events scripting dictionary. Your usage isn’t generating a syntax error, but it is probably causing more confusion than usual and is winding up targeting the wrong item (welcome to AppleScript).

You can use pipes around variable names like this where there may be a conflict (e.g. |name|), but CJK’s solution also avoids the repeat statement altogether.

  • Nope. AppleScript has zero problem with using property names as identifiers that are declared ahead of assignment, which includes using it to iterate over a list. There is nothing syntactically wrong with the OP's script. – CJK Jun 18 at 23:41
  • It works for the most part, but I got random “Where is the application?” dialogs for stuff like open Script Debugger documents, so something weird is happening in there. I didn’t get the same result using pipes or a different variable name. – red_menace Jun 19 at 0:12
  • I'm betting Script Debugger was the only random, because it itself is a bit weird. But point taken. Your advice isn't bad advice, I should have been clearer in stating. It just isn't wholly accurate, But, going on what I was preaching the other day, you're not wrong to encourage the newbies away from keyword identifiers if they don't know what the implications are. – CJK Jun 19 at 0:22
-1
tell application "System Events" to return the ¬
    bundle identifier of every process ¬
    whose visible = true

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

  • "We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed." Then that would be StackExchange's loss, since the context is clearly supplied by the OP, and the explanation for why my answer is right is because the code does exactly what the OP asked for. Some things in life really are just self-explanatory. – CJK Jun 17 at 12:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .