Capture o conteúdo da tela para análise de erro

3

Eu sou um administrador de banco de dados que trabalha com o DB2 no AIX. (Por favor, continue a ler, pois isso está relacionado mais com o ksh do que com o DB2; caso contrário, eu teria postado isso em dba.stackexchange.com .) Eu estou tentando escrever scripts ksh para vários de nossa implementação de banco de dados, bem como scripts de manutenção de banco de dados.

Estou no processo de colocar o tratamento de erros em nossos scripts para saber se algo requer ou não uma falha grave ou apenas uma mensagem de aviso ou pode ser ignorado.

Com a maioria das tarefas relacionadas ao AIX / ksh, posso verificar $? = 0 , mas não o DB2. A menos que o mecanismo de banco de dados falhe, nunca receberei nada além de um zero. O DB2, no entanto, retornará ao console seus códigos de erro / aviso / info.

Como sei que posso obter esses códigos por meio do console, estou tentando capturar o que estiver no console para um comando específico no DB2. Depois disso, envio essa saída para uma função em que uso egrep e expressões regulares para determinar se preciso falhar ( exit 1 ) ou ter êxito ( exit 0 ) no meu script. Eu também tendem a canalizar todas as saídas do meu script para tee , pois vários dos meus scripts são longos e / ou chamam vários outros scripts. Dessa forma, eu tenho um registro de todo o "job" executado tanto para referência quanto para a solução de problemas dos meus scripts.

Recentemente, aprendi que posso ksh blah.sh 2 > &1 | tee mylog para garantir que eu capture erros de sintaxe com meu script.

Eu estou querendo saber qual é a melhor maneira de lidar com esse tipo de análise de erros no ksh? Eu tentei alimentar um comando para o DB2 com a opção -v (que é suposto para reproduzir o comando de volta para a tela, bem como os resultados do comando) e colocar isso em uma variável, mas na verdade eu não entendo o comando é enviado para a tela. Exemplo:

RESULT=$(db2 -v drop table blah)

Acabo tendo que usar cat ${RESULT} para fazer com que minha tela seja impressa para o meu canal acima e depois ainda preciso passar RESULT para minha função de análise.

Outra coisa que tentei é canalizar o resultado do meu comando para um arquivo também. Exemplo:

db2 -v drop table blah | tee myResult

Isso irá gerar uma saída para a tela do meu tee de alto nível, mas agora eu tenho um arquivo extra no sistema de arquivos que eu tenho que me preocupar em limpar depois (embora eu possa egrep e cat sem problemas) . E se o meu trabalho em algum momento falhar em canalizar para tee no script e ele próprio estiver sendo canalizado para tee resulta em algum comportamento funky (funciona bem se tiver êxito sem travar). Isso me leva a acreditar que o pipe duplo para tee não é a melhor opção.

Alguém mencionou para mim o comando script , mas não tenho certeza se isso ajudará ou não?

Alguma ideia ou pensamento? Estou assumindo que não sou o único que procura usar "captura de tela" de comandos específicos para análise de erros enquanto ainda canaliza tudo para tee para toda uma execução de tarefa.

Também tenho a tendência de invocar sub shells com meus sub-scripts em vez de chamá-los como se estivessem no mesmo shell (ou seja, ksh blah.sh vs . ./blah.sh ). Parece que funciona melhor para os meus scripts. Não tenho certeza se isso afeta qualquer resposta ou não.

Qualquer direção baseada na experiência seria apreciada.

    
por Chris Aldrich 27.12.2012 / 21:50

1 resposta

1

Não há motivos para usar tee ou script . A menos que você esteja procurando fazer a análise após o fato e off-line.

script capturará a saída de texto da sua sessão de shell e a colocará em um arquivo typescript por padrão, mas não necessariamente. Anexar ou substituir é com você.

tee permite que você copie a saída do comando em execução para um arquivo e permita que ele apareça na tela também.

A minha preferência pessoal seria:

<command> 2>&1 > <filename>

se você precisar de logs das transações que você possa analisar posteriormente. Se você precisar analisá-los enquanto o command estiver sendo executado, isso seria mais inteligente do que simplesmente despejar a saída em um arquivo:

<command> | <script> 2>&1 > <filename>

Desta forma você pode ter o script despejar a saída seletiva ou completamente em um arquivo e executar outras tarefas como notificação (email, sms, paginação, notificação de software de monitoramento) sem parar o command .

Se você quiser assistir ao que está acontecendo agora no arquivo, coloque o trabalho em segundo plano:

<command> 2>&1 > <filename> &

e apenas siga o

tail -f <filename>

Eu diria que a saída é texto e não apenas códigos de mensagem.

    
por 28.12.2012 / 15:27