Peculiar comportamento pip / comportamento da cabeça

6

Estou ajudando o netadmin aqui com um regex perl para automatizar a operação em alguns snapshots de nossa SAN e nossos scripts fazem coisas assim:

varinit1=$(iscsiadm -m session | grep rbmsdata1 | head -n1 | perl -pe 's/^tcp: \[\d*\] \d*\.\d*\.\d*\.\d*:\d*,\d* (iqn\..*\..*\..*:.*-.*-.*-.*-(.*-.*-\d{4}-\d{2}-\d{2}-\d{2}:\d{2}:\d{2}\.\d*\.\d*))$/$1/')

varsnap1=$(iscsiadm -m session | grep rbmsdata1 | head -n1 | perl -pe 's/^tcp: \[\d*\] \d*\.\d*\.\d*\.\d*:\d*,\d* (iqn\..*\..*\..*:.*-.*-.*-.*-(.*-.*-\d{4}-\d{2}-\d{2}-\d{2}:\d{2}:\d{2}\.\d*\.\d*))$/$2/')

Existem duas partes na assinatura da captura instantânea, uma aninhada na outra e estamos usando os grupos de captura para capturar o nome e uma parte do nome para diferentes comandos subseqüentes que precisam ser executados. Eu sei que ele está executando o mesmo comando várias vezes, e o regex pode ser limpo mais tarde, mas basicamente eles estão usando perl para produzir um parens e o outro.

tcp: [32] 40.40.40.101:3260,1 iqn.2001-05.com.equallogic:4-52aed6-91c5ffa78-2f0d8ae18504fee1-r12prd-rbmsdata1-2012-06-29-16:07:40.108.1
tcp: [33] 40.40.40.101:3260,1 iqn.2001-05.com.equallogic:4-52aed6-91c5ffa78-2f0d8ae18504fee1-r12prd-rbmsdata1-2012-06-29-16:07:40.108.1

Querendo capturar o que foi o resultado do icsiadm e do grep para obter isso:

iqn.2001-05.com.equallogic:4-52aed6-91c5ffa78-2f0d8ae18504fee1-r12prd-rbmsdata1-2012-06-29-16:07:40.108.1

e

r12prd-rbmsdata1-2012-06-29-16:07:40.108.1

O problema que estamos tendo é que às vezes o encanamento a encabeçar para obter a primeira linha está falhando com:

head: cannot open '–n1' for reading: No such file or directory

Claro, isso parece indicar que o stdin to head está vazio, então ele está procurando por um nome de arquivo.

Mas não há motivo para estar vazio.

Se fizermos coisas assim:

varinit1=$(iscsiadm -m session | grep rbmsdata1 | head -n1)
varsnap1=$(iscsiadm -m session | grep rbmsdata1 | head -n1)

o segundo falhará e a segunda variável estará vazia.

No entanto, se os invertermos, o varsnap1 falhará:

varsnap1=$(iscsiadm -m session | grep rbmsdata1 | head -n1)
varinit1=$(iscsiadm -m session | grep rbmsdata1 | head -n1)

É muito peculiar e não conseguimos descobrir o que está acontecendo. O comando iscsiadm está retornando a mesma coisa que cada um executa quando o executamos a partir da linha de comando e depois do grepping.

Existe algo bagunçando a tubulação?

versão principal 5.97 no RedHat Enterprise Linux

    
por Cade Roux 05.07.2012 / 22:29

1 resposta

4

Enquanto a sua pergunta talvez contenha um erro (longo utf8 dash em vez do normal):

$ head –n1
head: cannot open ‘–n1’ for reading: No such file or directory
$ head -n1 # ctrl-d
$ 

Suponho que era apenas uma coisa do navegador, já que apenas uma ocorrência era assim. head aguarda a entrada quando precisar dela de qualquer maneira. Tente substituir head -n1 por um desses:

sed -n 1p
awk 'NR==1 {print}' # yay, no potential dash problems

Ok, há muitas outras maneiras de fazer isso, mas você também pode ignorar esse elemento de canal e apenas informar grep para retornar apenas a primeira correspondência adicionando o parâmetro -m 1 . Ou eliminar dois elementos e dizer a perl para operar apenas na primeira linha correspondente.

    
por 05.07.2012 / 22:57