Redirecionando erros no shell

Esta semana que estive meio afastado das conexões internet, comecei algumas manutenções no meu notebook que eu acabo não fazendo enquanto estou em casa.
Isto, lógico advém das diversas coisas que temos on line e que acabam nos tirando a atenção para o que realmente vale para manter nossa infra funcionando.
Tenho um script em minha máquina que faz um backup de alguns dos meus dados para uma conta on line na Dreamhost. Outros dados eu também tenho replicados em minha conta da Dropbox e por aí vai.
Falta-me hoje, somente para ter uma estrutura mais confiável, aumentar meu HD de 160GB para 250GB e comprar um HD externo de 500GB e tudo vai ficar numa boa.
Este script que eu citei carecia de um controle de erros mais apurado. No fim, a única coisa que eu andava fazendo era redirecionar a saida do rsync para o arquivo de log:

rsync -avz –delete $linha $DHUser@$DHhost:~/ >> $Log

Até resolvia, mas não era o ponto final. Ou seja, erros que ocorriam com o comando rsync, por exemplo, eram redirecionados para a stderr ( que como era o cron, ia para o meu email interno do sistema), e eu acabava não sabendo.
Assim, fui ao man do bash e achei uma coisa super interessante que eu nunca havia parado para analisar.
Vejamos dois exemplos:

(1) # ls > dirlist 2>&1
(2) # ls 2>&1 > dirlist


Qual a diferença entre o comando 1 e o comando 2  ?

A diferença é que o comando 1, redireciona tanto a saída de erro (stderr) quanto a saída padrão (stdout ) para o arquivo dirlist, enquanto o comando 2, somente direciona a saída padrão (stdout ) para o arquivo dirlist.

Ou seja, nunca havia me atentado que a ordem dos fatores, neste caso, alterava plenamente o produto :-)

Por estas e outras, que não adianta baterem o pé. Sim, informática é matemática … e nunca, outras áreas como muita gente teima de pé junto que informática é.