How to run sessionizer on SSH remote server?

[chengjianhua]

@mikkasendke Hi, I successfully ran sessionizer on my local mac, it works amazing. But how can I make it work on my SSH remote server, that I can use it to list projects in the remote server, not my local mac.

[mikkasendke]

Hey, just thinking about it we need to write a generator function that will execute fd (or find etc.) on your remote. I hope you can install fd on the remote if not we should use what's there. However currently there will be a couple of issues since I do think that the callback i.e. the action done when selected probably has to be overwritten and currently that unless you implement something yourself prevents having a mixed list of local and remote projects since you only get one callback (you could have separate lists on different binds though). Another thing is that ssh agent is hopefully running and no password prompts are needed which would make it easier.
These are just some quick thoughts I'll leave another comment with some code later on today (with a small implementation of what I said)

[mikkasendke]

Well you can do something like this to list remote projects (if you have fd v10.1.0 or higher for the --format option) where remote is your schema.

local function FdRemoteSearch(remote, path)
    return function()
        local command = {
            "ssh",
            remote,
            "fd",
            "-Hs",
            "^.git$",
            "-td",
            "--max-depth=4",
            "--prune",
            "--format",
            "{//}",
            path,
        }
        local success, stdout, stderr = wezterm.run_child_process(command)

        if not success then
            wezterm.log_error("Command failed:\n", command, "\nerror:\n", stderr)
            return {}
        end

        if not stdout then return {} end

        local result = {}
        for line in stdout:gmatch "[^\n]+" do
            local entry = { label = line, id = line }
            table.insert(result, entry)
        end

        return result
    end
end

local remote = {
    FdRemoteSearch("user@host", "/home/user/git")
}

as for switching we would have to set options.callback in the schema to something different. Also this now depends on if you are willing to attach to a wezterm running on your remote or if you just want your local wezterm, if you want all new panes, and tabs to be on that remote or be using ssh immediately or should it just be the first pane. For example if it was just the first we could on selection just spawn a new workspace somewhere or go back to that and let it just ssh into your remote immediately that would be the most straightforward. I hope this helps you in some way and I am happy to help once I get to know some more about what you require (I also would like to make this more straightforward, integrated and free of hassle in the plugin soon)

[chengjianhua]

@mikkasendke thanks for response. My requirement is, sessionizer list local workspaces when on local wezterm. When I was working on a tab that is opened by wezterm connect <remote-host>, sessionizer list the workspaces that are located in the remote host which I was ssh-ing into.

to some extent, it's like how VSCode extension https://marketplace.visualstudio.com/items?itemName=alefragnani.project-manager works.

When open a remote workspace, it list the projects are located in the remote host.

When open a local workspace, it list the projects are located in my mac.

[mikkasendke]

Alright, so I tried it myself when attached to the domain the default for the SwitchToWorkspace action in the spawn command is to spawn it in the domain of the current pane so if you wezterm connect remote and from such a pane open the menu and select an entry in the list it will work and take you to that path. If you always want it to use that domain to be used you can do something like the following too:

-- the schema
local remote = {
    options = {
        callback = function(window, pane, id, label)
            if not id then return end
            window:perform_action(
                require "wezterm".action.SwitchToWorkspace({
                    name = id,
                    spawn = {
                        cwd = id,
                        domain = { DomainName = "the name you gave the remote in your config under config.ssh_domains presumably" },
                    }
                }), pane)
        end,
    },
    -- ... things like the FdRemoteSearch above
}

This is just the default callback used in the plugin but with the domain explicitly set. However I ran across one problem and that is that on switching to and creating the new workspace the environment variables of the client would bleed onto the hosts domain so my non FHS compliant local environment variables were being used there and the FHS compliant remote did not know where to find its binaries or even configuration for the shell. So maybe this works for you maybe it does not, I am currently looking at the logic of why and how that happens but I am also in the study phase right now so I might take some time. Hope this helps, if it does work for you that is great but either way it is probably best for this issue to remain open for now

[mikkasendke]

If you want to use the same keybind it should be fairly easy to find out which domain you are attached to (so ideally just the current pane) depending on that either do the local or remote FdSearch you can literally just wrap it in a function. Also the above problem does not occur when opening new panes or tabs on that remote so this does seem like a bug maybe I'll look into it

[mikkasendke]

I made this somewhat easier on my local branch right now by passing window and pane to the schema evaluation and in schema_processor.lua and pass them to the generator functions you can do that too but those and a couple other changes might come soon that way you get the pane directly and can get the current domain and other stuff easier

[mikkasendke]

The key thing here is that the code in your configuration runs still running locally on your machine and we can use for example the spawn command to execute programs in the remote execution domain or like in FdRemoteSearch just use ssh. That means a process ran by wezterm.run_child_process (which sessionizer.wezterm in the default generators uses) will always be local, if we want remote execution we need to run the program directly through ssh or let wezterm handle that via its execution domains. In that sense it does work a little differently than the vscode extension from what I saw. I hope all these messages help provide at least some clarity, I am sorry that I can't give you the perfect solution at least yet but I am sure we will figure it out

[chengjianhua]

@mikkasendke Great. Appreciate your diving into this.

if we want remote execution we need to run the program directly through ssh or let wezterm handle that via its execution domains

the later one is more elegant. It's better to avoid dedicated configuration for specific ssh hosts, that's not intelligent and automatic enough.

In that sense it does work a little differently than the vscode extension from what I saw.

As I know, VSCode remote run a VSCode server on the remote host and the extensions just run on the remote host like on local. VSCode handle the communication with remote.

[chengjianhua]

@mikkasendke If I understand correctly, I should wait for some changes you'll release soon?