Summary
When a local command's output crosses the tokf output-filter threshold, the filter wrapper ends up appended into the command string that is sent to the remote shell over ssh. The remote does not have (and should not need) tokf installed, so the remote bash prints bash: line 1: tokf: command not found and the ssh call exits with status 127.
Short-output equivalents of the same ssh command work fine, which is what led me to initially misdiagnose this as a && / chaining issue — it's actually correlated with expected output length.
Environment
- Local: macOS, zsh,
/usr/bin/ssh (no local alias or shell function wrapping ssh)
- tokf: invoked from a Bash-tool wrapper that filters long local output
- Remote: plain Linux host, default bash, no tokf installed
Reproduction
A command whose output would be long enough to trip tokf's filter:
$ ssh HOST 'some command whose output crosses the filter threshold'
bash: line 1: tokf: command not found
# exit 127
Same command with short expected output:
$ ssh HOST hostname
HOST
# works
Expected
tokf should only operate on the local stdout/stderr pipeline. The command string passed to ssh must be left untouched so the remote shell never sees any tokf reference.
Observed
On commands that would produce long output, tokf appears to modify the command the local wrapper hands to ssh, so tokf ... ends up on the remote command line.
Impact
Breaks ssh-based remote operations that legitimately produce more than a handful of lines of output (listing files, docker ps, journalctl, ss, ip -d, etc.). Workarounds — piping remote output through head, tee-ing to a remote file, or splitting one ssh into many smaller ones — are awkward and noisy.
Summary
When a local command's output crosses the tokf output-filter threshold, the filter wrapper ends up appended into the command string that is sent to the remote shell over ssh. The remote does not have (and should not need)
tokfinstalled, so the remote bash printsbash: line 1: tokf: command not foundand the ssh call exits with status 127.Short-output equivalents of the same ssh command work fine, which is what led me to initially misdiagnose this as a
&&/ chaining issue — it's actually correlated with expected output length.Environment
/usr/bin/ssh(no local alias or shell function wrapping ssh)Reproduction
A command whose output would be long enough to trip tokf's filter:
Same command with short expected output:
Expected
tokf should only operate on the local stdout/stderr pipeline. The command string passed to
sshmust be left untouched so the remote shell never sees any tokf reference.Observed
On commands that would produce long output, tokf appears to modify the command the local wrapper hands to ssh, so
tokf ...ends up on the remote command line.Impact
Breaks ssh-based remote operations that legitimately produce more than a handful of lines of output (listing files,
docker ps,journalctl,ss,ip -d, etc.). Workarounds — piping remote output throughhead, tee-ing to a remote file, or splitting one ssh into many smaller ones — are awkward and noisy.