Posso gerar um novo terminal que é um clone do terminal atual?

8

Então, digamos que estou desenvolvendo código no diretório / asdf / qwer / dfgh / wert / asdf / qwer e adicionei mais três diretórios como esse ao meu caminho e tenho várias variáveis de ambiente misteriosas definidas. Então percebo que realmente preciso de outro terminal aberto e configurado da mesma maneira (embora essa necessidade não seja recorrente, para que eu apenas alterasse meu .bashrc). Existe algum comando para abrir uma nova janela de terminal que seja um clone exato dessa?

shell terminal environment-variables

— John Berryman
fonte

10

A clonagem do caminho é fácil se você puder executar o programa do terminal na linha de comando. Supondo que você esteja usando xterm, basta executar a xterm &partir do prompt do terminal que você deseja clonar. O novo xterm será iniciado no mesmo diretório, a menos que você o tenha configurado para iniciar como um shell de login. Quaisquer variáveis de ambiente exportadas também serão transferidas, mas variáveis não exportadas não serão.

Uma maneira rápida e suja de clonar todo o ambiente (incluindo variáveis não exportadas) é a seguinte:

# from the old shell:
set >~/environment.tmp

# from the new shell:
. ~/environment.tmp
rm ~/environment.tmp

Se você definiu alguma opção de shell personalizada, precisará reaplicá-las também.

Você pode agrupar todo esse processo em um script facilmente executável. Faça com que o script salve o ambiente em um arquivo conhecido e execute xterm. Faça com que o seu .bashrc verifique esse arquivo, origine-o e exclua-o, se encontrado.

Como alternativa, se você não deseja iniciar um terminal a partir de outro, ou apenas deseja mais controle, poderá usar um par de funções definidas em .bashrc:

putstate () {
    declare +x >~/environment.tmp
    declare -x >>~/environment.tmp
    echo cd "$PWD" >>~/environment.tmp
}

getstate () {
    . ~/environment.tmp
}

EDIT : Alterado putstatepara que ele copie o estado "exportado" das variáveis do shell, para corresponder ao outro método. Há outras coisas que também podem ser copiadas, como opções de shell (consulte a help set) - para que haja espaço para melhorias nesse script.

— Jander
fonte

Uau ... explicação legal que levou a algumas idéias que eu tive antes.

— John Berryman

Modifiquei o script para pegar um argumento e colocar o put e obter o ambiente em um arquivo nomeado pelo argumento ... agora posso ter vários ambientes! : D

— John Berryman

Pergunta: o que significa "." fazer em getstate?

— John Berryman

O "." diz: "Execute o conteúdo deste arquivo usando o shell atual, como se eles fossem digitados na linha de comando". Sem o ".", Uma nova cópia de bashexecutaria os comandos no arquivo e sairia, e o ambiente atual do shell não mudaria.

— Jander

0

Se você iniciar um screen(Tela GNU) em seu ambiente definido, esse ambiente será usado pelo subprocesso (ou seja screen) e você poderá usá-lo para gerar novos terminais. Mas se você quiser bifurcar outra vez (a screenem a screen), isso começará a ser complicado.

— shellholic
fonte

0

Em uma situação semelhante, também achei útil iniciar o novo shell no mesmo diretório que o atual. Eu usei uma receita como esta para iniciar o shell.

exec ssh -t $HOST "cd $DIR; $SHELL $parms"

A opção -t é necessária sempre que você executa explicitamente um shell usando ssh. Faz com que um pseudo-tty seja criado para o processo. Isso é necessário para que os comandos do histórico e outros recursos interativos funcionem corretamente. As linhas anteriores do script definem DIR no diretório atual e SHELL no shell preferido do usuário.

— Chris Quenelle
fonte

0

enquanto as variáveis exportadas chegam ao outro lado usando a função 'getstate' acima, por algum motivo elas acabam não sendo exportadas para lá (como pode ser visto usando um simples os.getenv do python). parece funcionar melhor para mim ao modificar o getstate para ser um alias:

alias getstate=". ~/environment.tmp"

— srepmub
fonte