Try this little variant. I don’t think it will change much, but who knows.
iTerm Tab with cd [variant].kmmacros (2.7 KB)
(I’ve slightly changed the test for frontmost.)
1 Like
Oh wow, that’s strange. I think it worked the first time I ran it and it was good.
But now once again, it just brings iTerm on focus but doesn’t trigger the hotkey to open the full screened iTerm.
Remove the frontmost test, so that the last tell block is this:
tell application "System Events"
key code 13 using {option down, control down, shift down, command down}
end tell
Try it
- while iTerm is frontmost
- while another app is frontmost
Just to see if the hotkey gets pressed now.
Still not working I am afraid. Switching focus to iTerm but does not trigger the hotkey, have to do that myself every time.
When I have just this in the macro :
It works as it should. Opens iTerm with hotkey when not in iTerm, and doesn't close it when iTerm is active.
I believe the culprit of the whole macro not triggering the hotkey is because that ‘if frontmost of process “iTerm2” is false’ is always true even when switching from Safari or other apps. I would assume you bring focus to iTerm in the prior code of the script and then that if clause never triggers.
If you mean the activate in line 3 then you are basically right. At least on my Mac, because – on my Mac – I don’t need the last tell block (key code 13). The script works exactly the same(!) for me without it, because of the activate.
The only reason we’ve put in the key code 13 thingy was because on your mac the activate didn’t work when in fullscreen mode, as you said in one of the earlier posts.
Maybe, on your machine it briefly activates, and then goes back to the other app, but the short activation period is enough to prevent the key code 13 block from running.
→ → So, delete line 3 (activate) please and try it again.
PS:
To make it clearer:
On my mac I can either…
- use the
activate(line 3) or… - the activation via
key code 13(⌃⌥⇧⌘W)
The result is the same!
Without the key code 13 method (that is, only via activate) it even works better, because with ⌃⌥⇧⌘W sometimes that transparent, large window interferes.
1 Like
Thank you, thank you.
This works magically.
Just curious, why don’t you use iTerm, I think it is better than stock Terminal in my opinion.
Great. So, the question is: why didn’t it work at the beginning? (After all, we introduced the ⌃⌥⇧⌘W method because it didn’t work.)
I’ve noticed a problem now here, on my Mac:
If iTerm is not frontmost and no window is open, the macro will fail, because the result of the window 1 test (line 4) is always positive. Via AppleScript I can see that there is indeed a – obviously invisible – window with 2 tabs/sessions. I didn’t have that yesterday.
Just curious, why don't you use iTerm, I think it is better than stock Terminal in my opinion.
I used it, some years ago, but Apple’s Terminal has improved since, and it offers everything I (currently) need.
Wait: What do you mean exactly? It works with only activate or it works with only ⌃⌥⇧⌘W ?
Works only with ⌃⌥⇧⌘W. I removed the activate command from line 3 as you said.
OK.
Now I’ve restarted the Mac, and I get a new behavior:
iTerm is running – frontmost or not, doesn’t matter – and I launch the macro → The macro succeeds and new tabs are created, but not in any visible window:
Either I’m missing something big, or something is fishy here.
Now, after the restart, it seems I get the behavior you described on your side.
And I have found the problem (at least on my machine):
If I uncheck the window hides checkbox – and relaunch(!) iTerm – everything is fine:
The macro works with only the activate from line 3, without the ⌃⌥⇧⌘W stuff. (That is, the same way as before I restarted the Mac. I don’t know why the behavior has been changed by a restart.)
I suggest you try it, because using activate is more “proper” than typing key strokes via System Events.
(Since you are working in fullscreen mode, the iTerm window is in its own Space either way, so it’s not necessary to hide it. (When you tab to another app you’ll be taken to another Space.))
Very confusing, that app 
I don’t think this is exactly what you’re looking for, but maybe it’s close or at least useful.
Here’s a function you can add to your .bash_profile. Running it from within* iTerm will:
- Detect frontmost Finder window
- Get its path
-
cdto that path
(*I’m sure you could figure out a way to execute it from a Keyboard Maestro Macro. Or maybe that’s what this whole thread is about. If so, sorry 
)
cdf () {
currFolderPath=$( /usr/bin/osascript <<" EOT"
tell application "Finder"
try
set currFolder to (folder of the front window as alias)
on error
set currFolder to (path to desktop folder as alias)
end try
POSIX path of currFolder
end tell
EOT
)
echo "cd to \"$currFolderPath\""
cd "$currFolderPath"
}
I use it all the time.
Yes, the OP wanted to open a new tab and cd to a particular directory (set by a variable), not necessarily the Finder window.
But the command indeed is really useful to quickly cd to the Finder window.
Many thanks for sharing!
Actually I’ve added the shorter form to my .bash_profile:
alias cdf='cd "`osascript -e "tell application \\"Finder\\" to get POSIX path of (insertion location as text)"`"'
- The AppleScript is cleaner
- For me it doesn’t make sense to cd to the Desktop on error
FWIW, a JS variant
alias cdf="cd `osascript -l JavaScript -e \"'\'' + decodeURI(Application('Finder').insertionLocation().url().slice(7)) + '\''\"`"