What
tush with no arguments runs $SHELL. Make that explicit, and make the first
argument mean what to run rather than nothing: tush /bin/zsh should be
the long form of tush, and tush k9s should tunnel k9s.
Now
The first argument is either a subcommand (version, help), empty, or a URL:
switch arg {
case "version": …
case "help": …
case "": os.Exit(host(ctx, bin)) // runs $SHELL
}
target, err := url.Parse(arg) // otherwise: client mode
So host mode is only reachable by passing nothing, and the fact that it runs
$SHELL is implicit. There is no way to say "tunnel this program instead".
Wanted
Dispatch on whether the first argument is a URL, and treat anything else as the
command to run:
| Invocation |
Mode |
Runs |
tush |
host |
$SHELL (falling back as today) |
tush /bin/zsh |
host |
/bin/zsh |
tush k9s |
host |
k9s, resolved on PATH |
tush https://… |
client |
attaches |
Client mode short-circuits on a URL; host mode is the fallback, resolving the
command the way which does (exec.LookPath).
That generalises what the host already is. Nothing about the console, the
attach endpoint or the client assumes the process is a shell — it is simply
whatever runs on the pseudo-terminal — so tush k9s mostly means letting the
argument through.
Worth deciding
- Reserved words.
version and help currently win over any program of
the same name. Keep that (and document it), or require a separator so
tush -- version runs a program called version.
- Arguments to the command.
tush k9s --context prod needs the tail
forwarded. -- is the conventional fence.
- What counts as a URL.
url.Parse accepts almost anything; a bare word
like k9s parses fine as a relative URL. The test needs to be a scheme check,
not "did it parse".
- Command not found. Today a missing
$SHELL fails before the tunnel is
published, which is the right order: fail before handing out a URL that leads
nowhere. Keep that for a named command.
- Exit behavior. The host exits when the program exits, which is already
true of the shell.
What
tushwith no arguments runs$SHELL. Make that explicit, and make the firstargument mean what to run rather than nothing:
tush /bin/zshshould bethe long form of
tush, andtush k9sshould tunnel k9s.Now
The first argument is either a subcommand (
version,help), empty, or a URL:So host mode is only reachable by passing nothing, and the fact that it runs
$SHELLis implicit. There is no way to say "tunnel this program instead".Wanted
Dispatch on whether the first argument is a URL, and treat anything else as the
command to run:
tush$SHELL(falling back as today)tush /bin/zsh/bin/zshtush k9sk9s, resolved onPATHtush https://…Client mode short-circuits on a URL; host mode is the fallback, resolving the
command the way
whichdoes (exec.LookPath).That generalises what the host already is. Nothing about the console, the
attach endpoint or the client assumes the process is a shell — it is simply
whatever runs on the pseudo-terminal — so
tush k9smostly means letting theargument through.
Worth deciding
versionandhelpcurrently win over any program ofthe same name. Keep that (and document it), or require a separator so
tush -- versionruns a program calledversion.tush k9s --context prodneeds the tailforwarded.
--is the conventional fence.url.Parseaccepts almost anything; a bare wordlike
k9sparses fine as a relative URL. The test needs to be a scheme check,not "did it parse".
$SHELLfails before the tunnel ispublished, which is the right order: fail before handing out a URL that leads
nowhere. Keep that for a named command.
true of the shell.