Todos os subprocessos são Bash (!),

Question

Eu estava tentando usar o GDB, e descobri que sempre que ele tentava gerar o programa que eu estava depurando, o Bash era gerado (o GDB diria starting myProg... e então o Bash apareceria. Quando eu matei o Bash, estar de volta no GDB, o que me diria o status de saída do Bash). No começo eu pensei que era um problema bizarro com o GDB, mas depois descobri que tentar gerar um processo a partir do Vim também gerava o Bash.

Através de um estranho flash de inspiração eu conectei este problema com o fato de que meu shell padrão é o Tcsh, e como eu não tenho permissão para alterá-lo, eu simplesmente configurei meu .tcshrc para conter exec bash . Quando mudei para bash ou usei apenas Tcsh o problema desapareceu.

Eu não tenho absolutamente nenhum insight sobre como a coisa Tcsh leva ao meu problema. Alguém poderia fornecer algum?

Como um aparte, consegui uma correção temporária executando o GDB por PATH="" /usr/bin/gdb em vez de apenas gdb . Ele cuspiu bash: command not found e, em seguida, começou a gerar o programa que eu queria depurar.

    

Answer 1

Eu acho que o motivo é claramente que gdb usa um shell para gerar processos.

O Vim faz isso com certeza ( help ! )

:!{cmd}         Execute {cmd} with the shell.

Então, quando dizemos que :!ls -l Vim executará de fato

$ SHELL -c 'ls -l'

Eu acho que (dado que eu entendi sua configuração hackish corretamente) você pode consertá-la facilmente executando exec bash -l em vez de exec bash .

A razão é que exec bash (não sendo shell de login) não alterará a variável de ambiente SHELL , que mais tarde será usada por gdb e vim e apontará para seu shell de login ( tcsh ). Eles devem usar seu shell de escolha ( bash ) diretamente.

NOTA: Você pode pensar no que acontece quando você executará algum programa escrito em tcsh . Provavelmente não se comportará como esperado.

    

Answer 2

A explicação das outras respostas está bem.

Como solução, eu configuraria export SHELL=bash muitos comandos como gdb ou screen para usar essa variável para determinar que tipo de shell usar para gerar comandos.

Portanto, bash é usado diretamente para gerar seu comando ao invés de tcsh, que é configurado para apenas iniciar o bash.

Você pode melhorar sua configuração usando uma chave ssh para acessar o servidor e adicionar um comando forçado à sua chave no arquivo authorized_keys.

Desta forma, você pode iniciar diretamente no bash, mas não quebrar nenhum script tcsh.

    

Answer 3

No seu arquivo .tcshrc, você pode agrupar seu exec bash assim:

if ($?prompt) then
    exec /path/to/bash
endif

$?prompt será falso para shells não interativos, então o bash é usado apenas quando você tem uma sessão interativa.

    

Answer 4

Eu suspeito que o que está acontecendo é quando você executa um programa de dentro do GDB, ele está lançando um subshell para rodar esse programa e, assim, origina esse arquivo rc.

a página exec man diz que "A família de funções exec () substitui a imagem do processo atual por uma nova imagem de processo"

Eu acho que o que está acontecendo é quando você chama exec no arquivo rc, ele substitui o que você quer executar com o bash e, quando você sai, você retorna ao GDB com o código de saída bash. Se você quiser usar exec com bash e fazer seu programa rodar, você provavelmente precisará descobrir onde o equivalente de tash do Bash's argv está armazenando a chamada do programa para o que quer que você queira rodar e passar para o bash.

Você também pode se interessar por esse arquivo rc e inspecionar o argv e determinar se está tentando executar um programa, ou apenas obter um shell de login e fazer um comportamento diferente com base nisso.