Fig spamming `nc` commands while typing about fig

[mschrage]

I've pushed the fix to withfig/config.

If anyone else is having this issue, you can pull the latest version by rerunning the the "install/update script"

[mschrage]

We switched out our IPC method from websockets to Unix sockets in the last build. Running nc on keypresses is the expected behavior.

However, it seems like you might have a non-standard version of nc? Is that possible? Can you run which nc to verify?

---

In the meantime, you can fix this issue by opening ~/.config/fish/conf.d/fig.fish and replacing the nc command with the following:

fig bg:fish-keybuffer (commandline -C) (commandline) 0 &

Here is a snapshot of the old version.

This reverts to using a websocket connection which is slightly slower, but should solve the issue until I can push a fix to the withfig/config repo.

[jeremylvln]

We switched out our IPC method from websockets to Unix sockets in the last build. Running nc on keypresses is the expected behavior.

However, it seems like you might have a non-standard version of nc? Is that possible? Can you run which nc to verify?

In the meantime, you can fix this issue by opening ~/.config/fish/conf.d/fig.fish and replacing the nc command with the following:

fig bg:fish-keybuffer (commandline -C) (commandline) 0 &

Here is a snapshot of the old version.

This reverts to using a websocket connection which is slightly slower, but should solve the issue until I can push a fix to the withfig/config repo.

❯ which nc
/usr/local/bin/nc

✦2 ❯ nc --version
netcat (The GNU Netcat) 0.7.1
Copyright (C) 2002 - 2003  Giovanni Giacobbi

It doesn't seem to be an override from a nc alternative from brew, could you confirm this?

EDIT: this nc is a GNU version, I'm investigating.

EDIT 2: as discussed on Slack, specifying the macOS's path of nc (/usr/bin/nc) should do the trick.