Como evito que apenas 'sair' seja salvo quando fecho uma conexão SSH?

Question

Ao procurar uma maneira de fazer isso no Google, tudo o que posso encontrar são maneiras de sair da sessão sem salvar o histórico (como kill -9 $$ ), mas tenho o problema oposto. Eu quero salvar todo o meu histórico, mas não o comando exit .

A Comcast realmente abusou de nós no trabalho de tal forma que nossos túneis SSH não podem ficar acordados por mais de 5 minutos sem ter um cano quebrado. Depois de reconectar, vou executar o último comando e, com certeza, esqueci que agora é exit !

    

Answer 1

O shell lerá os comandos do seu terminal (isto é, a entrada padrão do shell) até que seja solicitado a parar (inserindo o comando exit ) ou quando um fim de arquivo (EOF) for encontrado (como quando shell está executando um script).

Se você inserir o comando exit , primeiro ele será salvo no histórico e, em seguida, o shell será encerrado. Digitar ctrl - D gera um EOF; como este não é um comando, mas um estado de entrada, ele não pode ser salvo no histórico do shell.

Observe que você pode instruir bash a ignorar EOF; isso pode ser feito de duas maneiras:

• set -o ignoreeof
• IGNOREEOF = n

A primeira maneira é equivalente a fazer IGNOREEOF=10 , significando que você tem que pressionar ctrl - D 10 vezes seguidas antes que o shell saia. Isto é para evitar terminar acidentalmente a casca, e. se você digitar ctrl - C ou o que quer que seja.

Note também que ctrl - D só gera um EOF quando inserido como a primeira coisa em uma linha (ie após uma entrada), bash o ignora se alguma coisa já foi digitada na linha.

O ctrl - D também gera EOF fora do shell. Por exemplo:

$ wc
foo bar
<ctrl-D>
      1       2       8

wc contou 1 linha, 2 palavras, 8 caracteres (incluindo a nova linha).

Aqui está um exemplo com o uso de ctrl - D após alguma entrada ter sido dada na linha:

$ wc
foo bar<ctrl-D><ctrl-D>       0       2       7

Agora, wc contou as linhas zero (nenhum enter foi dado), 2 palavras e 7 caracteres. Duas seqüências ctrl - D foram necessárias porque os dados já haviam sido dados; observe que bash lida com isso especialmente (ignorando o EOF se algo já foi inserido na linha), enquanto, por exemplo, dash não. Isso provavelmente se deve ao recurso de edição de linha em bash .

    

Answer 2

Se a sugestão do @StéphaneChazelas de aumentar ServerAliveInterval não funciona (talvez tente um valor de 300 ), então você pode querer considerar algo como GNU screen ou tmux para que você possa retomar suas conexões perdidas.

Eu tenho isso perto do topo do meu ~/.bashrc em todos os meus sistemas remotos:

screen -r >/dev/null 2>&1

Isso não fará nada se você não tiver uma sessão de tela desconectada (por exemplo, se for sua segunda conexão ou se você acabou de reinicializar), mas se você tiver uma sessão de tela (que não está anexada em outro lugar), ela será automaticamente reconectada . Bam, todo o seu histórico anterior (e comandos ativos, etc.) são restaurados. (Isso pressupõe que você execute screen no seu primeiro login.)

Eu também conecto isso com uma conexão SSH em loop. Aqui está uma versão simples para ilustrar o que estou falando:

while sleep 1; do ssh remotehost; done

Dessa forma, quando você estiver desconectado, você se reconectará automaticamente (isso é transparente, supondo que você tenha uma chave ssh e esteja usando ssh-agent ou uma chave sem senha).