Macro settings

[thshdw]

By default shuttle opens new commands in a new tab. These changes allow you to set flag “isNewTab”:false” if set the command will open in the active tab. This is useful if you want to run a commonly used command in the existing ssh tab.

{
"name": "check ssh process",
"isNewTab": "false",
"cmd": "ps aux | grep [s]sh”
}

With isNewTab set to false the command will run in your existing terminal tab and NOT a new one. If this setting is omitted then commands will revert back to the default of opening in a new tab.

I branched these changes off my terminal-themes branch as some of the code was reused.

[thshdw]

@fitztrev This is on hold until the SQLite / applescript changes are in place. I wanted to chat about the implementation. The goal of this is to allow commands to run in the existing tab Not the new one.
I want to make this as foolproof / easy as possible perhaps the value here should simply be "newTab": "no", what are your thoughts.

[fitztrev]

Should these be global preferences, as opposed to per-host?

Maybe one setting open_behavior? Then the UI has 3 radio buttons:

1. Current window, new tab (default)
2. Current window, current tab
3. New window

[thshdw]

@fitztrev Here is my scenario:
I have a web server that I log in to. In shuttle its menu is
WebServers > DevSite > ssh to Dev
^this is default window handling and shuttle will open this site in a new tab"

I have some scripts that I often run on this server and and I place these in shuttle:
WebServers > DevSite > parse log files
WebServers > DevSite > RestartSite
^To have these commands run in my "ssh to Dev" session, they need to be placed in the existing Terminal window. To do to that I would set "isNewTab": "false",

I'm basically treating the "hosts" in JSON as "commands". In JSON, with the "command", I'm specifying how terminal or iTerm will launch that "command":
In a new tab: no extra notation in JSON as this is the default behavior
In an existing tab: "isNewTab": "false", overrides the default and opens in existing tab
In a new window "isNewWindow": "true", overrides the default and opens in new window
Perhaps in the future:
In a split iTerm window "isSplitVertical": "true" or "isSplitHorizontal": "true"

[thshdw]

Perhaps the extra notation should be like this
"inTerminal": "current",
"inTerminal": "new",

"SplitPane": "Vertical",
"SplitPane": "Horizontal",

so

{
"name": "check ssh process",
"inTerminal": "current",
"cmd": "ps aux | grep [s]sh”
}

would run command ps aux | grep [s]sh in the existing Terminal window

[fitztrev]

@thshdw Sounds good. Instead of current, I wonder if each cmd could target a specific tab by a name.

So with your scenario, first you SSH into a host, then you want to run a command inside that session. To make sure that command gets sent to the right tab/window, maybe the applescript could first set active tab to [name]... That's just pseudo-code so it may not even be possible. But I would just worry about sending a command to the wrong terminal window and having unforeseen effects. That's why I had everything default to just open a new tab.

But I'm fine with your suggestion. The user can be responsible for how they choose to use it.

[thshdw]

@fitztrev with iTerm nightly you can do this applescript:

tell application "iTerm"
    tell terminal window 5
        select
        tell tab 2
            select
            tell current session
                activate
                write text "ps aux | grep [s]sh"
            end tell
        end tell
    end tell
end tell

It may be possible but I don't see a way to select a tab by its name. If you could select by name, I think we would run into issues with non unique names. Maybe terminal window 5 has two tabs with name "foo".

Adding these features does add some risk, in that it could be possible for a user to run a command on the wrong server. However shuttle would not come shipped with these directives in the JSON; users would have to manually enter these in. Then as you mention, the user can be responsible for how they choose to use it.

Being able to manually set how a command launches makes shuttle very flexible. I think this flexibility outweighs the risk. Perhaps if these settings end up in master we can note the risk in the help section for these features something like...

Note: adding "inTerminal": "current", to a command will launch that command in the current open terminal. Be careful when using this option as it could be possible to run a command in the wrong server.

We could also instruct users that run commands in existing windows to wrap those commands with some user input like this:

echo "are you sure y/n"; read sure; if [ "$sure" == "y" ]; then echo "running command" && ps aux | grep [s]sh; else echo "exiting..."; fi

This way we have done our due diligence :-)
Thoughts?

[fitztrev]

@thshdw 👍 😄