Return to Answer

When you source the script, your interactive shell interprets it. It's probably Bash with job control enabled (the default behavior for an interactive Bash). If so, it runs the background loop in a separate process group, but its stdin is still connected to the terminal (in general this allows us to fg a background job and type to it). For a background job the inability to steal input from the terminal comes from SIGTTIN, EOF never happens. This way, when the script is being sourced, the listening nc does not suffer from -q 0 that is the problem when you run the script without sourcing.

Note this answer addresses the explicit question, nothing more. E.g.:

• there is a code injection vulnerability (./lanchat <local_ip>:<local_port> <remote_ip>:<remote_port>"'; rogue command'");
• there are short time windows when there is no listening nc on one end or the other;
• one pair of ncs might be enough to handle the whole "session".

The answer does not address these, however I can give you a sketch of an alternative script:

The script does require Bash (for itself and inside tmux). You run it with arguments you want to provide to nc, so e.g.

A single nc to nc connection handles all the communication in both directions. The script uses ts for timestamps (you can remove both instances of | ts %H:%M if you want) and rlwrap for line editing with readline (you can remove rlwrap if you want). sed -u is not portable; sed without -u will cause buffering issues, unless you also get rid of ts.

When you source the script, your interactive shell interprets it. It's probably bash with job control enabled (the default behavior for an interactive bash). If so, it runs the background loop in a separate process group, but its stdin is still connected to the terminal (in general this allows us to fg a background job and type to it). For a background job the inability to steal input from the terminal comes from SIGTTIN, EOF never happens. This way, when the script is being sourced, the listening nc does not suffer from -q 0 that is the problem when you run the script without sourcing.

There is more to improve, e.g.:

• there is a code injection vulnerability (./lanchat <local_ip>:<local_port> <remote_ip>:<remote_port>"'; rogue command'");
• there are short time windows when there is no listening nc on one end or the other;
• one pair of ncs is enough to handle a whole "session".

I won't address these here, however I can give you a sketch of an alternative script:

The script does require bash (for itself and inside tmux). You run it with arguments you want to provide to nc, so e.g.

A single nc to nc connection handles all the communication in both directions. The script uses ts for timestamps (you can remove both instances of | ts %H:%M if you want) and rlwrap for line editing with readline (you can remove rlwrap if you want). sed -u is not portable; sed without -u will cause buffering issues, unless you also get rid of ts.

Tested in bash 5.2.15, tmux 3.3a.

A single nc to nc connection handles all the communication in both directions. The script uses ts for timestamps (you can remove both instances of | ts %H:%M if you want) and rlwrap for line editing with readline (you can remove rlwrap if you want).

A single nc to nc connection handles all the communication in both directions. The script uses ts for timestamps (you can remove both instances of | ts %H:%M if you want) and rlwrap for line editing with readline (you can remove rlwrap if you want). sed -u is not portable; sed without -u will cause buffering issues, unless you also get rid of ts.

The answer does not address these.

The answer does not address these, however I can give you a sketch of an alternative script:

#!/usr/bin/env bash

target="$(tmux new -dP 'tail -f /dev/null')"
uptty="$(tmux display-message -p -F '#{pane_tty}' -t "$target")"
tmux split -t "$target" -v "
   rlwrap tee    >(sed -u 's/^/      < /' | ts %H:%M >${uptty@Q}) \
   | nc ${*@Q} > >(sed -u 's/^/> /'       | ts %H:%M >${uptty@Q})
"
tmux a -t "$target"

The script does require Bash (for itself and inside tmux). You run it with arguments you want to provide to nc, so e.g.

• first a listening side: ./lanchat -n -l -s 192.168.11.22 -p 2345,
• then a connecting side: ./lanchat 192.168.11.22 2345.

A single nc to nc connection handles all the communication in both directions. The script uses ts for timestamps (you can remove both instances of | ts %H:%M if you want) and rlwrap for line editing with readline (you can remove rlwrap if you want).