Evita o fork fork ao usar comandos interativos (como script) em .bashrc

Question

Eu sempre quis registrar a saída do Terminal. Então, tentei definir script para ser executado na inicialização; no meu arquivo .bashrc eu coloquei:

script ~/Logs/$(date "+%Y-%m-%d.%H-%M-%S")

Como os comandos do meu arquivo .bashrc são executados sempre que eu abro um terminal interativo, achei que isso faria o que eu queria.

No entanto, como o script abre um novo terminal durante a execução, eu acabei com uma fork fork:

Last login: Sat May  9 12:02:43 on ttys001
Script started, output file is /Users/mchenja/Logs/2015-05-09.12-14-37
Script started, output file is /Users/mchenja/Logs/2015-05-09.12-14-37
Script started, output file is /Users/mchenja/Logs/2015-05-09.12-14-37
Script started, output file is /Users/mchenja/Logs/2015-05-09.12-14-37
Script started, output file is /Users/mchenja/Logs/2015-05-09.12-14-37
Script started, output file is /Users/mchenja/Logs/2015-05-09.12-14-37
[mchenja@mycomp ~]$

Alguma dica sobre como garantir que script seja executado exatamente uma vez quando eu abrir um novo terminal interativo?

Se isso importa, isso é no OS X, embora eu acredite que a mesma coisa aconteceria no Linux.

    

Answer 1

Eu refleti sobre a resposta do @Thomas Dickey através da "variável guarda" e sua situação. Há algumas coisas complicadas acontecendo aqui e isso depende do seu ambiente.

Se você estiver logado em uma estação de trabalho executando o X windows, quando você efetuar login, o arquivo .bash_profile será lido (normalmente, embora eu não possa dizer com certeza sobre todas as edições do Linux; ele também depende do seu shell de login) . Isso iniciaria sua sessão script , então isso é uma coisa ruim. Além disso, quando você logar em um terminal a partir do X, ele não lerá .bash_profile , mas somente .bashrc , a menos que você diga ao software do terminal para avisar que é um shell de login, caso em que acontece exatamente o oposto.

Então, aqui estão algumas dicas:

• Use $ SHLVL para determinar se você está em uma chamada de "nível superior" do bash, ou possivelmente em uma sessão de login do X, ou possivelmente dentro de um prazo / prompt de comando no X (ou talvez no console!). Você pode usar o comando tty para distinguir entre o login do console e o login do terminal ( tty |grep -q ^/dev/tty && echo "is console" )
• .bash_profile será lido apenas uma vez por login session ... normalmente. Você também pode forçar sua leitura chamando bash com -l .
• Se for um shell de login, .bashrc não será lido automaticamente. Você o executa ao fazer o sourcing de dentro de .bash_profile .
• Acredito que você deseja garantir que script não seja reentrante. Ou seja, se você estiver em um shell com script em execução e criar um sub-shell, não será necessário que script seja executado novamente.
• O que acontece se você executar screen em script ?
• screen tem um recurso de registro que pode ser mais adequado que o script. Então você tem outros problemas como, o que acontece quando você tem várias janelas de terminal abertas? Cada um deles tem uma sessão de tela separada?

Answer 2

Você teria que definir sua própria variável especial para ser testada em .bash_profile , por exemplo,

if [ -z "$IN_MY_SCRIPT" ]
then
    export IN_MY_SCRIPT=$(date)
    script ~/Logs/$(date "+%Y-%m-%d.%H-%M-%S")
fi

    

Answer 3

Estou respondendo a pergunta "evite garfo bomba" no título, não aquela que você realmente perguntou. ;)

Coloque os limites nproc em /etc/security/limits.conf impostos pelo PAM.

Apenas uma sugestão:

 *        soft   nproc   500
 %users   soft   nofile  256

Mas isso pode simplesmente estragar com algo como o Apache ou o MySQL.