O que é um "cano" e como pode ser "quebrado"?

Eu recebi o erro "tubo quebrado" do Xcode uma vez demais. Agora estou curioso para saber exatamente o que é um cano.

Qual é o conceito de "tubo" e como ele pode ser "quebrado"?

Um canal é simplesmente um mecanismo de comunicação entre processos (IPC) usado para conectar a saída padrão de um processo à entrada padrão de outro.

Um exemplo é quando você deseja procurar um arquivo pela palavra "pax":

cat filename | grep pax

e sim, eu sei que você pode grepo arquivo diretamente, mas isso não explica como funciona, não é?

Isso conecta a saída padrão do catcomando à entrada padrão do grepcomando. catenvia o conteúdo do arquivo para sua saída padrão e greplê seu arquivo (neste caso) a partir de sua entrada padrão. Ao conectar processos como esse, você pode criar suas próprias ferramentas, consistindo em qualquer número de segmentos de tubos. Coisas como:

show_users | grep pax | awk -F: '{print $4}' | tr '[a-z]' '[A-Z]' | cut -c1-20

Um tubo quebrado é aquele em que (geralmente) o receptor dos dados fechou a conexão enquanto o remetente ainda está tentando enviar coisas.

Por exemplo, se você enviar um arquivo grande por meio de um programa de pager (para visualizá-lo uma página por vez):

cat myfile | pager

e faça a CTRL-BREAK, isso pode fazer com que o pagerprocesso desligue seu tubo de entrada antes de catterminar de usá-lo. Essa é uma possibilidade para obter este tubo quebrado.

Em uma pesquisa superficial do Google , esse problema específico parece estar relacionado a implantações ad hoc e as soluções fornecidas geralmente incluem sair da maior parte do seu software e reiniciar a maioria dos seus dispositivos.

Provavelmente, isso é sério o suficiente para relatar o problema à Apple. Quanto mais desenvolvedores reclamarem disso, maior será a probabilidade de algo ser feito para corrigi-lo.

O |personagem costuma ser chamado de pipe. Nos vários shells do UNIX (que eu conheço), ele pode ser usado para canalizar a saída de um comando para a entrada de outro.

cat myfile.txt | head

O headcomando mostra apenas as primeiras linhas de sua entrada. Nesse ponto, ele fecha sua entrada. Isso representa um problema para o comando que estava gerando a entrada. Para onde ele escreve? Sempre que temos essa situação ou quando o processo de escrita termina antes que o leitor termine, isso é chamado de "cano quebrado".

Para impedir que o catcomando permaneça para sempre, o padrão UNIX define um sinal especial ( SIGPIPE , sinal 13 ) ao qual ele é enviado cat. A ação padrão para esse sinal é interromper o processo, o que faz com que o catfinal seja agradável.

Parece que o aplicativo que você está usando instalou um manipulador de sinal para todos os sinais, incluindo o SIGPIPE, que cria a pequena mensagem pop-up que você vê.

Este erro parece surgir com bastante frequência. /programming/490366/ad-hoc-deployment-issue-putpkt-write-failed-broken-pipe é "... um erro interno na capacidade do Xcode de falar com seu telefone. Isso não acontece significa que você fez algo errado, é um bug no sistema de desenvolvimento "

Um canal é um mecanismo IPC em sistemas Unix. Um tubo possui duas extremidades, uma extremidade de leitura e uma extremidade de gravação. Os dados gravados no final da gravação podem ser lidos a partir do final da leitura e saem na ordem em que foram gravados.

No mundo da linha de comando do Unix, os pipes são uma maneira muito comum de conectar programas para realizar um trabalho. Por exemplo sed 's/foo/bar/g' fred.txt | grep -e 'bar.*baz', o arquivo será lido, fred.txtsubstituindo todas as instâncias da sequência foopela sequência e, em barseguida, procure o resultado por linhas que contenham barseguidas por algum número de caracteres baz.

Isso, é claro, não parece muito útil. Mas tenho certeza de que, se você pensar sobre isso, poderá ver como pode colocar isso em todos os tipos de usos interessantes, especialmente depois de ter programas como awkou perlà sua disposição.

O sistema de tubulação faz parte do Unix desde muito cedo. E se um processo no seu pipeline terminar, você normalmente deseja que todos os programas no pipeline sejam encerrados. Isso significa que, por padrão, um processo que grava em um canal no qual o processo na extremidade de leitura se foi receberá um SIGPIPEsinal. E se o sinal estiver bloqueado, o writeerro ainda ocorrerá com um tipo especial de erro, indicando que o tubo 'quebrou'.

A manipulação padrão de SIGPIPEmata o processo que o recebe. E se não é a "cabeça" do oleoduto, a SIGPIPEcoisa toda se propaga de volta à cadeia.

O que o Xcode está reclamando é que ele iniciou algum subprograma para fazer algo com um cano que o levava, e esse subprograma morreu inesperadamente deixando o cano quebrado.

Um tubo "quebrado" é aquele em que uma extremidade foi close()atingida e a outra está sendo lida ou gravada. Por exemplo, no seguinte comando shell:

cat foo | less

O catprocesso mantém a extremidade de escrita do tubo e o lessprocesso a leitura. Se o processo do leitor fechar o tubo, ele será quebrado (e, portanto, inútil); o processo do gravador receberá o erro de "tubo quebrado" do sistema operacional.