Fazendo um loop entre duas datas no Python

Quem trabalha com análise de dados sabe que muitas vezes é necessário agilizar o processo de organização e compreensão através de programas e scripts que sejam capazes de entender padrões. A utilização de scripts Shell são uma poderosa ferramenta e programas em linguagens de alto nível como C e FORTRAN permitem o processamento eficiente dos dados representados. Em muitas ocasiões, dependendo das suas habilidades computacionais e da sua proficiência em algum tipo de linguagem, você será capaz de trabalhar com esta(s) linguagem(ns), aplicando conceitos de forma quase exclusiva, sem a necessidade de recorrer a linguagens adicionais e tornar a solução do problema excessivamente complicada.

Continue Lendo “Fazendo um loop entre duas datas no Python”

Anúncios

Inserir espaço extra entre as colunas de um arquivo

Ah o SED (e o AWK também)!

Estava lidando com arrays escritos em arquivos texto, mas a formatação desses arquivos não era muito boa. Dependendo da magnitude do número no array, não sobrava espaço entre uma coluna e outra.

Continue Lendo “Inserir espaço extra entre as colunas de um arquivo”

Makefile (mínimo!)

Quem trabalha com programação sabe que é necessário manter tudo em ordem: não importa se o trabalho é solo ou em grupo. Além de se utilizar um software de gerenciamento de códigos (eg., CVS, Subversion, git), à medida em que o(s) código(s) cresce(m), torna-se necessário (e desejável também), a utilização de algum software para o gerenciamento do projeto (eg., Redmine, Trac). Mas no meio disso tudo – na verdade, antes disso tudo, há um pequeno pedaço de software que é responsável pela organização hierárquica de todo o projeto. Estamos falando sobre o Makefile.

Continue Lendo “Makefile (mínimo!)”

Shell: fazendo o inverso dos padrões (wildcards)

Essa dica é simples, mas é aquela que você sempre quis saber. Se você sempre soube dela, parabéns, você aprendeu o Shell direito. Ou não 🙂

Suponha que você queira listar (ou copiar, mover, apagar etc) todos os arquivos de uma pasta, cujos nomes NÃO contenham um determinado padrão.

Continue Lendo “Shell: fazendo o inverso dos padrões (wildcards)”

Teste de argumentos em Korn Shell

Quando se programa scripts no Shell, muitas vezes torna-se conveniente passar argumentos junto com o script para tornar sua execução mais dinâmica e genérica. Mas esta prática também pode trazer alguns problemas: o script pode ser executado mesmo com um argumento errado! Por isso, é importante testar os argumentos antes de se executar as funções ou comandos do script.

Neste artigo, criaremos um script Korn Shell (KSH) que contém algumas funções, que serão executadas dependendo do argumento passado pela linha de comando. As funções, por simplicidade, conterão apenas o comando “print” com uma mensagem indicando qual função foi chamada. Veja abaixo, as etapas e a lógica do teste de argumentos:

Estrutura do Script

O script que montaremos, terá a seguinte estrutura – que pode ser copiada para qualquer outro script que faça qualquer outra coisa e que receba argumentos de entrada:

#! /bin/ksh
# set -o xtrace
# Funcoes
funcao_01() {
  print "Voce escolheu a funcao_01"
}
funcao_02() {
  print "Voce escolheu a funcao_02"
}
funcao_03(){
  print "Voce escolheu a funcao_03"
}
ajuda(){
  print "Uso: ./teste.ksh <argumento>"
}
# Teste dos argumentos
if [[ $# = 0 ]]
then
  print "Erro: Nao foi passado nehum argumento!"
  ajuda
elif [[ #1 != 1 ]]
then
  print "Apenas um argumento e necessario!"
elif [[ ${1} = "funcao_01" ]]
then
  print "Executando funcao ${1}"
  funcao_02
elif [[ ${1} = "funcao_02" ]]
then
  print "Executando funcao ${1}"
  funcao_02
elif [[ ${1} = "funcao_03" ]]
then
  print "Executando funcao ${1}"
  funcao_03
else
  print "Comando desconhecido: ${1}"
  ajuda
  exit 1
fi
exit 0

O script acima pode ser dividido em duas partes: uma contendo as funções, e outra contendo o teste dos argumentos. Na primera parte há três funções definidas que são executadas apenas quando chamadas, ou melhor, quando invocadas pela linha de comando através do argumento passado. Um das funções, chama-se “ajuda” e pode ser utilizada quando nenhum argumento é passado junto com o script, quando um número errado de argumentos é passado junto com o script (por exemplo, quando é necessário apenas um argumento e dois ou mais argumentos são passados) ou quando um argumento inválido é passado junto com o script – neste caso não haveria uma função associada ao argumento passado. Na segunda parte, é feito o teste dos argumentos. Esta estrutura do script é vantajosa pois impede que comando perigosos (como um “rm -rf”) sejam executados na ausência de argumentos ou ainda na presença de um argumento errado. Geralmente, estas situações ocorrem com usuários que não têm o hábito de ler o script antes de executar.

Algorítimo dos testes

O algorítimo para o teste de argumentos é o seguinte:

  1. Teste se algum argumento é passado. Caso positivo, passa-se para o próximo teste; caso negativo, mostra-se a função “ajuda”.
  2. Teste se mais do que um argumento é passado. Caso negativo, passa-se para o próximo teste; caso positivo, mostra-se a função “ajuda”.
  3. Teste se o argumento passado está associado à função funcao_01. Caso positivo, executa-se a função funcao_01; caso negativo, passa-se para o próximo teste.
  4. Teste se o argumento passado está associado à função funcao_02. Caso positivo, executa-se a função funcao_02; caso negativo, passa-se para o próximo teste.
  5. Teste se o argumento passado está associado à função funcao_03. Caso positivo, executa-se a função funcao_03; caso negativo, encerra-se o script com status de erro (1).

Observe que os argumentos possíveis neste script têm o mesmo nome que as funções definidas: funcao_01, funcao_02 e funcao_03. Qualquer nome (ou argumento) passado junto com o script e que for diferentes destes nomes, fará com que nenhuma das funções definidas seja executada.

Conclusão

O teste de argumentos deve englobar todas as possibilidades. Neste simples caso, apenas um argumento é testado o que torna simples a estruturação dos testes. Aumentando-se o número de argumentos, a complexidade dos testes pode aumentar e é aí que o programador deve avaliar a necessidade de se utilizar muitos argumentos dentro de um script. A idéia principal é manter o script simples e enxuto.

Backup local simples com o rsync

O script abaixo tem por objetivo realizar o backup/sincronização (incremental) entre duas pastas diferentes, facilitando e agilizando p processo de cópia de grandes volumes de arquivos.

Algorítmo

O algorítmo deste script segue os seguintes passos:

  1. Verificação dos argumentos de entrada:
    1. Verifica se a quantidade de argumentos não é dois (caso postivo, mostra a função ajuda e finaliza);
    2. Verifica se a quantidade de argumentos é dois (caso positivo, verifica os locais – se são acessíveis ou não);
  2. Com os dois argumentos de entrada (origem e destino, respectivamente), chama a função backup
  3. Finaliza o script
#!/bin/ksh
#set -o xtrace
ajuda() {
print "Uso: ./backup_rsync.ksh <origem> <destino>"
 exit 1
}
backup() {
origem=${1}
 destino=${2}
rsync -av ${origem}/ ${destino}/
}
if [ $# -ne 2 ]
 then
ajuda
elif [ $# -eq 2 ]
 then
print "Verificando os locais:"
 print "${1}"
 print "${2}"
if [ ${1} == ${2} ]
 then
print "${1} e o mesmo local de destino (${2})"
 exit 1
elif [ ${1} != ${2} -a -r ${1} -a -w ${2} ]
 then
backup ${1} ${2}
else
print "${1} inacessivel ou ${2} nao pode ser escrito"
 exit 1
fi
else
ajuda
fi
exit 0

Exemplo

No exemplo abaixo, serão sincronizadas as pastas “teste1” e “teste2”, ambas presentes no mesmo diretório em que o script será executado (o que não é uma necessidade). Cada uma das pastas contém os arquivos “arquivo1” e “arquivo2”, respectivamente. O objetivo é fazer com que a “pasta2” contenha os “arquivo1” e “arquivo2”. Em qualquer caso, nenhum arquivos é apagado.

./backup_rsync.ksh teste2 teste1
 Verificando os locais:
 teste2
 teste1
 sending incremental file list
 arquivo2
sent 127 bytes received 31 bytes 316.00 bytes/sec
 total size is 0 speedup is 0.00

Observações

  • Na primeira vez em que o script for utilizado, pode ser que leve um tempo maior; depois disso, o processo de sincronização é mais rápido;
  • Na linha 17 do script, a barra no final de ${origem} e ${destino} é necessária para que o conteúdo de ${origem} seja armazenado no primeiro nível de ${destino}, caso contrário a pasta ${origem} será criada dentro de ${destino}.

Dicas para quem está iniciando em “modelagem”

A idéia deste post é mostrar algumas dicas para quem está iniciando a “rodar” modelos, seja realizando testes, seja realizando implementações. Com algum tempo trabalhando com modelagem (no meu caso em meteorologia), você acaba colecionando algumas dicas que podem ser preciosas em diversos aspectos da atividade prática da modelagem. Mas antes de mais nada, vou definir aqui que o termo “modelagem”, se refere à atividade prática (à execução da modelagem) de preparar um determinado sistema ou modelo computacional e seu respectivo ambiante de compilação/submissão, e não necessariamente a modelagem em si – que por si só tem seus desafios. Estas mesmas idéias podem ser facilmente aplicadas a situações mais simples, como por exemplo, desenvolver um programa em linguagem C, fortran ou um script shell simples que automatize algumas tarefas. É preciso ter em mente apenas começar da forma correta, o não o isenta de cometer erros (inerentes ao seu trabalho) e aprender com eles.

Pois bem, quem está começando sempre tem um pouco de pressa, ou por não saber que o processo prático da modelagem é não linear, ou porque é muito apressado e sabe que não tem muito tempo para gerar e analisar os seus resultados. Nesse caso, há um caminho bastante longo e complicado entre “gerar” e “analisar” os resultados. Muitas vezes, gerar os resultados pode parecer um alívio, mas se eles não foram gerados da forma correta, podem lhe trazer muita dor de cabeça. Então, para começarmos, vamos colocar os tópicos desta discussão na seguinte ordem:

  1. Cheguei agora, o que faço?
  2. Certo, agora que já comecei, o que faço?
  3. Deu pau, o que faço?
  4. Deu pau de novo, o que posso fazer?
  5. Acho que agora está dando certo…, o que faço?
  6. Meu primeiro resultado! E agora, o que faço?
  7. Meu tempo acabou, o que faço?
  8. Outras dúvidas…

Certamente, poderiam haver outros “… e agora, o que faço?”, mas com certeza estes sete tópicos são bastante representativos do processo prático da modelagem como um todo e certamente podem lhe ajudar. Portanto, entenda este texto como uma espécie de “auto-ajuda” da prática da modelagem (antes que você tenha que recorrer à alguma ajuda externa) ou um “caminho-zen” para as suas atividades em modelagem.

1. Cheguei agora, o que faço?

Com certeza, essa é a sua primeira dúvida quando não se tem experiência prévia na prática do seu trabalho de pesquisa. Geralmente, a iniciação científica nos serve como uma espécie de laboratório com experimentos controlados em que não se assume a responsabilidade por um determinado resultado, ou melhor, aprende-se – num espaço curto de tempo, a colocar a mão na massa. Mas nem sempre, quem faz iniciação científica, acaba trabalhando com os mesmo temas em pesquisas futuras. Nesse momento, as dúvidas e aflições de quem está começando são, frequentemente, as seguintes: “putz, vou ter que mexer no linux…”, “putz, vou ter que mexer no terminal do linux…”, “putz, vou ter que trabalhar com programação…”, “putz, vou ter que trabalhar com o cluster…”, “putz, vou ter que trabalhar com o supercomputador…” etc. Na verdade, a grande sacada nesse momento é não se aborrecer e nem se preocupar com o tal do linux e seu terminal, até porque – dependendo da área em que você trabalhe, vai acabar percebendo que ao invés dele ser um vilão, ele será a melhor ferramenta com que você vai trabalhar. Dito isto, comece a se preparar fazendo-se as seguintes perguntas:

Se eu vou trabalhar com um modelo computacional ou um programa fortran, ou script do matlab etc, onde ele(s) está(ão)?

Essa é a primeira coisa que você tem que se perguntar. Se isso lhe parecer um pouco óbvio demais, saiba que se você não for cuidadoso(a) a partir daqui, os seus problemas podem começar logo de início. Se você for trabalhar no linux (sendo no seu computador/notebook, em um cluster ou em um supercomputador), com certeza terá que lidar com o terminal. Por isso, pesquise com os seus colegas de trabalho onde pode-se obter o modelo ou programa com que você vai trabalhar. Não se preocupe demais com o terminal e os seus comandos, com certeza você vai aprender praticando.

Sempre, eu eu disse SEMPRE, a melhor situação é quando você pode trabalhar com repositórios (em cvs, svn, git, bazar etc).

Os repositórios são importantes porque permitem que você crie um histórico de alterações e de versões dos seus scripts e rotinas que for trabalhar/criar/modificar. Além disso, ele vai lhe ajudar naquele momento em que você estiver escrevendo um relatório ou em que precisar lembrar de uma determinada data em que modificações ou implementações foram realizadas. Portanto, nessa primeira situação, pergunte a seus chefes, colegas, orientadores se o código com o qual você for trabalhar está em um repositório e em que tipo de repositório. Pergunte também se você pode criar um ramo (repositório) próprio para realizar os seus desenvolvimentos. Com certeza, essa é a melhor maneira de se iniciar o trabalho com códigos computacionais em sistemas e modelos. Para exemplos de utilização do svn, por exemplo (eu aprendi a trabalhar com o svn), leia este post sobre a criação de um repositório svn em sua máquina local (https://craftmind.wordpress.com/2011/04/25/criando-um-repositorio-svn-local/) e este sobre como utilizar o svn (http://samuca.wordpress.com/2007/04/12/tutorial-subversion/).

2. Certo, agora que já comecei, o que faço?

Se você já sabe onde está o código ou modelo com que vai trabalhar, agora é o momento de aprender a instalar/utilizar/testar o seu código. Todo código que tem um desenvolvimento ordenado e, por mais simples que seja, deve ter um README ou um LEIAME com a descrição do programa, notas de versão, bugs conhecidos e – principalmente, como instalar/utilizar/testar. Este trio (instalar/utilizar/testar) é essencial e deve ser seguido antes que qualquer outro tipo de teste seja feito com o código que você vai trabalhar. Procure saber se há uma conjunto de dados de teste (geralmente um conjunto pequeno de dados que permita testar todos os aspectos do programa).

Leia o README, siga as instruções, tire suas dúvidas e quando se sentir confortável o suficiente para começar, inicie o trio instalar/utilizar/testar.

3. Deu pau, o que faço?

Tem certeza de que leu o README por completo? Tem certeza de que não surgiram dúvidas? Se alguém lhe deu uma explicação e você não entendeu muito bem, volte e pergunte novamente. Não se acanhe! Quanto menos dúvidas você tiver sobre o processo de instalar/utilizar/testar, melhor. Assim você poderá se preocupar menos com os aspectos práticos do sistema e mais com os aspectos teóricos da sua pesquisa. Caso todas as informações do README e as instruções que lhe foram fornecidas tenham sido completamente atendidas, então o problema pode ser outro. Será necessário ler todos os logs do sistema e procurar por erros desconhecidos ou que, por uma razão ou outra, ainda não foram relatados.

Inclusive, esta pode ser uma oportunidade para que você colabore com os desenvolvedores do sistema que você está utilizando.

4. Deu pau de novo, o que posso fazer?

Se o problema persiste ou lhe parece ser algo sistemático (que está se repetindo sempre, da mesma forma), pode ser que o problema não seja com o seu sistema, mas sim com a máquina em que está sendo executado.

Lembre-se que assim como o seu computador, qualquer sistema – por mais moderno e seguro que seja, ele é suscetivel a problemas de software e hardware diversos. Se você tiver certeza de que os problemas não fazem parte do seu sistema (dos modelos/rotinas/scripts), entre em contato com o administrador da máquina que você está utilizando.

Se você está utilizando apenas o seu computador, não perca tempo e peça ajuda a alguém mais experiente. Geralmente, problemas de compilação estão relacionados à variáveis de ambiente mal ajustadas e programas que não estão completamente instalados. Se você depende de algum tipo de biblioteca que não é fornecida com o seu sistema, leia este post para uma explanação geral sobre a instalação de programas a partir do código fonte no linux (https://craftmind.wordpress.com/2011/04/25/variaveis-de-ambiente-para-programas-fonte/).

5. Acho que agora está dando certo…, o que faço?

Com muita sorte, as coisas dão certo logo de primeira ou pelo menos nas primeiras tentativas. Se não derem certo de primeira e você teve que queimar uma pouco da sua preciosa mufa para resolver, parabéns: com certeza você aprendeu mais coisas do que esperava. Uma vez que as coisas começam a fluir e a funcionar de forma como tem que ser (ou pelo menos da forma como se espera), fique atento com a performance do seu modelo/programa e veja se os resultados preliminares (on the flie) estão razoavelmente dentro do que se sabe/conhece. Geralmente os modelos computacionais geram saídas de log e erro a partir das quais pode-se acompanhar os valores calculados de uma determinada variável ou o tempo que está demorando para realizar algum cálculo. Observando estes aspectos, você poderá ser capaz de identificar problemas como: valores espúrios, situações fisicamente impossíveis, instabilidade numérica, problemas de paralelismo etc. Este tipo de diagnóstico pode lhe poupar horas, dias ou até semanas de trabalho! Imagine a situação em que um modelo numérico de previsão de tempo é empregrado para integrar uma condição inicial durante sete dias. Atualmente, dependendo de onde o modelo está sendo executado, este trabalho pode demorar de horas a dias e se você não se preocupar em olhar os valores que estão sendo escritos no log do sistema, só vai perceber que alguma coisa está errada no final.

Portanto, fique atento aos logs e aprenda a interpretar os valores e resultados preliminares. Ah, não se engane com as médias!!

6. Meu primeiro resultado! E agora, o que faço?

Ótimo, se você conseguiu chegar até aqui, já deve ter alguma bagagem com coisas interessantes que aprendeu sobre o processo prático da modelagem. No caso dos resultados de modelo, certamente haverá um arquivo final com os valores/campos e, dependendo do sistema empregado, esse arquivo poderá ser convertido para um formato padrão (por exemplo, grib, netcdf, hdf etc) que, além de ocupar menos espaço, já disponibiliza o arquivo final para visualização em um software específico (por exemplo, o GrADS). Geralmente, o conjunto dessas rotinas de conversão é chamada de pós-processamento e geralmente, são feitas interpolações e outros procedimentos matemáticos que podem embutir pequenos erros oriundos de aproximações. Fique atento às fontes de erros nos seus resultados e saiba ponderá-las em sua avaliação. Procure também comparar os dados brutos (antes do pós-processamento) com os dados finais (pós-processados).

Certamente, estas informações podem lhe assegurar um controle e visão melhores sobre os resultados que você obteve.

Ao sinal de qualquer dúvida sobre os resultados gerados, se você tiver tempo, refaça os experimentos e tire suas dúvidas. Além disso, a avaliação estatística e/ou interpretação física dos resultados deve ser feita de forma bastante consistente. Leve em consideração os tipos de avaliação que outros pesquisadores estão fazendo e tente comparar os seus resultados com os deles. Isso ajuda e muito na validação dos seus experimentos e também vai lhe assegurar que a sua metodologia não contém falhas.

7. Meu tempo acabou, o que faço?

Isso vai acontecer e, geralmente no mestrado – em que se tem pouco tempo para executar a parte prática, você pode se desesperar com a qualidade dos seus resultados.

Se você tomar todos os cuidados e rever sempre os seus passos, dificilmente passará por algum problema por culpa sua.

Acredite, erros todos comentem e perder o tempo que se tem para uma determinada tarefa, é o pior deles. Então, tome os devidos cuidados e extraia o máximo que puder do aprendizado da prática de modelagem. Com certeza, numa outra oportunidade, você estará mais calejado e esperto para enfrentar novos desafios e saberá como começar…

Outras dúvidas…

Na verdade, este tópico não é sobre dúvidas, mas sim recomendações. Sempre que você estiver desenvolvendo algo, seja minucioso, documente tudo o que você está fazendo. Se a sua memória é fraca, certamente você estará se livrando de um imprevisto ou de ter que bolar uma solução para um problema que você já resolveu. Para as rotinas e scripts que você escrever, utilize o Doxygen ou o ProTeX para gerar a documentação. É justo com você, porque agrega valor ao seu trabalho e justo com quem vai colaborar ou dar continuidade aos desenvolvimentos que você iniciou. Lembre-se que linguagem de máquina é para máquina, humanos lêem textos.

Se ao escrever a documentação você ficar na dúvida se escreve em português ou em inglês, não exite: escreva em português.

Sempre tem alguém que diz “tem que escrever em inglês porque se houver alguma colaboração de fora, todos têm que entender”. Isso está correto, desde que se saiba escrever corretamente em inglês… não adianta nada escrever em inglês se apenas os nativos procurarem a documentação para ler, e vai ser pior se estiver em inglês mal escrito. Portanto, a menos que alguém se disponha a revisar a documentação, escreva em bom português mesmo. Vale lembrar que a documentação, além de ajudar no entendimento dos seus programas, ajuda também a escrever o trabalho final ou relatório.

Ao escrevermos, sempre confrontamos e revisamos idéias anteriores e fixamos o que sabemos.

Boa sorte!

PS.: Este texto deverá ser melhorado ao longo do tempo.

Minha lista de comandos úteis no shell do linux

Depois de algum tempo fazendo scripts e tentando lançar uma solução aqui e ali, montei uma lista de alguns comando do shell do linux que me quebram uma galhão. Espero que lhe ajude também! Só para melhorar a diagramação dos comando, coloquei alguns “\n” para quebrar a linha, mas você suprimir esta parte e colocar tudo em uma linha só:

1. Operações de busca com o comando find

$ find <diretorio> -name ""

Exemplos:

1.1 Procurar arquivos com o nome “run” na pasta atual em diante

 $ find . -name "run" 

1.2 Procurar arquivo com a extensão “.ksh” na pasta /etc

 $ find /etc -name "*.ksh" 

1.3 Procurar por links simbólicos na pasta atual em diante

 $ find . type -l 

1.4 Procurar por links simbólicos na pasta atual em diante, com saída formatada (indicando a origem e o destino do link)

 $ find . -type l -printf "%p -> %l\n" 

1.5 Apagar todos os links simbólicos encontrados utilizando o comando xargs

 $ find . -type l | xargs rm -rf 

1.6 Procurar todos os arquivos de nome “monitor.t” em pastas com nome sequencial formatado de “001” a “040”, na pasta atual

 $ for pasta in $(seq -f "%03g" 1 40); do echo $pasta; cd $pasta; \n 
 if test ! -e monitor.t; then echo ">>> $pasta falhou"; fi; cd -; done 

2. Operações de pesquisa em arquivos com o comando grep

$ grep <opcoes> <expressao> <arquivo(s)>

Exemplos:

2.1 Pesquisa recursiva pela expressão “letkf” em todos os scripts ksh na pasta atual em diante

 $ grep -R "letkf" *.ksh 

2.2 Pesquisa recursiva pela exporessão “letkf” ou “LETKF” (ou uma mistura de maiúsculas/minúsculas) em todos os scripts ksh na pasta atual em diante

 $ grep -iR "letkf" *.ksh 

3. Operações com arquivos utilizando o comando awk

 $ awk <opcoes> <comandos> <arquivo>

ou

 $ cat <arquivo> | awk <opcoes> <comandos>

Exemplos:

3.1 Filtrando um arquivo com colunas separadas por espaços, mostrando apenas a coluna “n”

 $ cat <arquivo> | awk -F " " '{print $n}'

4. Operações com arquivos utilizando o comando sed

 $ sed <opcoes> <comandos> <arquivo(s)>

ou

 $ cat <arqvuivo> | sed <opcoes> <comandos>

Exemplos:

4.1 Substituindo todas as ocorrências da string “A” pela string “B” em todos os scripts .ksh (apenas na pasta atual)

 $ sed -i "s,A,B,g" *.ksh 

4.2 Comentando a linha “n” em um arquivo (comentário é dados por #)

 $ sed -i 'ns/^/#/' 

4.3 Inserindo um comentário na primeira linha de um arquivo

 $ sed -i "1s/^/# Comentario/" > 

5. Criando uma sequência de números no shell com o comando seq

 $(seq <inicio> <fim>)

Exemplos:

5.1 Imprimir no shell a sequencia de 1 a 20

 $ echo $(seq 1 20) 

6. Operações com loops no shell:

Comando for; do; done

Exemplos:

6.1 Imprimir a sequência de 1 a 30 utilizando o comando de laço for

 $ for i in $(seq 1 30); do echo $i; done 

6.2 Renomear todos os arquivos com extensão .txt adicionando uma nova extensão .dat

 $ for i in `find . -name *.txt`; do mv ${i} ${i}.dat; done 

6.3 Alterar todos os arquivos com a extensão .TQ0213L042 para .T213L42, utilizando o for e o sed

 $ for arq1 in `ls *.TQ0213L042`; do arq2=`echo ${arq1} | sed "s,TQ0213L042,T213L42,g"`; \n 
 cp ${arq1} ${arq2}; done 

Comando until; do; done

Exemplos:

6.4 Aguardar até que um arquivo esteja disponível

 $ until [ -e <arquivo> ]; do sleep .1s; done

Comando if; then; fi

Exemplos:

6.5 Verifica se uma pasta existe; se não existir, cria, se existir sai do teste

 $ if test ! -s <pasta>; then mkdir -p <pasta>; fi

6.6 Lê um lista chamada “lista” com os nomes das pastas que contém um script de submissão, dá permissão de execução e executa

 $ for i in `cat lista`; do cd $i; chmod +x qsub_interface.g2s.$i; \n 
 ./qsub_interface.g2s.$i; cd -; done

Comando while; do; done

6.6 Faz um loop em cima de datas; verifica se a primeira data é menor ou igual do que a segunda. Quando esta condição é alcançada, sai do loop

 $ while [ <data_inicio> -le <data_fim> ]; do <operacoes>; done

Referências Úteis:

Valor Máximo e Mínimo em um arquivo

Esses dias estava precisando saber qual era o valor máximo e o mínimo dentro de um arquivo com centenas de números. Em Korn Shell, não há uma função reservada para fazer este tipo de verificação, então tive que procurar algum script que o fizesse. Acabei encontrando um por aí que não fazia exatamente o que eu queria, mas que comparava dois números inteiros. Dei uma modificada e acabei com isso aqui:


#! /bin/sh

#set -o xtrace

max=0

while read valor

do

val="$(echo ${valor})"

if [ ${val} -gt ${max} ]

then

max=${val}

fi

done < teste

min=${max}

while read valor

do

val="$(echo ${valor})"

if [ ${val} -lt ${min} ]

then

min=${val}

fi

done < teste

echo "valor maximo e ${max}" echo "valor minimo e ${min}"

Para testar, basta escrever alguns valores (um por linha) em um arquivo texto chamado teste e executar o script na mesma pasta 😉