No Vim, quais são as diferenças entre usar: sus e: sh para acessar o shell sem finalizar a sessão do Vim?

Question

Eu sei que, embora no Vim (e no Vi, também acho), se eu quiser acessar temporariamente o shell, posso fazer uma de várias coisas:

• Use :sh (a.k.a. :shell ) e, em seguida, efetue logout do shell para retornar ao Vim
• Use :sus (a.k.a. :suspend , :st ou :stop ) e use fg para retornar ao Vim
• Use :! <command> para passar comandos pelo Vim para o shell
• Use :mksession <filename> para salvar uma sessão, encerrar o Vim e restaurar a sessão com :source <filename> após retornar ao Vim (admitidamente, isso provavelmente é muito complicado para a maioria das necessidades de acesso "temporário" ao shell)
• Use software de janelas, como screen, tmux, etc.

Minha pergunta é: quais são as diferenças técnicas e práticas das duas primeiras opções - usando :sh vs. usando :sus ? Nas páginas de ajuda do Vim, parece que a única diferença é que, com :sus , você escreve automaticamente o buffer (se 'autowrite' estiver configurado) ou corre o risco de perder seus buffers editados se nunca retornar ao Vim, enquanto :sh você não tem escolha a não ser retornar à sua sessão do Vim quando sair do shell.

Existem outras diferenças, seja tecnicamente (como uso da memória e do processador) ou razões relacionadas à produtividade, pelas quais um usuário do Vim pode escolher um método sobre o outro em situações diferentes?

    

Answer 1

Para mim, a maior diferença entre :suspend e :shell é que, com o primeiro, você retorna ao shell original , enquanto o segundo inicia um novo subshell . Isso significa que variáveis de ambiente (não exportadas) estão disponíveis no primeiro, mas não no segundo. Do ponto de vista do desempenho, dependendo da sua personalização (por exemplo, em ~/.bashrc ), a inicialização de um novo shell pode apresentar um atraso perceptível.

Em geral, não há resposta certa ou errada à sua pergunta. Vim (como é derivado da filosofia Unix) permite que você encontre e escolha seu próprio estilo. Pessoalmente, eu sempre faço grandes edições no GVIM e uso apenas o console Vim para edições curtas e táticas (por exemplo, uma mudança rápida nos arquivos de configuração). Eu também sempre tenho múltiplos terminais abertos, então eu prefiro mudar para outro terminal com Alt + Tab do que o shell out do Vim.

    

Answer 2

Usar :sh cria um novo processo - um processo filho do processo vi - e executa um novo shell. :sus coloca o editor em um estado suspenso e permite que o processo pai (normalmente, seu shell de login ou o shell principal na janela) retome o controle. Portanto, :sh usa marginalmente mais recursos. Mas a maior diferença é que se você executar :sh e, em seguida, cd (diretório de mudanças), definir uma variável de shell / variável de ambiente, alterar um limite de processo ( ulimit ) ou qualquer outra coisa que afete diretamente o shell então esses efeitos desaparecerão quando você retornar ao editor (ao sair do shell). Por outro lado, se você voltar ao seu shell principal, os efeitos ainda estarão lá quando você sair do editor.

A resposta de Ingo sobre as variáveis de shell (não exportadas) no shell pai que não estão disponíveis na subshell também está correta.

Ah, outra coisa: :sh provavelmente fornecerá uma instância do shell nomeado por $SHELL . Se a sua shell pai é algo diferente, então, obviamente, isso será outra diferença.

Editar:

Oh, outra coisa que eu pensei: dependendo do shell que você está usando (bash, C shell, zsh, etc.) e quais configurações você tem em vigor, uma subshell provavelmente não terá acesso ao shell principal. histórico de comandos (por exemplo, !-2 ou ↑ ↑ ). Como um corolário trivial, que você provavelmente já observou, o fg que você deve digitar para voltar ao editor depois de um :sus ser adicionado ao histórico de comandos do shell principal. Eu costumo salvar e sair do editor, e depois digo imediatamente para mim mesmo: “Oh! Esqueci de mudar «Humpty» para «Dumpty». », E digite !! Enter para voltar ao editor, apenas para ser pego de surpresa pelo fato de que !! aparece o comando fg . No bash, você pode evitar isso configurando HISTIGNORE para fg (ou adicionando fg , delimitado por um : , para sua lista HISTIGNORE existente, se houver).