I'd be fine with a shorter mode. Got a concrete proposal?

Keep in mind there can be multiple gomote sessions open at once.

Would you do the short magic based on $GOMOTE being set? On there being only one gomote session?

Keep in mind there can be multiple gomote sessions open at once.

Indeed: for example, I've been using them to test plan9, solaris, and darwin concurrently (in separate terminals).

Would you do the short magic based on $GOMOTE being set? On there being only one gomote session?

I think I would start with $GOMOTE exclusively. That works with multiple sessions, and it's trivial to run export GOMOTE=$(gomote create […]) instead of just gomote create […].

(Perhaps we could also allow inference for singleton instances, but the failure mode of running commands on the wrong machine if you forget that you had another instance up seems potentially confusing.)

I think I would start with $GOMOTE exclusively.

SGTM.

but the failure mode of running commands on the wrong machine if you forget that you had another instance up seems potentially confusing

Agreed. That's been my main concern in the past when I've considered something like this.

So what's the rule? If the <instance> argument to gomote {destroy,gettar,ls,ping,push,put,put13,puttar,rm,run,ssh} does not contain a hyphen, then require $GOMOTE to set and fail otherwise? But there might be some ambiguity there with some of the commands, running commands with hyphens (pkg-config?), or moving around files with hyphens.

Or $GOMOTE != "" means that the <instance> argument cannot be specified (can't override $GOMOTE)?

Or $GOMOTE != "" means that the <instance> argument cannot be specified (can't override $GOMOTE)?

That seems like the simplest approach: it's easy enough to run GOMOTE='' gomote […] to bypass it for single commands, and then we don't have to worry about distinguishing instance names from commands.

I don't want to let the perfect be the enemy of the good here, but I find gomote run to be difficult to use in a lot of ways. Not just that it requires the hostname, but how it implements path lookup and how it escapes things.

I use this wrapper myself, which gives me a more normal PATH (plus go/bin, which I generally want), and implements ssh-like argument splitting (which has its own problems, but at least I'm used to it):

#!/bin/bash

if [[ -z "$VM" ]]; then
    echo "VM variable not set" >&2
    exit 1
fi

pre='PATH=$PATH:$PWD/go/bin &&'

# Duplicate the quoting behavior of ssh.
exec gomote run $VM /bin/sh -c "$pre $*"

I'm currently working on an extension to the gomote command to shorten the commands a lot by managing some state. The goal is to also allow manipulation of several gomotes at once (a la https://github.com/mknyszek/goswarm).

@aclements I'm also working on a fix for the PATH issue.

@mknyszek, if you're working on gomote PATH issues, also be aware of some CLs in flight: https://go.dev/cl/418104 (@ianlancetaylor) and https://go.dev/cl/367896 (me). 🙃

Thanks. I'm mostly focused on the gomote frontend, so based on those CLs I don't think we're interfering with each other much. Talking with @cagedmantis, I think the PATH issues with run I'm gonna fix in the gomote command itself by automatically setting a reasonable baseline path (/bin, etc.). The issues goes all the way down to the stage0 binary, which is run without a PATH, and then everything spawned from it (which is everything) by default doesn't have a PATH, unless you create a shell.

Just to avoid confusion and duplicate work, I tried to lay out what I planned to work on and what I discussed so far with Carlos in #53956. I had it in a doc, but I figured it would be more visible as an issue (and I can add it to the hotlist). Feel free to comment there if you have opinions. Nothing about that is intended to be set in stone, but more of a decent starting point.