Fig Autocomplete in SSH & Docker
Today, we are excited to announce Fig Autocomplete in SSH & Docker 🚀🚀🚀
- Set it up in < 30 seconds (see steps below)
- Support for linux & macOS, arm & x86_64, and bash/zsh/fish
Note: Autocomplete in SSH and Docker are currently only available on Fig Pro 👑. Try it free for 14 days.
Set up the Integrations
Follow the quick guides below or read our User Manual
How does Autocomplete work?
There are two big hurdles we had to solve to get Fig working in remote environments.
- How do we know what you've currently typed on in the remote terminal (the edit buffer)?
- How do we run shell commands to generate suggestions dynamically
How do we solve this in your local environment?
To get the edit buffer in your local environment, Fig spawns a pseudoterminal in each of your shell sessions (much like
tmux). Fig also installs shell integrations that wrap your shell's prompt in escape characters. With the pseudoterminal and these escape sequences, we are able to annotate your the cells of your terminal screen as
input (edit buffer),
output (command output), or
prompt. We can then grab the last edit buffer on the screen as what you've currently typed. If your interested in the details, check out our deep dive blog post here: How does Fig know what you've typed
Running commands locally is pretty easy as we can just spawn a process to list files, etc.
How do we solve this in your remote environment?
Our first approach to getting the edit buffer in the remote environment (docker or SSH) was to install our shell integrations in the remote environment. Since you have Fig installed on the host machine, the local shell still has a pseudoterminal, which means that if we wrap the remote prompts with the same escape sequences we can still annotate the screen and grab the edit buffer. This works well in simple cases, but unfortunately falls apart when tools like
tmux are used in the remote environment. This is a very, very common workflow in SSH environments. These tools add other characters like pane dividers to the screen that that local pseudoterminal can't correctly annotate and we end up with garbage text in the edit buffer.
To solve this issue, in the next few days we will be launching an even better version of SSH support that spawns a pseudoterminal in each shell on the remote machine as well and communicates the edit buffer via unix sockets with the host machine. In tools like
tmux, then, there will be a nested pseudoterminal inside each pane and we won't have to worry about extraneous characters on the screen.
To run commands in an SSH environment we take advantage of SSH's built in connection multiplexing. With the SSH
ControlMaster option, the host can reuse the original SSH network connection to initiate other SSH sessions to run commands on the remote machine. For docker environments, we simply use
We have several more major announcements coming this month. To stay up to date, follow us on Twitter: @fig