Re: Bash Command Leads to CLI No Longer Drawing Commands

is siteis siteis siteis siteis site
On Sat, 31 Jan 2026 at 06:08, Garrett Andrews via Bug reports for the GNU
Bourne Again SHell <[email protected]> wrote:

> handle_ssh_connect () {
>     target_ip=$1
>     command=$2
>     ssh -o StrictHostKeyChecking=accept-new ${LINC360_USER}@${target_ip}
> & > /dev/null 2>&1
>     pid="$!"
>     sleep 15
>     ps -ef | grep $pid
>     kill -9 $pid
>     sshpass -p ${LINC360_PASSWORD} ssh ${LINC360_USER}@${target_ip}
> $command
> }
> ...
> handle_ssh_connect 10.38.83.104 "touch hi"
>

... after running the 2 commands above, your terminal will no longer draw
> your commands to screen. hitting enter spends the buffer, meaning whatever
> command youve typed into the buffer will be executed, but will not be
> written to GUI. Best guess is ssh & causing it. Intent of code was to have
> CI/CD connect initially via ssh to add to known hosts (so i can pull data
> later). im sure there exists a more elegant way
>

The far simpler way to demonstrate this effect is to type:

stty -echo

Bash cannot know whether you have turned echo off intentionally (such as by
running stty) or left it off accidentally (by killing a process such as ssh),
so it just leaves it alone. If you want to re-instate echo, just blind type:

stty echo

The easiest solution in this case would be to change “kill -9” to just “kill”;
don't use “-9” unless something has gone wrong.
But that would hide worse problems, so please read on.

If you look closely at the output of “ps” you will see that the “ssh”
process is in state “*T*”, meaning that it's stopped, which is because it's
trying to read from the terminal when it's in the background. (That's
probably why you decided you needed to kill it, because it always seemed
“hung”.)

A somewhat better fix would be to change the first ssh to be
non-interactive in the foreground. When you run ssh interactively, echoing
comes from the remote system, not locally, so the local echo needs to be
turned off, and it's actively reading from the terminal even when the
remote process isn't waiting for input. Normally you don't notice this
because ssh will return the local echo state to whatever it was before it
started, but if you kill it with “kill -9” it doesn't get a chance to tidy
things up like this.

Simply invoke ssh with a command to run on the remote system, such as
“true”, and run it in the *foreground*, without a remote tty (-T), and
without reading any input (-n).

ssh -nT -o StrictHostKeyChecking=accept-new -o BatchMode=yes
"$LINC360_USER@$target_ip"
true

Clean up minor omissions. (*2) Remove all the logic for delaying and
killing it.
(“BatchMode=yes” will prevent ssh from asking for a password.)

However there's an even simpler fix: omit the first ssh command entirely,
and run the second one with the “StrictHostKeyChecking” option, like:

sshpass  -p "$LINC360_PASSWORD" ssh -o
StrictHostKeyChecking=accept-new "$LINC360_USER@$target_ip" "$command"

-Martin

PS:

*1: I've omitted the “>/dev/null 2>&1” because it did nothing useful: it
was a separate empty command after the “&” that terminated the preceding
command.

*2: I've also fixed the missing quotes that would have caused other
problems.
Run your scripts through “ShellCheck” before deploying to production, or
whenever you have issues.