Terminal & Multiple SSH connections

How are you referencing your windows?

Referencing them via index (e.g. '... window 1, window 2', etc.) is inherently problematic since window orders can change (what is 'window 1' now might be different from 'window 1' in two minutes time).

Instead, Terminal.app passes back a reference to the window when you run a new shell command. This should be used for all subsequent commands to that shell. For example:

tell application "Terminal"
	set host1Window  to do script "ssh host1"
	set host2Window to do script "ssh host2
	do script "foo" in host1Window
	do script "bar" in host2Window
end tell

now there is no ambiguity as to where each command runs.

As an aside, you might want to look at the ssh options since there may be better ways of running remote commands, depending on what you're trying to do.

As an example, here's an example of a message broker script. Let me know if this gets you closer.

The first script should be saved as a stay-open application. When launched it creates three new windows with separate ssh connections to the target. You can open as many connections as you need.

It also saves a reference to each connection for later use (here I use labels 'codec1', 'codec2' and 'codec3', but you can use anything you like).

global codec1win, codec2win, codec3win


on run
	set theUsername to "me"
	set theHostname to "shell.xyz123.com"
	
	tell application "Terminal"
		-- just open three connections -- extend as much as you like
		set codec1win to do script "ssh " & theUsername & "@" & theHostname
		set codec2win to do script "ssh " & theUsername & "@" & theHostname
		set codec3win to do script "ssh " & theUsername & "@" & theHostname
	end tell
end run

on idle {}
	-- just a tickle to keep the app alive
	return 60
end idle

on sendTo(theHost, theCommand)
	if theHost = "codec1" then
		tell application "Terminal" to do script theCommand in codec1win
	else if theHost = "codec2" then
		tell application "Terminal" to do script theCommand in codec2win
	else if theHost = "codec3" then
		tell application "Terminal" to do script theCommand in codec3win
	end if
	-- etc...
end sendTo

Then the script then sits idling in the background, doing nothing until it's told to by the second script.

This second script simply sends a message to the broker script and passes in the connection identifier and the command to run. The broker identifies the target and sends the appropriate command.

tell application "CodecBroker"
	sendTo("codec1", "foo")
end tell

(here 'CodecBroker' is what I named my stay-open script. You can call it whatever you like).

You can duplicate the second script as many times as you like for as many connection/command combinations as you like. You may also be able to do something with BetterTouchTool to pass in parameters rather than hardcoding the commands in the script - that requires more knowledge of BetterTouchTool than I have.

This is only one approach, but it sounds like it's along the lines of what you were looking for.

You could simplify all this by using iTerm2

https://iterm2.com

Create a Profile for each system you wish to start an ssh session.

Assign a Command-Control-letter to each profile

You can configure the profile so that it open a new Tab or a new Window.

You can have iTerm2 memorize a window and tab arrangement, and either ask iTerm2 to remake that arrangement, which includes issuing all the ssh commands, or you can configure iTerm2 so it uses the saved arrangement when you launch iTerm2, along with issuing all the saved ssh commands.

I can Quit iTerm2, reboot (such as when installing a software update), relaunch iTerm2, and I have all my windows and tabs opened, and all my ssh connections re-established. In many cases, the ssh commands attach to a tmux session on the remote system, so I do not even loose what I was doing on the remote system, because my Mac was unavailable. GNU screen can be used instead of tmux, but I find tmux to be more flexible and has more features than GNU screen. Also iTerm2 has tmux integration, so you can ssh to a remote system, then issue the command "tmux -CC", and iTerm2 will take over control of the remote tmux sessions so you can use iTerm2 menus and keyboard shortcuts to manage the remote tmux sessions.

If you do not know what tmux is, search YouTube and you will find dozens of YouTube demos using tmux.

https://github.com/tmux/tmux/wiki

Are these separate and distinct scripts?

My earlier approach of capturing the reference to each connection is based on staying within the script, where a simple variable can track which window maps to which connection.

In this case, with separate scripts, if script1 creates the SSH connection there's no simple way for script2 to know that.

Changing the name of the window is ineffective and prone to error.

I'm also not familiar with BetterTouchTool to know what options it has. Off hand I can see a couple of ways of doing this - one option would be a stay-open script that acts as a message broker, managing the requests from BetterTouchTool and passing them to the appropriate connection.

Another approach is a series of scripts, each dedicated to a different codec/connection. You then setup BetterTouchTool to call the appropriate script based on the codec you want to invoke, passing in the relevant parameters.

A lot depends on the number of connections and commands you expect to manage. Can you provide ideal numbers?

I'm confused as to what you're trying to do here.

Maybe I should clarify a couple of points on how do script works:

On its own, do script "foo" will open a new shell window and execute the given command this new shell. It then returns a reference to the new window as a result.

With an in parameter (e.g. do script "foo" in window 1), Terminal.app runs the shell command in the given window (where in this case 'window 1' indicates the frontmost window).

In your AppleScript examples, you only have one line that calls 'do script' (and therefore opens a new window). All other examples of do script will execute in the front window, whatever that might be.

If you want to execute your commands in specific windows, you need to identify them.

I guess what's missing is how you want/expect to identify which window to run each command in.