Não estou claro se você recebe um resultado por read?
ou se obtiver um fluxo de resultados. Eu acho que você está dizendo um pedido - > uma resposta. E você nunca deu um hexdump ou qualquer coisa da saída, mas parece que as terminações de linha são provavelmente CR-only, não DOS CR-LF ou LF unix. (É por isso que o seu prompt sobrescreve a saída após o netcat).
Eu encontrei o manual: link
Confirma que as respostas são encerradas com um CR. Isso faz com que seja difícil trabalhar com o shell, porque tr '\r' '\n'
tem o mesmo problema que o cat: ele não para depois de uma linha.
# read -d sets the delimiter.
# $'' is a special type of quoting where \r expands to a literal carriage return.
get_temp () { # io to fluke on FD 3
echo "read?" >&3
local resp
IFS= read resp -d $'\r' -u 3
printf '%s\n' "$resp"
}
exec 3<>"/dev/tcp/$host/$port"
while true; do # whole loop is redirected to log
temp="$( get_temp )"
printf '%s - %s\n' "$(date +%F_%T)" "$temp"
# or echo -n "$(date) - "; get_temp
sleep 1
done | tee -a "$log"
# or just >> "$log", and tail -f the log file when you want it on screen.
Ou uma implementação que permite que tr
lidem com o CR - > Tradução LF:
exec 3<>"/dev/tcp/$host/$port"
(while echo 'read?';do sleep 1;done >&3) &
tr -d '\r' '\n' <&3 | IFS= while read temp; do
printf '%s - %s\n' "$(date +%F_%T)" "$temp"
done >> "$log"
Isto coloca um subshell em segundo plano, escrevendo um comando a cada segundo. Você ainda precisa de um loop de leitura para obter a hora atual formatada nas linhas recebidas. IDK se ^ C matar a subshell ou não.
Variáveis definidas dentro do loop não estarão presentes após o término, porque nós canalizamos para ele , no caso de você tentar isso.
Essa é uma pergunta antiga, então eu não executei isso. Pode haver erros de sintaxe ou erros. Mas a ideia geral é boa, tenho certeza.