Uma das tarefas padrão mais comuns (especialmente ao exibir linguagens de programação esotéricas) é implementar um "programa de gato" : leia todo o STDIN e imprima-o no STDOUT. Embora esse nome tenha o nome do utilitário de shell Unix cat
, é claro que é muito menos poderoso que o real, que normalmente é usado para imprimir (e concatenar) vários arquivos lidos no disco.
Tarefa
Você deve escrever um programa completo que leia o conteúdo do fluxo de entrada padrão e os grave literalmente no fluxo de saída padrão. Se, e somente se, seu idioma não suportar fluxos de entrada e / ou saída padrão (como é entendido na maioria dos idiomas), você poderá considerar esses termos como o equivalente mais próximo em seu idioma (por exemplo, JavaScript prompt
e alert
). Essas são as únicas formas admissíveis de E / S, pois qualquer outra interface alteraria amplamente a natureza da tarefa e tornaria as respostas muito menos comparáveis.
A saída deve conter exatamente a entrada e nada mais . A única exceção a essa regra é a saída constante do intérprete do seu idioma que não pode ser suprimida, como uma saudação, códigos de cores ANSI ou recuo. Isso também se aplica ao rastreamento de novas linhas. Se a entrada não contiver uma nova linha à direita, a saída também não deverá incluir uma! (A única exceção é se o seu idioma sempre imprimir uma nova linha à direita após a execução.)
A saída para o fluxo de erros padrão é ignorada, desde que o fluxo de saída padrão contenha a saída esperada. Em particular, isso significa que seu programa pode terminar com um erro ao atingir o final do fluxo (EOF), desde que não polua o fluxo de saída padrão. Se você fizer isso, recomendamos que você adicione uma versão livre de erros à sua resposta (para referência).
Como isso é um desafio em cada idioma e não entre idiomas, existem algumas regras específicas para o idioma:
- Se for possível, no seu idioma, distinguir bytes nulos no fluxo de entrada padrão do EOF, seu programa deverá suportar bytes nulos como quaisquer outros bytes (ou seja, eles também deverão ser gravados no fluxo de saída padrão).
- Se for possível, no seu idioma, suportar um fluxo de entrada infinito arbitrário (ou seja, se você puder começar a imprimir bytes na saída antes de pressionar EOF na entrada), seu programa deverá funcionar corretamente nesse caso. Como exemplo,
yes | tr -d \\n | ./my_cat
deve imprimir um fluxo infinito dey
s. Depende de você com que frequência você imprime e libera o fluxo de saída padrão, mas deve garantir que isso ocorra após um período finito de tempo, independentemente do fluxo (isso significa, em particular, que você não pode esperar por um caractere específico como avanço de linha antes da impressão).
Adicione uma observação à sua resposta sobre o comportamento exato em relação a bytes nulos, fluxos infinitos e saída estranha.
Regras adicionais
Não se trata de encontrar o idioma com a solução mais curta para isso (existem algumas onde o programa vazio faz o truque) - trata-se de encontrar a solução mais curta em todos os idiomas. Portanto, nenhuma resposta será marcada como aceita.
Os envios na maioria dos idiomas serão pontuados em bytes em uma codificação preexistente apropriada, geralmente (mas não necessariamente) UTF-8.
Alguns idiomas, como pastas , são um pouco difíceis de pontuar. Em caso de dúvida, pergunte no Meta .
Sinta-se livre para usar um idioma (ou versão do idioma), mesmo que seja mais novo que esse desafio. Os idiomas escritos especificamente para enviar uma resposta de 0 byte a esse desafio são um jogo justo, mas não particularmente interessante.
Observe que deve haver um intérprete para que o envio possa ser testado. É permitido (e até encorajado) escrever esse intérprete para um idioma anteriormente não implementado.
Observe também que as línguas não têm de cumprir os nossos critérios usuais para linguagens de programação .
Se o seu idioma de escolha for uma variante trivial de outro idioma (potencialmente mais popular) que já tenha uma resposta (pense em dialetos BASIC ou SQL, shell do Unix ou derivados triviais do Brainfuck como Headsecks ou Unary), considere adicionar uma nota à resposta existente que a mesma solução ou uma solução muito semelhante também é a mais curta no outro idioma.
A menos que tenham sido anuladas anteriormente, todas as regras de código-golfe padrão se aplicam, incluindo o http://meta.codegolf.stackexchange.com/q/1061 .
Como uma observação lateral, por favor, não reduza as respostas chatas (mas válidas) em idiomas onde não há muito para jogar golfe; eles ainda são úteis para essa pergunta, pois ela tenta compilar um catálogo o mais completo possível. No entanto, faça respostas positivas acima em idiomas nos quais o autor realmente tenha se esforçado para jogar o código no golfe.
Catálogo
O snippet de pilha na parte inferior desta postagem gera o catálogo a partir das respostas a) como uma lista da solução mais curta por idioma eb) como uma tabela geral de líderes.
Para garantir que sua resposta seja exibida, inicie-a com um título, usando o seguinte modelo de remarcação:
## Language Name, N bytes
onde N
está o tamanho do seu envio. Se você melhorar sua pontuação, poderá manter as pontuações antigas no título, identificando-as. Por exemplo:
## Ruby, <s>104</s> <s>101</s> 96 bytes
Se você quiser incluir vários números no cabeçalho (por exemplo, porque sua pontuação é a soma de dois arquivos ou você deseja listar as penalidades do sinalizador de intérpretes separadamente), verifique se a pontuação real é o último número no cabeçalho:
## Perl, 43 + 2 (-p flag) = 45 bytes
Você também pode transformar o nome do idioma em um link que será exibido no snippet:
## [><>](http://esolangs.org/wiki/Fish), 121 bytes
cat
sh
resposta usandocat
que também contém uma solução mais curto usandodd
.)Respostas:
sed, 0
O
sed
programa vazio faz exatamente o que é necessário aqui:fonte
yes | tr -d \\n | sed ''
?yes
um buffer padrão até ficar sem memória. Uma advertência suponho ...Ziim ,
222201196185182 bytesProvavelmente, isso não será exibido corretamente no seu navegador, então aqui está um diagrama do código:
Não consigo pensar em uma estrutura mais simples para resolver o problema no Ziim, mas tenho certeza de que o código real ainda é bastante jogável.
O Ziim não pode lidar com fluxos infinitos, porque só é possível imprimir qualquer coisa no final do programa.
Explicação
Como o Ziim possui um modelo de fluxo de controle declarativo bastante exclusivo, um algoritmo imprescindível de pseudocódigo não o abordará aqui. Em vez disso, explicarei o básico do Ziim e, atualmente, a estrutura arrumada do código acima (de maneira gráfica semelhante) como a arte ASCII.
O fluxo de controle em Ziim acontece em todo o lugar: cada flecha que não é apontada por outra flecha inicializa um "encadeamento" que é processado independentemente das outras (não realmente em paralelo, mas não há garantias em que ordem elas são processadas) , a menos que você os sincronize por concatenação). Cada thread contém uma lista de dígitos binários, começando como
{0}
. Agora, cada seta no código é algum tipo de comando que possui uma ou duas entradas e uma ou duas saídas. O comando exato depende de quantas setas estão apontando para ele a partir de quais orientações.Aqui está a lista dos comandos, onde
m -> n
indica que o comando recebem
entradas e produzn
saídas.1 -> 1
, no-op : simplesmente redireciona o thread.1 -> 1
, invert : nega cada bit no segmento (e também o redireciona).1 -> 1
, leia : substitui o valor do encadeamento pelo próximo bit de STDIN ou pela lista vazia se clicarmos em EOF.2 -> 1
, concatenar : esta é a única maneira de sincronizar threads. Quando um fio atinge um lado da seta, ele fica suspenso até que outro fio atinja o outro lado. Nesse ponto, eles serão concatenados em um único encadeamento e continuarão a execução.2 -> 1
, label : esta é a única maneira de associar diferentes caminhos de execução. Este é simplesmente um no-op que possui duas entradas possíveis. Assim, os tópicos inseridos no "rótulo" por qualquer rota serão simplesmente redirecionados na mesma direção.1 -> 2
, dividir : pega um único encadeamento e envia duas cópias em direções diferentes.1 -> 1
, isZero? : consome o primeiro bit do encadeamento e envia o encadeamento em uma das duas direções, dependendo se o bit foi 0 ou 1.1 -> 1
, isEmpty? : consome a lista inteira (ou seja, substitui-a por uma lista vazia) e envia o encadeamento em uma das duas direções, dependendo de a lista já estar vazia ou não.Então, com isso em mente, podemos descobrir uma estratégia geral. Usando concatenar , queremos acrescentar repetidamente novos bits a uma string que representa toda a entrada. Podemos simplesmente fazer isso repetindo a saída da concatenação em uma de suas entradas (e inicializamos isso em uma lista vazia, limpando a
{0}
com isEmpty? ). A questão é como podemos encerrar esse processo.Além de adicionar o bit atual também irá preceder a 0 ou 1 indicando se chegamos a EOF. Se enviarmos nossa string através do isZero? , ele se livrará desse bit novamente, mas vamos distinguir o final do fluxo. Nesse caso, simplesmente deixamos o thread deixar a borda da grade (o que faz com que Ziim imprima o conteúdo do thread em STDOUT e encerre o programa) .
Se alcançamos o EOF ou não, pode ser determinado usando o isEmpty? em uma cópia da entrada.
Aqui está o diagrama que prometi:
Algumas notas sobre por onde começar a ler:
{0}
canto superior esquerdo é o gatilho inicial que inicia o loop de entrada.{0}
canto superior direito é imediatamente limpo para uma lista vazia e representa a sequência inicial que preencheremos gradualmente com a entrada.{0}
s são alimentados em um "produtor" loop (um invertido, não), para nos dar um suprimento ilimitado de0
s e1
s que precisa prefixar para a cadeia.fonte
Hexagonia , 6 bytes
Isso costumava ter 3 bytes (veja abaixo), mas essa versão não funciona mais desde a atualização mais recente do idioma. Como nunca intencionalmente introduzi o erro usado pela versão, decidi não contar.
Uma solução sem erros (ou seja, que funciona com o intérprete fixo) acaba sendo muito mais complicada. Eu tive alguns problemas para compactá-lo em uma grade 2x2, mas encontrei uma solução agora, embora precise dos 7 bytes completos :
Após o desenvolvimento, obtemos:
Como a borda da memória inicial é 0, o
<
incondicionalmente desvia o ponteiro da instrução para a diagonal nordeste, onde passa para o caminho cinza. O.
é um não-op. Agora,
lê um byte, o)
incrementa de forma que bytes válidos (incluindo bytes nulos) sejam positivos e EOF seja 0.Assim, no EOF, o IP passa para o caminho vermelho, onde
@
finaliza o programa. Porém, se ainda lermos um byte, o IP passará para o caminho verde e, em vez disso,(
diminuirá a borda para o valor original, antes;
de imprimi-lo em STDOUT. O IP agora volta incondicionalmente ao caminho cinza, repetindo o processo.Depois de escrever um script de força bruta para a minha resposta da Truth Machine, configurei-o para encontrar também uma solução de 6 bytes sem erros para o programa cat. Surpreendentemente, ele encontrou uma - sim, exatamente uma solução em todos os programas possíveis de hexagonia de 6 bytes. Depois das 50 soluções da máquina da verdade, isso foi bastante surpreendente. Aqui está o código:
Desdobramento:
O uso de
~
(negação unária) em vez de()
é interessante, porque a) é zero no zero, b) troca os lados do ramo, c) em alguns códigos, um único~
pode ser usado duas vezes para desfazer a operação consigo mesmo . Então, aqui está o que está acontecendo:A primeira vez (caminho roxo) que passamos
~
é um no-op. O/
reflete o IP na diagonal noroeste. O caminho cinza agora lê um caractere e multiplica seu código por-1
. Isso transforma o EOF (-1
) em um valor verdadeiro (positivo) e todos os caracteres válidos em valores falsos (não positivos). No caso de EOF, o IP pega o caminho vermelho e o código termina. No caso de um caractere válido, o IP segue o caminho verde, onde~
desfaz a negação e;
imprime o caractere. Repetir.Finalmente, aqui está a versão de 3 bytes que costumava funcionar no interpretador Hexagony da versão original.
Como a resposta do labirinto, isso termina com um erro se o fluxo de entrada for finito.
Depois de desdobrar o código, ele corresponde à seguinte grade hexadecimal:
O
.
são não-ops. A execução começa no caminho roxo.,
lê um byte,;
escreve um byte. Em seguida, a execução continua no caminho do salmão (ish?). Precisamos&
redefinir a borda da memória atual para zero, de modo que o IP volte para a linha roxa ao atingir o canto no final da segunda linha. Uma vez,
atingido o EOF, ele retornará-1
, o que causa um erro ao;
tentar imprimi-lo.Diagramas gerados com o incrível HexagonyColorer de Timwi .
fonte
TeaScript , 0 bytes
TeaScript é uma linguagem concisa de golfe compilada em JavaScript
Em uma atualização recente, a entrada é incluída implicitamente como a primeira propriedade.
Experimente online
Como alternativa, 1 byte
x
contém a entrada no TeaScript. Saída implícitafonte
Brian & Chuck , 44 bytes
Eu originalmente criei essa linguagem para Criar uma linguagem de programação que parece apenas inutilizável . No entanto, é um exercício muito bom para resolver problemas simples.
O básico: Cada uma das duas linhas define um programa semelhante ao Brainfuck que opera no código fonte do outro programa - o primeiro programa é chamado Brian e o segundo é chamado Chuck. Apenas Brian pode ler e apenas Chuck pode escrever. Em vez dos loops de Brainfuck, você tem o
?
que passa o controle para o outro programa (e os papéis do ponteiro de instruções e da cabeça da fita também mudam). Uma adição ao Brainfuck é{
e}
que digitaliza a fita para a primeira célula diferente de zero (ou a extremidade esquerda). Além disso,_
são substituídos por bytes nulos.Embora eu ainda não pense que isso seja ótimo, estou muito feliz com esta solução. Minha primeira tentativa foi de 84 bytes e, após várias sessões de golfe com o Sp3000 (e inspirando-me nas tentativas dele), consegui baixá-lo lentamente para 44, alguns bytes de cada vez. Especialmente o
+}+
truque brilhante foi idéia dele (veja abaixo).Explicação
A entrada é lida na primeira célula da fita de Chuck e depois copiada meticulosamente até o final da fita de Brian, onde é impressa. Ao copiá-lo até o final, podemos salvar bytes ao definir o caractere anterior como zero.
O
#
é apenas um espaço reservado, porque alternar o controle não executa a célula que ligamos.{<{
garante que a cabeça da fita esteja na primeira célula de Chuck.,
lê um byte de STDIN ou-1
se clicarmos em EOF. Então, incrementamos isso com+
para torná-lo zero para EOF e diferente de zero.Vamos supor que ainda não estamos na EOF. Então a célula é positiva e
?
trocará o controle para Chuck.}>
move a cabeça da fita (na Brian) ao+
do_
e?
passa o controle de volta para Brian.{-
agora diminui a primeira célula em Chuck. Se ainda não for zero, passamos o controle para Chuck novamente com?
. Desta vez,}>
move a cabeça da fita em Brian duas células à direita da última célula diferente de zero. Inicialmente está aqui:Mas mais tarde, já teremos alguns personagens lá. Por exemplo, se já lemos e imprimimos
abc
, ficaria assim:Onde os
1
s são na verdade 1 bytes (veremos mais adiante).Essa célula sempre será zero, portanto, desta vez
?
, o controle não será alterado.>
move ainda outra célula para a direita e+
incrementa essa célula. É por isso que o primeiro caractere na entrada termina três células à direita da?
(e cada uma subsequente três células à direita).<<<
volta ao último caractere da lista (ou?
se é o primeiro caractere) e{>
volta à+
fita de Brian para repetir o loop, que transfere lentamente a célula de entrada para o final da fita de Brian.Uma vez que a célula de entrada estiver vazia, o
?
after{-
não mudará mais o controle. Em seguida,>}<
move a cabeça da fita em Chuck para o_
controle e alterna para que a segunda metade de Chuck seja executada.}>>
move-se para a célula que escrevemos no final da fita de Brian, que é o byte que lemos de STDIN, para imprimi-lo novamente.
. Para}
executar esse novo caractere na fita, precisamos fechar o espaço de dois bytes nulos, para incrementá-los1
com<+<+
(é por isso que existem 1 bytes entre os caracteres reais na fita final). Finalmente,{<{
volta ao início da fita de Brian e?
começa tudo desde o início.Você pode se perguntar o que acontece se o caractere que lemos for um byte nulo. Nesse caso, a célula recém-escrito seria por si só zero, mas já que é no final da fita de Brian e nós não nos importamos onde esse fim é, podemos simplesmente ignorar isso. Isso significa que se a entrada fosse
ab\0de
, a fita de Brian acabaria parecendo:Finalmente, uma vez que atingimos o EOF, o primeiro
?
na fita de Brian será um no-op. Neste ponto, encerramos o programa. A solução ingênua seria para mover para o fim do controle de fita e chave de Chuck, de tal forma que os termiantes programa:>}>}<?
. É aqui que a idéia realmente inteligente do Sp3000 salva três bytes:+
transforma a primeira célula de Chuck1
. Isso significa que}
tem um ponto de partida e encontra_
o meio da fita de Chuck. Em vez de ignorá-lo, simplesmente fechamos a lacuna transformando-a em um1
com+
. Agora vamos ver o que o resto do código de Brian faz com este Chuck modificado ...{
volta à primeira célula de Chuck, como de costume, e a-
transforma em um byte nulo. Isso significa que?
é um não-op. Mas agora>}<
, que geralmente moveu a cabeça da fita para o meio da fita de Chuck, passa por ela até o final da fita de Chuck e?
passa o controle para Chuck, encerrando o código. É bom quando as coisas dão certo ... :)fonte
Haskell, 16 bytes
interact
lê a entrada, passa-a para a função fornecida como argumento e imprime o resultado que recebe.id
é a função de identidade, ou seja, retorna sua entrada inalterada. Graças à preguiça de Haskell,interact
podemos trabalhar com informações infinitas.fonte
sh + binutils,
32 bytesBem, não é tão óbvio. From @ Random832
Original:
O dolorosamente óbvio ...: D
fonte
dd
.cat
???Função , 16 bytes
(Codificado como UTF-16 com uma lista técnica)
Explicação
A caixa retorna o conteúdo de STDIN. A extremidade solta produz.
fonte
Motorola MC14500B Código da máquina , 1,5 bytes
Escrito em hexadecimal:
Escrito em binário:
Explicação
Os códigos de operação são de 4 bits cada.
fonte
Mornington Crescent , 41 bytes
Não tenho idéia se o Mornington Crescent pode manipular bytes nulos e todas as entradas são lidas antes do início do programa, pois essa é a natureza do idioma.
fonte
Brainfuck, 5 bytes
Equivalente ao pseudocódigo:
Isso lida com fluxos infinitos, mas trata bytes nulos como EOF. Se o BF pode ou não manipular bytes nulos corretamente varia de implementação para implementação, mas isso pressupõe a abordagem mais comum.
fonte
+[,.]
certo?Labirinto , 2 bytes
Se o fluxo for finito, isso terminará com um erro, mas toda a saída produzida pelo erro vai para STDERR, portanto, o fluxo de saída padrão está correto.
Como em Brainfuck,
,
lê um byte (empurrando-o para a pilha principal do Labyrinth) e.
escreve um byte (saltando-o da pilha principal do Labyrinth).A razão pela qual isso ocorre é que ambos
,
e.
são "becos sem saída" no labirinto (muito trivial) representado pelo código-fonte, de modo que o ponteiro da instrução simplesmente gire no local e volte ao outro comando.Quando pressionamos EOF,
,
empurra-1
e.
lança um erro porque-1
não é um código de caractere válido. Isso pode realmente mudar no futuro, mas ainda não decidi isso.Para referência, podemos resolver isso sem erros em 6 bytes, como segue
Aqui, os
)
incrementos do byte que lemos, o que dá0
no EOF e algo positivo de outra forma. Se o valor for0
, o IP seguirá em frente, atingindo o@
que encerra o programa. Se o valor for positivo, o IP fará uma curva à direita em direção à(
que diminui o topo da pilha de volta ao seu valor original. O IP está agora em um canto e simplesmente continuará fazendo as curvas certas, imprimindo.
e lendo um novo byte.
antes que ele atinja o garfo)
novamente.fonte
C, 40 bytes
fonte
getchar
retorna -1 , para que seu código imprima um fluxo infinito de bytes 0xFF após a entrada (finita).> <> , 7 bytes
Experimente aqui . Explicação:
Se você quiser continuar até dar mais informações, substitua
;
por!
.fonte
io
(2 bytes) faz o mesmo, mas trava e gravasomething smells fishy...
no STDERR no final da execução, o que é permitido.Montagem X86, 70 bytes
Desmontagem com
objdump
:A fonte:
fonte
objdump
desmontou-o como código de 32 bits, enquanto você parece ter compilado como 16 bits. Em que acreditar? Desde que você usaint 0x80
, acho que é para o Linux, mas por que compilar como 16 bits então?Lambda universal , 1 byte
Um programa Universal Lambda é uma codificação de um termo lambda em binário, dividido em pedaços de 8 bits, preenchendo pedaços incompletos com quaisquer bits, convertidos em um fluxo de bytes.
Os bits são traduzidos para um termo lambda da seguinte maneira:
00
apresenta uma abstração lambda.01
representa uma aplicação de dois termos subsequentes.111..10
, com n repetições do bit1
, refere-se à variável da n- ésima mãe lambda; ou seja, é um índice de De Bruijn em unário.Por essa conversão,
0010
é a função de identidadeλa.a
, o que significa que qualquer programa de byte único do formulário0010xxxx
é umcat
programa.fonte
!
é0x21
, não0x4_
?PowerShell,
884130 bytesEDIT - esqueci que posso usar a
$input
variável automática para entrada do pipeline ... EDIT2 - não precisa testar a existência de$input
Sim, então ... STDIN no PowerShell é ... estranho, digamos. Com a suposição de que precisamos aceitar informações de todos os tipos de STDIN, essa é uma resposta possível para este catálogo, e tenho certeza de que existem outras. 1
A entrada de pipeline no PowerShell não funciona como você pensaria. Como a canalização no PowerShell é uma função do idioma e não do ambiente / shell (e o PowerShell não é realmente apenas um idioma), existem algumas peculiaridades no comportamento.
Para iniciantes e mais relevante para essa entrada, o canal não é avaliado instantaneamente (na maioria das vezes). O significado, se tivermos
command1 | command2 | command3
em nosso shell,command2
não aceitará entrada ou iniciará o processamento até que sejacommand1
concluído ... a menos que você o encapsulecommand1
com umForEach-Object
... diferente deForEach
. (mesmo queForEach
seja um alias paraForEach-Object
, mas esse é um problema separado, pois estou falandoForEach
como a declaração, não como alias)Isso significaria que algo como
yes | .\simple-cat-program.ps1
(mesmo queyes
não exista realmente, mas seja o que for) não funcionaria porqueyes
nunca seria concluído. Se pudéssemos fazerForEach-Object -InputObject(yes) | .\simple-cat-program.ps1
isso, deveria (em teoria) funcionar.Conhecendo o ForEach e o ForEach-Object no Microsoft "Ei, pessoal de scripts!" blog.
Portanto, todos esses parágrafos estão explicando por que
if($input){$input}
existe. Nós pegamos um parâmetro de entrada criado especialmente automaticamente se a entrada do pipeline estiver presente, testamos se ela existe e, se houver, a produzimos.Em seguida, pegamos a entrada do usuário
(read-host)
através do que é essencialmente um fluxo STDIN separado ewrite-host
o fazemos novamente com a-n
bandeira (abreviação de-NoNewLine
). Observe que isso não suporta entrada arbitrária de comprimento, poisread-host
só será concluída quando um avanço de linha for inserido (tecnicamente quando o usuário pressionar "Enter", mas funcionalmente equivalente).Ufa.
1 Mas existem outras opções:
Por exemplo, se estivéssemos preocupados apenas com a entrada do pipeline e não precisássemos de um programa completo, você poderia fazer algo como o
| $_
que produziria apenas o que foi inserido. (Em geral, isso é um pouco redundante, pois o PowerShell tem uma saída implícita de coisas "deixadas para trás" após os cálculos, mas isso é um aparte.)Se estivermos preocupados apenas com a entrada interativa do usuário, poderíamos usar apenas
write-host(read-host)-n
.Além disso, essa função possui o recursopeculiarde aceitar a entrada da linha de comando, por exemplo.\simple-cat-program.ps1 "test"
, preencheria (e depois produziria) a$a
variável.fonte
Cubix ,
65 bytesAgora lida com bytes nulos!
Cubix é um esolang bidimensional baseado em pilha. O Cubix é diferente de outros idiomas 2D, pois o código-fonte está envolvido na parte externa de um cubo.
Teste online! Nota: há um atraso de 50 ms entre as iterações.
Explicação
A primeira coisa que o intérprete faz é descobrir o menor cubo no qual o código se ajustará. Nesse caso, o comprimento da borda é 1. Em seguida, o código é preenchido com no-ops
.
até que todos os seis lados sejam preenchidos. O espaço em branco é removido antes do processamento, portanto, esse código é idêntico ao acima:Agora o código está sendo executado. O IP (ponteiro de instrução) inicia na face esquerda extrema, apontando para leste.
O primeiro caractere que o IP encontra é
_
, que é um espelho que gira o IP se estiver voltado para o norte ou sul; atualmente está voltado para o leste, então isso não faz nada. A seguiri
, insira um byte de STDIN.?
vira o IP para a esquerda se o item principal for negativo ou para a direita se for positivo. Existem três caminhos possíveis aqui:@
, o que encerra o programa.o
._
. Isso inverte, enviando-o de volta para o?
, que vira a direita novamente e gera o byte.Eu acho que este programa é ideal. Antes que o Cubix pudesse manipular bytes nulos (o EOF era 0, não -1), este programa funcionava para tudo, exceto bytes nulos:
Eu escrevi um forçador bruto para encontrar todos os programas de gato de 5 bytes. Embora demore cerca de 5 minutos para concluir, a versão mais recente encontrou 5 programas:
fonte
Vitsy, 2 bytes
z
obtém toda a pilha de entrada e a envia para a pilha de programa ativa.Z
imprime toda a pilha ativa em STDOUT.Método alternativo:
fonte
MarioLANG , 11 bytes
Não tenho certeza se isso é ótimo, mas é o mais curto que encontrei.
Isso suporta fluxos infinitos e terminará com um erro ao atingir o EOF (pelo menos a implementação de referência Ruby).
Há outra versão disso que transforma Mario em um ninja que pode pular duas vezes:
Nos dois casos, Mario começa a cair na coluna da esquerda, onde
,
lê um byte e.
grava um byte (que gera um erro no EOF porque,
não retorna um caractere válido).>
garante que Mario caminha para a direita (=
é apenas um terreno para ele caminhar). Então, ele se move para cima, quer através de um salto duplo com^
ou através de um elevador (o"
e#
par) antes da<
lhe diz para voltar para a coluna da esquerda.fonte
rs , 0 bytes
A sério. O rs apenas imprime o que obtém se o script fornecido estiver completamente vazio.
fonte
GolfScript, 3 bytes
O programa vazio ecoa a entrada padrão. O idioma não pode lidar com fluxos infinitos. No entanto, ele acrescenta uma nova linha, como o @Dennis mencionou. Isso é feito envolvendo a pilha inteira em uma matriz e chamando
puts
, que é definido comoprint n print
onden
é uma nova linha. No entanto, podemos redefinirn
para ser STDIN e depois esvaziar a pilha, que é exatamente o que:n;
faz.fonte
Carro meio quebrado no tráfego pesado , 9 + 3 = 12 bytes
Carro meio quebrado no trânsito pesado (HBCHT) recebe a entrada como argumentos da linha de comando, portanto, execute como
Observe que o +3 é para o
-s
sinalizador, que sai como caracteres. Além disso, o HBCHT não parece lidar com NULs, pois todos os zeros são eliminados da saída (por exemplo, a97 0 98
saída é como dois caracteresab
).Explicação
No HBCHT, seu carro começa na
o
e seu objetivo é a saída#
.^>v<
direcione o movimento do carro, enquanto modifica simultaneamente uma fita tipo BF (^>v<
traduza para+>-<
). No entanto, como o nome do idioma sugere, seu carro só pode virar à direita - qualquer tentativa de virar à esquerda é completamente ignorada (incluindo seus efeitos de memória). Note que isto é apenas para rodar - o seu carro é perfeitamente capaz de dirigir para frente / para trás.Outras partes interessantes sobre o HBCHT são que a direção inicial do seu carro é aleatória e a grade é toroidal. Assim, precisamos apenas do carro para chegar à saída sem modificar a fita nas quatro direções iniciais:
Para cima e para baixo são simples, indo diretamente para a saída.
Para a esquerda, envolvemos, executamos
<
e incrementamos com^
. Não podemos virar à esquerda no próximo,<
então encerramos e diminuímosv
, negando o incremento anterior. Como estamos descendo agora, podemos virar à direita na<
saída e sair, movendo o ponteiro duas vezes e modificando os valores das células.Para a direita, fazemos o mesmo que para a esquerda, mas pulamos a primeira,
^
pois não podemos virar à esquerda.Edit : Acontece que o intérprete HBCHT permite executar apenas um único caminho através de um sinalizador de linha de comando, por exemplo
No entanto, o sinalizador não é apenas muito caro para essa questão em particular (pelo menos 5 bytes para
" -d u"
), parece que todos os caminhos ainda precisam ser capazes de chegar à saída para a execução do código.fonte
Minkolang , 5 bytes
Experimente aqui.
Explicação
o
lê um caractere da entrada e envia seu código ASCII para a pilha (0
se a entrada estiver vazia).d
depois duplica o topo da pilha (o caractere que acabou de ser lido).?
é um trampolim condicional, que salta a próxima instrução do topo da pilha não0
. Se a entrada estiver vazia, a.
mensagem não será saltada e o programa será interrompido. Caso contrário,O
gera o topo da pilha como um caractere. A natureza toroidal de Minkolang significa que isso faz um loop até o começo.fonte
INTERCALL , 133 bytes
wat
fonte
500
(não tenho certeza), seriaPRINT D
, certo? (excluindo o cabeçalho)PUSH XX<newline>PRINT
ouPUSH XX AND PRINT
. Ah, e eu sou o criador do INTERCALLV , 0 bytes
Experimente online!
A idéia de "memória" de V é apenas um gigantesco conjunto de caracteres 2D. Antes de qualquer programa ser executado, todas as entradas são carregadas nessa matriz (conhecida como "O Buffer"). Em seguida, no final de qualquer programa, todo o texto no buffer é impresso.
Em outras palavras, o programa vazio é um programa para gatos.
fonte
Boneco de neve 1.0.2 , 15 caracteres
Tomado diretamente do
examples
diretório do Snowman . Lê uma linha, imprime uma linha, lê uma linha, imprime uma linha ...Observe que, devido a um detalhe de implementação, quando STDIN está vazio,
vg
retornará a mesma coisa que faria para uma linha vazia. Portanto, isso imprimirá novas linhas repetidamente em um loop infinito quando o STDIN for fechado. Isso pode ser corrigido em uma versão futura.Explicação do código:
fonte
FireType , 7 bytes
Requer algumas mudanças que acabei de pressionar . As regras dizem:
então eu estou livre!
fonte
Fissão , 4 bytes
Não é legal quando você vence os programas de amostra no próprio repositório da linguagem? :) Para referência, possui a solução de 7 bytes
Explicação
Então,
R
inicia o fluxo de controle com um átomo à direita.?
lê um caractere de STDIN na massa do átomo. Enquanto estamos lendo caracteres, a energia permanece zero, então oJ
árbitro é um não-op e!
imprime o personagem. O átomo volta ao início (R
agora não funciona) e repete todo o processo.Quando atingimos o EOF,
?
configuramos a energia do átomo para1
, então oJ
ump agora ignorará o comando de impressão. Mas quando um átomo atinge?
depois que o EOF já foi retornado, ele destrói o átomo, o que encerra o programa.(A solução do autor do idioma usa um explícito
;
para encerrar o programa, que é pulado com dois0
portais caso contrário.)fonte
Shtriped , 20 bytes
Isso demonstra descaradamente que quase qualquer string ASCII imprimível é um identificador válido no Shtriped.
Como funciona:
Não há uma maneira real de detectar o EOF, portanto, isso ocorre para sempre, como a resposta do Python .
Você pode fazê-lo facilmente quando uma linha vazia é fornecida (30 bytes):
Observe que o Shtriped I / O suporta apenas ASCII imprimível , guias, alimentações de linha, retornos de carro, guias verticais e alimentações de formulário (100 caracteres no total). Isso ocorre porque internamente, as strings são representadas como números inteiros de precisão arbitrários não negativos, e deve haver um alfabeto finito de caracteres para poder codificar todas as strings.
fonte