Một trong những nhiệm vụ tiêu chuẩn phổ biến nhất (đặc biệt là khi hiển thị các ngôn ngữ lập trình bí truyền) là thực hiện một "chương trình mèo" : đọc tất cả STDIN và in nó sang STDOUT. Mặc dù cái này được đặt theo tên của tiện ích shell Unix, catnhưng dĩ nhiên nó không mạnh hơn nhiều so với thực tế, thường được sử dụng để in (và ghép) một số tệp được đọc từ đĩa.

Bài tập, nhiệm vụ

Bạn nên viết một chương trình đầy đủ để đọc nội dung của luồng đầu vào tiêu chuẩn và ghi nguyên văn chúng vào luồng đầu ra tiêu chuẩn. Nếu và chỉ khi ngôn ngữ của bạn không hỗ trợ các luồng đầu vào và / hoặc đầu ra tiêu chuẩn (như được hiểu trong hầu hết các ngôn ngữ), thay vào đó, bạn có thể sử dụng các thuật ngữ này để có nghĩa tương đương gần nhất với ngôn ngữ của bạn (ví dụ: JavaScript promptvà alert). Đây là các hình thức I / O được chấp nhận duy nhất , vì bất kỳ giao diện nào khác sẽ thay đổi phần lớn bản chất của nhiệm vụ và làm cho câu trả lời ít so sánh hơn.

Đầu ra phải chứa chính xác đầu vào và không có gì khác . Ngoại lệ duy nhất cho quy tắc này là đầu ra liên tục của trình thông dịch ngôn ngữ của bạn không thể bị loại bỏ, chẳng hạn như lời chào, mã màu ANSI hoặc thụt lề. Điều này cũng áp dụng cho dòng mới. Nếu đầu vào không chứa một dòng mới, đầu ra không nên bao gồm một đầu vào! (Ngoại lệ duy nhất là nếu ngôn ngữ của bạn hoàn toàn luôn in một dòng mới sau khi thực hiện.)

Đầu ra cho luồng lỗi tiêu chuẩn bị bỏ qua, miễn là luồng đầu ra tiêu chuẩn chứa đầu ra dự kiến. Cụ thể, điều này có nghĩa là chương trình của bạn có thể chấm dứt với một lỗi khi nhấn vào cuối luồng (EOF), với điều kiện là không gây ô nhiễm luồng đầu ra tiêu chuẩn. Nếu bạn làm điều này, tôi khuyến khích bạn thêm một phiên bản không có lỗi vào câu trả lời của bạn (để tham khảo).

Vì đây là một thách thức trong mỗi ngôn ngữ chứ không phải giữa các ngôn ngữ, nên có một vài quy tắc cụ thể về ngôn ngữ:

• Nếu ngôn ngữ của bạn hoàn toàn có thể phân biệt byte rỗng trong luồng đầu vào tiêu chuẩn với EOF, thì chương trình của bạn phải hỗ trợ byte rỗng giống như bất kỳ byte nào khác (nghĩa là chúng cũng phải được ghi vào luồng đầu ra tiêu chuẩn).
• Nếu ngôn ngữ của bạn hoàn toàn có thể hỗ trợ luồng đầu vào vô hạn tùy ý (nghĩa là nếu bạn có thể bắt đầu in byte cho đầu ra trước khi bạn nhấn EOF trong đầu vào), chương trình của bạn phải hoạt động chính xác trong trường hợp này. Như một ví dụ yes | tr -d \\n | ./my_catnên in một dòng vô hạn của ys. Tùy thuộc vào tần suất bạn in và tuôn ra luồng đầu ra tiêu chuẩn, nhưng nó phải được đảm bảo xảy ra sau một khoảng thời gian hữu hạn, bất kể luồng đó là gì, đặc biệt là, bạn không thể đợi một ký tự cụ thể như một linefeed trước khi in).

Vui lòng thêm một ghi chú vào câu trả lời của bạn về hành vi chính xác liên quan đến null-byte, luồng vô hạn và đầu ra không liên quan.

Quy tắc bổ sung

• Đây không phải là tìm ngôn ngữ với giải pháp ngắn nhất cho việc này (có một số nơi mà chương trình trống thực hiện thủ thuật) - đây là về việc tìm giải pháp ngắn nhất trong mọi ngôn ngữ. Do đó, không có câu trả lời sẽ được đánh dấu là chấp nhận.

• Đệ trình trong hầu hết các ngôn ngữ sẽ được ghi bằng byte theo mã hóa có sẵn từ trước, thường (nhưng không nhất thiết) UTF-8.

  Một số ngôn ngữ, như Thư mục , có một chút khó khăn để ghi điểm. Nếu nghi ngờ, xin vui lòng hỏi về Meta .

• Hãy sử dụng một ngôn ngữ (hoặc phiên bản ngôn ngữ) ngay cả khi nó mới hơn thử thách này. Các ngôn ngữ được viết cụ thể để gửi câu trả lời 0 byte cho thử thách này là trò chơi công bằng nhưng không đặc biệt thú vị.

  Lưu ý rằng phải có một thông dịch viên để trình có thể được kiểm tra. Được phép (và thậm chí được khuyến khích) tự viết trình thông dịch này cho một ngôn ngữ chưa được thực hiện trước đó.

  Cũng lưu ý rằng ngôn ngữ làm phải thực hiện đầy đủ các tiêu chí thông thường của chúng tôi cho các ngôn ngữ lập trình .

• Nếu ngôn ngữ bạn chọn là một biến thể tầm thường của ngôn ngữ khác (có khả năng phổ biến hơn) đã có câu trả lời (nghĩ phương ngữ BASIC hoặc SQL, shell Unix hoặc dẫn xuất Brainfuck tầm thường như Headsecks hoặc Unary), hãy xem xét thêm ghi chú vào câu trả lời hiện có cùng một hoặc một giải pháp rất giống nhau cũng là ngắn nhất trong ngôn ngữ khác.

• Trừ khi chúng được ghi đè trước đó, tất cả các quy tắc golf-mã tiêu chuẩn sẽ được áp dụng, bao gồm http://meta.codegolf.stackexchange.com/q/1061 .

Là một lưu ý phụ, xin vui lòng không downvote câu trả lời nhàm chán (nhưng hợp lệ) trong các ngôn ngữ không có nhiều để chơi golf; những câu hỏi này vẫn hữu ích cho câu hỏi này vì nó cố gắng biên dịch một danh mục đầy đủ nhất có thể. Tuy nhiên, chủ yếu thực hiện các câu trả lời trong các ngôn ngữ mà tác giả thực sự phải nỗ lực để đánh gôn.

Mục lục

Đoạn trích Stack ở cuối bài đăng này tạo ra danh mục từ các câu trả lời a) dưới dạng danh sách các giải pháp ngắn nhất cho mỗi ngôn ngữ và b) dưới dạng bảng xếp hạng tổng thể.

Để đảm bảo rằng câu trả lời của bạn hiển thị, vui lòng bắt đầu câu trả lời của bạn bằng một tiêu đề, sử dụng mẫu Markdown sau:

## Language Name, N bytes

nơi Nlà kích thước của trình của bạn. Nếu bạn cải thiện điểm số của mình, bạn có thể giữ điểm số cũ trong tiêu đề, bằng cách đánh bại chúng thông qua. Ví dụ:

## Ruby, <s>104</s> <s>101</s> 96 bytes

Nếu bạn muốn bao gồm nhiều số trong tiêu đề của mình (ví dụ: vì điểm của bạn là tổng của hai tệp hoặc bạn muốn liệt kê riêng các hình phạt cờ của thông dịch viên), hãy đảm bảo rằng điểm thực tế là số cuối cùng trong tiêu đề:

## Perl, 43 + 2 (-p flag) = 45 bytes

Bạn cũng có thể đặt tên ngôn ngữ thành liên kết sau đó sẽ hiển thị trong đoạn trích:

## [><>](http://esolangs.org/wiki/Fish), 121 bytes

<style>body { text-align: left !important} #answer-list { padding: 10px; width: 290px; float: left; } #language-list { padding: 10px; width: 290px; float: left; } table thead { font-weight: bold; } table td { padding: 5px; }</style><script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script> <link rel="stylesheet" type="text/css" href="//cdn.sstatic.net/codegolf/all.css?v=83c949450c8b"> <div id="language-list"> <h2>Shortest Solution by Language</h2> <table class="language-list"> <thead> <tr><td>Language</td><td>User</td><td>Score</td></tr> </thead> <tbody id="languages"> </tbody> </table> </div> <div id="answer-list"> <h2>Leaderboard</h2> <table class="answer-list"> <thead> <tr><td></td><td>Author</td><td>Language</td><td>Size</td></tr> </thead> <tbody id="answers"> </tbody> </table> </div> <table style="display: none"> <tbody id="answer-template"> <tr><td>{{PLACE}}</td><td>{{NAME}}</td><td>{{LANGUAGE}}</td><td>{{SIZE}}</td><td><a href="{{LINK}}">Link</a></td></tr> </tbody> </table> <table style="display: none"> <tbody id="language-template"> <tr><td>{{LANGUAGE}}</td><td>{{NAME}}</td><td>{{SIZE}}</td><td><a href="{{LINK}}">Link</a></td></tr> </tbody> </table><script>var QUESTION_ID = 62230; var ANSWER_FILTER = "!t)IWYnsLAZle2tQ3KqrVveCRJfxcRLe"; var COMMENT_FILTER = "!)Q2B_A2kjfAiU78X(md6BoYk"; var OVERRIDE_USER = 8478; var answers = [], answers_hash, answer_ids, answer_page = 1, more_answers = true, comment_page; function answersUrl(index) { return "//api.stackexchange.com/2.2/questions/" + QUESTION_ID + "/answers?page=" + index + "&pagesize=100&order=desc&sort=creation&site=codegolf&filter=" + ANSWER_FILTER; } function commentUrl(index, answers) { return "//api.stackexchange.com/2.2/answers/" + answers.join(';') + "/comments?page=" + index + "&pagesize=100&order=desc&sort=creation&site=codegolf&filter=" + COMMENT_FILTER; } function getAnswers() { jQuery.ajax({ url: answersUrl(answer_page++), method: "get", dataType: "jsonp", crossDomain: true, success: function (data) { answers.push.apply(answers, data.items); answers_hash = []; answer_ids = []; data.items.forEach(function(a) { a.comments = []; var id = +a.share_link.match(/\d+/); answer_ids.push(id); answers_hash[id] = a; }); if (!data.has_more) more_answers = false; comment_page = 1; getComments(); } }); } function getComments() { jQuery.ajax({ url: commentUrl(comment_page++, answer_ids), method: "get", dataType: "jsonp", crossDomain: true, success: function (data) { data.items.forEach(function(c) { if (c.owner.user_id === OVERRIDE_USER) answers_hash[c.post_id].comments.push(c); }); if (data.has_more) getComments(); else if (more_answers) getAnswers(); else process(); } }); } getAnswers(); var SCORE_REG = /<h\d>\s*([^\n,<]*(?:<(?:[^\n>]*>[^\n<]*<\/[^\n>]*>)[^\n,<]*)*),.*?(\d+)(?=[^\n\d<>]*(?:<(?:s>[^\n<>]*<\/s>|[^\n<>]+>)[^\n\d<>]*)*<\/h\d>)/; var OVERRIDE_REG = /^Override\s*header:\s*/i; function getAuthorName(a) { return a.owner.display_name; } function process() { var valid = []; answers.forEach(function(a) { var body = a.body; a.comments.forEach(function(c) { if(OVERRIDE_REG.test(c.body)) body = '<h1>' + c.body.replace(OVERRIDE_REG, '') + '</h1>'; }); var match = body.match(SCORE_REG); if (match) valid.push({ user: getAuthorName(a), size: +match[2], language: match[1], link: a.share_link, }); else console.log(body); }); valid.sort(function (a, b) { var aB = a.size, bB = b.size; return aB - bB }); var languages = {}; var place = 1; var lastSize = null; var lastPlace = 1; valid.forEach(function (a) { if (a.size != lastSize) lastPlace = place; lastSize = a.size; ++place; var answer = jQuery("#answer-template").html(); answer = answer.replace("{{PLACE}}", lastPlace + ".") .replace("{{NAME}}", a.user) .replace("{{LANGUAGE}}", a.language) .replace("{{SIZE}}", a.size) .replace("{{LINK}}", a.link); answer = jQuery(answer); jQuery("#answers").append(answer); var lang = a.language; lang = jQuery('<a>'+lang+'</a>').text(); languages[lang] = languages[lang] || {lang: a.language, lang_raw: lang.toLowerCase(42), user: a.user, size: a.size, link: a.link}; }); var langs = []; for (var lang in languages) if (languages.hasOwnProperty(lang)) langs.push(languages[lang]); langs.sort(function (a, b) { if (a.lang_raw > b.lang_raw) return 1; if (a.lang_raw < b.lang_raw) return -1; return 0; }); for (var i = 0; i < langs.length; ++i) { var language = jQuery("#language-template").html(); var lang = langs[i]; language = language.replace("{{LANGUAGE}}", lang.lang) .replace("{{NAME}}", lang.user) .replace("{{SIZE}}", lang.size) .replace("{{LINK}}", lang.link); language = jQuery(language); jQuery("#languages").append(language); } }</script>

quyến rũ, 0

sedChương trình trống thực hiện chính xác những gì được yêu cầu ở đây:

$ printf "abc\ndef" | sed ''
abc
def$ 

Ziim , 222 201 196 185 182 byte

    ↓ ↓

 ↓ ↓     ↓
 ↗ ↗↙↔↘↖ ↖
 ↓↓⤡⤢  ⤢↙
↘ ↖⤡ ↖
  ↙
  ↕↘ ↑ ↙
→↘↖↑ ↙ ↑
→↖   ↑
→↖↘ ↙
  ↑↓↑

   ⤡

Điều này có thể sẽ không hiển thị chính xác trong trình duyệt của bạn, vì vậy đây là sơ đồ mã:

Tôi không thể nghĩ ra một cấu trúc đơn giản hơn để giải quyết vấn đề trong Ziim, nhưng tôi chắc chắn rằng mã thực tế vẫn khá dễ chơi.

Ziim không thể xử lý các luồng vô hạn vì chỉ có thể in bất cứ thứ gì vào cuối chương trình.

Giải trình

Vì Ziim có một mô hình dòng điều khiển khai báo khá độc đáo, một thuật toán mã giả bắt buộc sẽ không cắt nó ở đây. Thay vào đó, tôi sẽ giải thích những điều cơ bản của Ziim và hiện tại cấu trúc được dọn dẹp của đoạn mã trên (theo cách thức đồ họa tương tự) như nghệ thuật ASCII.

Luồng điều khiển trong Ziim xảy ra ở mọi nơi: mỗi mũi tên không được chỉ bởi một mũi tên khác khởi tạo một "luồng" được xử lý độc lập với các luồng khác (không thực sự song song, nhưng không có gì đảm bảo chúng được xử lý theo thứ tự nào , trừ khi bạn đồng bộ hóa chúng thông qua ghép nối). Mỗi luồng như vậy chứa một danh sách các chữ số nhị phân, bắt đầu như {0}. Bây giờ mỗi mũi tên trong mã là một loại lệnh có một hoặc hai đầu vào và một hoặc hai đầu ra. Lệnh chính xác phụ thuộc vào số lượng mũi tên đang chỉ vào nó từ đó định hướng.

Dưới đây là danh sách các lệnh, trong đó m -> nchỉ ra rằng lệnh lấy mđầu vào và tạo nđầu ra.

• 1 -> 1, no-op : chỉ đơn giản là chuyển hướng chuỗi.
• 1 -> 1, invert : phủ định từng bit trong luồng (và cũng chuyển hướng nó).
• 1 -> 1, đọc : thay thế giá trị của luồng bằng bit tiếp theo từ STDIN hoặc bằng danh sách trống nếu chúng ta đã nhấn EOF.
• 2 -> 1, concatenate : đây là cách duy nhất để đồng bộ các chủ đề. Khi một luồng chạm vào một bên của mũi tên, nó sẽ bị treo cho đến khi một luồng khác chạm vào phía bên kia. Tại thời điểm đó, chúng sẽ được nối vào một luồng duy nhất và tiếp tục thực thi.
• 2 -> 1, nhãn : đây là cách duy nhất để tham gia các đường dẫn thực thi khác nhau. Đây chỉ đơn giản là một no-op có hai đầu vào có thể. Vì vậy, các luồng vào "nhãn" thông qua một trong hai tuyến sẽ chỉ được chuyển hướng vào cùng một hướng.
• 1 -> 2, split : lấy một chuỗi duy nhất và gửi hai bản sao theo các hướng khác nhau.
• 1 -> 1, là Zero? : tiêu thụ bit đầu tiên của luồng và gửi luồng theo một trong hai hướng tùy thuộc vào việc bit là 0 hay 1.
• 1 -> 1, có phải là không? : tiêu thụ toàn bộ danh sách (nghĩa là thay thế nó bằng một danh sách trống) và gửi chuỗi theo một trong hai hướng tùy thuộc vào danh sách đã trống hay chưa.

Vì vậy, trong tâm trí đó, chúng ta có thể tìm ra một chiến lược chung. Sử dụng concatenate, chúng tôi muốn liên tục nối các bit mới vào một chuỗi đại diện cho toàn bộ đầu vào. Chúng ta chỉ đơn giản có thể làm điều này bằng cách lặp đầu ra của concatenate trở lại một trong những đầu vào của nó (và chúng ta khởi tạo nó thành một danh sách trống, bằng cách xóa a {0}bằng isEmpty? ). Câu hỏi là làm thế nào chúng ta có thể chấm dứt quá trình này.

Ngoài việc nối thêm bit hiện tại, chúng tôi cũng sẽ thêm 0 hoặc 1 cho biết chúng tôi đã đạt EOF chưa. Nếu chúng tôi gửi chuỗi của chúng tôi thông qua isZero? , nó sẽ loại bỏ bit đó một lần nữa, nhưng chúng ta hãy phân biệt phần cuối của luồng, trong trường hợp đó chúng ta chỉ cần để luồng rời khỏi cạnh của lưới (khiến Ziim in nội dung của luồng sang STDOUT và chấm dứt chương trình) .

Chúng ta có thể xác định EOF hay không bằng cách sử dụng isEmpty? trên một bản sao của đầu vào.

Đây là sơ đồ tôi đã hứa:

              +----------------------------+   {0} --> isEmpty --> label <--+
              |                            |                    n    |      |
              v                            |                         v      |
    {0} --> label --> read --> split --> split ------------------> concat   |
                                 |                                   |      |
                           n     v     y                             |      |
 inv --> label --> concat <-- isEmpty --> concat <-- label <-- {0}   |      |
  ^        ^          |                     |          ^             |      |
  |        |          v                     v          |             |      |
 {0}       +------- split ---> label <--- split -------+             |      |
                                 |                                   |      |
                                 +-------------> concat <------------+      |
                                                   |                        |
                                              y    v                        |
                         print and terminate <-- isZero --------------------+

Một số lưu ý về nơi bắt đầu đọc:

• Ở {0}góc trên cùng bên trái là trình kích hoạt ban đầu bắt đầu vòng lặp đầu vào.
• Góc {0}trên cùng bên phải ngay lập tức bị xóa vào một danh sách trống, đại diện cho chuỗi ban đầu mà chúng ta sẽ dần dần điền vào đầu vào.
• Hai cái {0}còn lại được đưa vào một vòng lặp "nhà sản xuất" (một đảo ngược, một không), để cung cấp cho chúng tôi một nguồn cung cấp không giới hạn của 0s và 1s mà chúng ta cần phải thêm vào chuỗi.

Lục giác , 6 byte

Điều này từng là 3 byte (xem bên dưới), nhưng phiên bản đó không hoạt động lâu kể từ khi cập nhật mới nhất của ngôn ngữ. Vì tôi không bao giờ cố ý giới thiệu lỗi mà phiên bản đã sử dụng, tôi quyết định không tính nó.

Một giải pháp không có lỗi (tức là một giải pháp hoạt động với trình thông dịch cố định) hóa ra phức tạp hơn nhiều. Tôi đã gặp một số khó khăn khi ép nó vào lưới 2x2, nhưng tôi đã tìm thấy một giải pháp ngay bây giờ, mặc dù tôi cần 7 byte đầy đủ :

<)@,;.(

Sau khi mở ra, chúng tôi nhận được:

Vì cạnh bộ nhớ ban đầu là 0, nên <vô điều kiện làm lệch hướng con trỏ lệnh vào đường chéo Đông Bắc, nơi nó bao bọc theo đường dẫn màu xám. Đây .là một không-op. Bây giờ ,đọc một byte, )tăng nó sao cho các byte hợp lệ (bao gồm cả byte rỗng) là dương và EOF là 0.

Vì vậy, trên EOF, IP kết thúc thành đường dẫn màu đỏ, trong đó @kết thúc chương trình. Nhưng nếu chúng ta vẫn đọc một byte, thì IP sẽ kết thúc đường dẫn màu xanh lá cây thay vào đó là làm (giảm cạnh của giá trị ban đầu, trước khi ;in nó thành STDOUT. IP bây giờ kết thúc vô điều kiện trở lại đường dẫn màu xám, lặp lại quá trình.

Sau khi viết một kịch bản mạnh mẽ cho câu trả lời Máy thật của tôi, tôi đã đặt nó để tìm một giải pháp 6 byte không có lỗi cho chương trình con mèo. Đáng kinh ngạc, nó đã tìm thấy một - có, chính xác một giải pháp trong tất cả các chương trình Hexagony 6 byte có thể. Sau 50 giải pháp từ cỗ máy thật, điều đó khá bất ngờ. Đây là mã:

~/;,@~

Mở ra:

Việc sử dụng ~(phủ định đơn phương) thay vì ()thú vị, bởi vì a) nó không phải là số không, b) nó hoán đổi các cạnh của nhánh, c) trong một số mã, một mã ~có thể được sử dụng hai lần để hoàn tác thao tác với chính nó . Vì vậy, đây là những gì đang xảy ra:

Lần đầu tiên (con đường màu tím) chúng ta đi qua ~đó là một con đường không. Các /phản ánh IP vào đường chéo Tây Bắc. Đường dẫn màu xám hiện đọc một ký tự và nhân mã nhân vật của nó với -1. Điều này biến EOF ( -1) thành giá trị trung thực (dương) và tất cả các ký tự hợp lệ thành giá trị giả (không dương). Trong trường hợp EOF, IP lấy đường dẫn màu đỏ và mã kết thúc. Trong trường hợp ký tự hợp lệ, IP sẽ lấy đường dẫn màu xanh lục, trong đó ~hoàn tác phủ định và ;in ký tự. Nói lại.

Cuối cùng, đây là phiên bản 3 byte được sử dụng để làm việc trong trình thông dịch Hexagony phiên bản gốc.

,;&

Giống như câu trả lời Labyrinth, điều này chấm dứt với một lỗi nếu luồng đầu vào là hữu hạn.

Sau khi mở mã, nó tương ứng với lưới hex sau:

Không .có ops. Thực hiện bắt đầu trên con đường màu tím.

,đọc một byte, ;viết một byte. Sau đó thực hiện tiếp tục trên đường dẫn cá hồi (ish?). Chúng ta cần &thiết lập lại cạnh bộ nhớ hiện tại về 0, sao cho IP nhảy trở lại hàng màu tím khi nhấn vào góc ở cuối hàng thứ hai. Khi ,nhấn EOF, nó sẽ trở lại -1, điều này gây ra lỗi khi ;đang cố in nó.

Sơ đồ được tạo ra với Timwi tuyệt vời 's HexagonyColorer .

TeaScript , 0 byte

TeaScript là một ngôn ngữ chơi golf súc tích được biên dịch thành JavaScript

Trong một bản cập nhật gần đây, đầu vào được thêm vào dưới dạng thuộc tính đầu tiên.

Dùng thử trực tuyến

Ngoài ra, 1 byte

x

xchứa đầu vào trong TeaScript. Đầu ra là ẩn

Brian & Chuck , 44 byte

#{<{,+?+}_+{-?>}<?
_}>?>+<<<{>?_}>>.<+<+{<{?

Ban đầu tôi đã tạo ngôn ngữ này cho Tạo ngôn ngữ lập trình chỉ có vẻ không sử dụng được . Nó hóa ra là một bài tập rất hay cho các vấn đề đơn giản trong golf.

Khái niệm cơ bản: Mỗi dòng trong hai dòng định nghĩa một chương trình giống Brainfuck hoạt động trên mã nguồn của chương trình khác - chương trình đầu tiên được gọi là Brian và dòng thứ hai được gọi là Chuck. Chỉ Brian có thể đọc và chỉ Chuck có thể viết. Thay vì các vòng lặp của Brainfuck, bạn có ?quyền điều khiển cho chương trình khác (và vai trò của con trỏ lệnh và đầu băng cũng thay đổi). Một bổ sung cho Brainfuck là {và }quét băng cho ô khác không đầu tiên (hoặc đầu bên trái). Ngoài ra, _được thay thế bằng byte rỗng.

Mặc dù tôi không nghĩ rằng điều này là tối ưu nhưng tôi khá hài lòng với giải pháp này. Nỗ lực đầu tiên của tôi là 84 byte và sau vài lần chơi golf với Sp3000 (và lấy một số cảm hứng từ những nỗ lực của anh ấy), tôi đã cố gắng giảm dần xuống còn 44, một vài byte mỗi lần. Đặc biệt là +}+mẹo tuyệt vời là ý tưởng của anh ấy (xem bên dưới).

Giải trình

Đầu vào được đọc vào ô đầu tiên trên băng của Chuck, sau đó được sao chép một cách tỉ mỉ vào cuối băng của Brian, nơi nó được in. Bằng cách sao chép nó đến cuối, chúng ta có thể lưu byte khi đặt ký tự trước thành 0.

Đây #chỉ là một trình giữ chỗ, bởi vì điều khiển chuyển đổi không thực thi ô mà chúng ta đã bật. {<{đảm bảo rằng đầu băng nằm trên ô đầu tiên của Chuck. ,đọc một byte từ STDIN hoặc -1nếu chúng ta nhấn EOF. Vì vậy, chúng tôi gia tăng rằng +để làm cho nó bằng 0 đối với EOF và khác không.

Chúng ta hãy giả sử bây giờ chúng ta chưa ở EOF. Vì vậy, tế bào là tích cực và ?sẽ chuyển điều khiển sang Chuck. }>di chuyển người đứng đầu băng (Brian) đến +các _và ?chuyển điều khiển trở lại Brian.

{-bây giờ làm giảm ô đầu tiên trên Chuck. Nếu nó chưa bằng 0, chúng tôi sẽ chuyển điều khiển cho Chuck một lần nữa ?. Lần này }>di chuyển đầu băng trên Brian hai ô bên phải của ô khác không cuối cùng. Ban đầu là ở đây:

#{<{,+?+}_+{-?>}<?__
                   ^

Nhưng sau này, chúng ta sẽ có một số nhân vật ở đó. Chẳng hạn, nếu chúng ta đã đọc và in abc, thì nó sẽ trông như thế này:

#{<{,+?+}_+{-?>}<?11a11b11c__
                            ^

Trong đó các 1s thực sự là 1 byte (chúng ta sẽ thấy những gì về sau).

Ô này sẽ luôn là 0, vì vậy lần này ? sẽ không thay đổi quyền kiểm soát. >di chuyển một ô khác sang bên phải và +tăng ô đó. Đây là lý do tại sao ký tự đầu tiên trong đầu vào kết thúc ba ô ở bên phải của ?(và mỗi ô tiếp theo ba ô bên phải).

<<<di chuyển trở lại ký tự cuối cùng trong danh sách đó (hoặc ?nếu đó là ký tự đầu tiên) và {>quay lại +băng trên của Brian để lặp lại vòng lặp, từ từ chuyển ô đầu vào vào cuối băng của Brian.

Khi ô nhập đó trống, ?sau đó {-sẽ không chuyển điều khiển nữa. Sau đó >}<di chuyển đầu băng trên Chuck sang _và chuyển đổi điều khiển sao cho nửa thứ hai của Chuck được thực thi thay thế.

}>>di chuyển đến ô mà chúng ta đã viết qua phần cuối của băng Brian, đó là byte chúng ta đã đọc từ STDIN, vì vậy chúng tôi in lại .. Để cho }chạy qua nhân vật mới này trên băng chúng ta cần phải thu hẹp khoảng cách của hai byte null, vì vậy chúng tôi tăng họ 1với <+<+(vì vậy đó là lý do tại sao có 1-byte giữa các nhân vật thực tế trên băng cuối cùng). Cuối cùng {<{di chuyển trở lại đầu băng của Brian và ?bắt đầu mọi thứ từ đầu.

Bạn có thể tự hỏi điều gì xảy ra nếu ký tự chúng ta đọc là một byte rỗng. Trong trường hợp đó, tế bào mới được viết sẽ bằng không, nhưng vì nó ở cuối băng của Brian và chúng tôi không quan tâm đến kết thúc đó ở đâu , chúng tôi chỉ đơn giản có thể bỏ qua điều đó. Điều đó có nghĩa là nếu đầu vào là ab\0de, thì băng của Brian thực sự sẽ trông giống như:

#{<{,+?+}_+{-?>}<?11a11b1111d11e

Cuối cùng, một khi chúng tôi đạt EOF, lần đầu tiên ?trên băng của Brian sẽ là không hoạt động. Tại thời điểm này, chúng tôi chấm dứt chương trình. Giải pháp ngây thơ sẽ là di chuyển đến hết băng của Chuck và điều khiển chuyển đổi, sao cho chương trình chấm dứt : >}>}<?. Đây là nơi mà ý tưởng thực sự thông minh của Sp3000 tiết kiệm ba byte:

+biến tế bào đầu tiên của Chuck thành 1. Điều đó có nghĩa là }có một điểm bắt đầu và tìm thấy _ở giữa băng của Chuck. Thay vì bỏ qua nó, chúng ta chỉ cần thu hẹp khoảng cách bằng cách biến nó thành một 1với +. Bây giờ hãy xem phần còn lại của mã Brian xảy ra với Chuck đã sửa đổi này ...

{quay trở lại ô đầu tiên của Chuck như bình thường và -biến nó trở lại thành một byte rỗng. Điều đó có nghĩa ?là không có op. Nhưng bây giờ >}<, thường di chuyển đầu băng vào giữa băng của Chuck, di chuyển ngay qua đầu băng của Chuck và ?sau đó chuyển quyền kiểm soát cho Chuck, chấm dứt mã. Thật tuyệt khi mọi thứ chỉ diễn ra ... :)

Haskell, 16 byte

main=interact id

interactđọc đầu vào, chuyển nó đến hàm được đưa ra làm đối số của nó và in kết quả mà nó nhận được. idlà chức năng nhận dạng, tức là nó trả về đầu vào không thay đổi. Nhờ sự lười biếng của Haskell interactcó thể làm việc với đầu vào vô hạn.

sh + binutils, 3 2 byte

dd

Vâng, không hoàn toàn rõ ràng. Từ @ Random832

Nguyên:

cat

Rõ ràng đau đớn ...: D

Funciton , 16 byte

╔═╗
╚╤╝

(Được mã hóa dưới dạng UTF-16 với BOM)

Giải trình

Hộp trả về nội dung của STDIN. Các đầu ra lỏng lẻo nó.

Mã máy Motorola MC14500B , 1,5 byte

Viết theo hệ thập lục phân:

18F

Viết bằng nhị phân:

0001 1000 1111

Giải trình

1   Read from I/O pin
8   Output to I/O pin
F   Loop back to start

Các opcodes là 4 bit mỗi.

Lưỡi liềm Mornington , 41 byte

Take Northern Line to Mornington Crescent

Tôi không biết liệu Mornington Crescent có thể xử lý các byte null hay không và tất cả các đầu vào được đọc trước khi chương trình bắt đầu, vì đó là bản chất của ngôn ngữ.

Brainfuck, 5 byte

,[.,]

Tương đương với mã giả:

x = getchar()
while x != EOF:
    putchar(x)
    x = getchar()

Điều này xử lý các luồng vô hạn, nhưng coi các byte rỗng là EOF. Việc BF có thể xử lý các byte null thay đổi chính xác từ triển khai đến thực hiện hay không, nhưng điều này giả định cách tiếp cận phổ biến nhất.

Mê cung , 2 byte

,.

Nếu luồng là hữu hạn, điều này sẽ chấm dứt với một lỗi, nhưng tất cả các đầu ra được tạo ra bởi lỗi đều thuộc về STDERR, vì vậy luồng đầu ra tiêu chuẩn là chính xác.

Như trong Brainfuck ,đọc một byte (đẩy nó lên ngăn xếp chính của Labyrinth) và .viết một byte (xuất hiện từ ngăn xếp chính của Labyrinth).

Lý do các vòng lặp này là cả hai ,và .là "ngõ cụt" trong mê cung (rất tầm thường) được đại diện bởi mã nguồn, sao cho con trỏ lệnh chỉ đơn giản quay lại tại chỗ và quay trở lại lệnh khác.

Khi chúng ta nhấn EOF ,đẩy -1thay vào đó và .ném một lỗi vì -1không phải là một mã ký tự hợp lệ. Điều này thực sự có thể thay đổi trong tương lai, nhưng tôi chưa quyết định về điều này.

Để tham khảo, chúng ta có thể giải quyết vấn đề này mà không có lỗi trong 6 byte như sau

,)@
.(

Ở đây, )gia tăng byte mà chúng ta đọc, cung cấp 0tại EOF và một cái gì đó tích cực khác. Nếu giá trị là 0, IP sẽ di chuyển thẳng, nhấn vào điểm @kết thúc chương trình. Nếu giá trị là dương, thay vào đó, IP sẽ rẽ phải theo hướng (giảm dần đỉnh của ngăn xếp về giá trị ban đầu. IP hiện đang ở một góc và chỉ cần tiếp tục rẽ phải, in bằng ., đọc một byte mới với ., trước khi nó chạm ngã ba )một lần nữa.

C, 40 byte

main(i){while(i=~getchar())putchar(~i);}

> <> , 7 byte

i:0(?;o

Hãy thử nó ở đây . Giải trình:

i:0(?;o
i        Take a character from input, pushing -1 if the input is empty
 :0(     Check if the input is less than 0, pushing 1 if true, 0 if false
    ?;   Pop a value of the top of the stack, ending the program if the value is non-zero
      o  Otherwise, output then loop around to the left and repeat

Nếu bạn muốn nó tiếp tục cho đến khi bạn cung cấp thêm đầu vào, hãy thay thế ;bằng !.

Lắp ráp X86, 70 byte

Tháo gỡ với objdump:

00000000 <.data>:
   0:   66 83 ec 01             sub    sp,0x1
   4:   66 b8 03 00             mov    ax,0x3
   8:   00 00                   add    BYTE PTR [eax],al
   a:   66 31 db                xor    bx,bx
   d:   66 67 8d 4c 24          lea    cx,[si+0x24]
  12:   ff 66 ba                jmp    DWORD PTR [esi-0x46]
  15:   01 00                   add    DWORD PTR [eax],eax
  17:   00 00                   add    BYTE PTR [eax],al
  19:   cd 80                   int    0x80
  1b:   66 48                   dec    ax
  1d:   78 1c                   js     0x3b
  1f:   66 b8 04 00             mov    ax,0x4
  23:   00 00                   add    BYTE PTR [eax],al
  25:   66 bb 01 00             mov    bx,0x1
  29:   00 00                   add    BYTE PTR [eax],al
  2b:   66 67 8d 4c 24          lea    cx,[si+0x24]
  30:   ff 66 ba                jmp    DWORD PTR [esi-0x46]
  33:   01 00                   add    DWORD PTR [eax],eax
  35:   00 00                   add    BYTE PTR [eax],al
  37:   cd 80                   int    0x80
  39:   eb c9                   jmp    0x4
  3b:   66 b8 01 00             mov    ax,0x1
  3f:   00 00                   add    BYTE PTR [eax],al
  41:   66 31 db                xor    bx,bx
  44:   cd 80                   int    0x80

Nguồn:

sub esp, 1
t:
mov eax,3
xor ebx,ebx
lea ecx,[esp-1]
mov edx,1
int 0x80
dec eax
js e
mov eax,4
mov ebx,1
lea ecx,[esp-1]
mov edx,1
int 0x80
jmp t
e:
mov eax,1
xor ebx,ebx
int 0x80

Universal Lambda , 1 byte

!

Chương trình Universal Lambda là một mã hóa của thuật ngữ lambda ở dạng nhị phân, được cắt thành các khối 8 bit, đệm các đoạn không hoàn chỉnh với bất kỳ bit nào , được chuyển đổi thành luồng byte.

Các bit được dịch thành một thuật ngữ lambda như sau:

• 00 giới thiệu một trừu tượng lambda.
• 01 đại diện cho một ứng dụng của hai điều khoản tiếp theo.
• 111..10, với n lần lặp lại của bit 1, đề cập đến biến của lambda cha thứ n ; tức là nó là một chỉ số De Bruijn trong unary.

Theo chuyển đổi này, 0010là hàm nhận dạng λa.a, có nghĩa là bất kỳ chương trình byte đơn nào của biểu mẫu 0010xxxxlà một catchương trình.

PowerShell, 88 41 30 byte

$input;write-host(read-host)-n

_{EDIT - quên rằng tôi có thể sử dụng $inputbiến tự động cho đầu vào đường ống} ... _{EDIT2 - không cần kiểm tra sự tồn tại của$input}

Vâng, vậy ... STDIN trong PowerShell là ... kỳ lạ, chúng ta sẽ nói. Với giả định rằng chúng tôi cần chấp nhận đầu vào từ tất cả các loại STDIN, đây là một câu trả lời có thể có cho danh mục này và tôi chắc chắn có những loại khác. ¹

Mặc dù vậy, đầu vào đường ống trong PowerShell không hoạt động như bạn nghĩ. Vì đường ống trong PowerShell là một chức năng của ngôn ngữ và không phải là chức năng của môi trường / trình bao (và PowerShell thực sự không chỉ là một ngôn ngữ), nên có một số hành vi kỳ quặc.

Đối với người mới bắt đầu và có liên quan nhất đến mục này, đường ống không được đánh giá ngay lập tức (hầu hết thời gian). Có nghĩa là, nếu chúng ta có command1 | command2 | command3trong vỏ của mình, command2sẽ không nhận đầu vào hoặc bắt đầu xử lý cho đến khi command1hoàn thành ... trừ khi bạn đóng gói của bạn command1bằng một ForEach-Object... khác với ForEach. _{(mặc dù ForEachlà bí danh cho ForEach-Object, nhưng đó là một vấn đề riêng biệt, vì tôi đang nói ForEachnhư một tuyên bố, không phải bí danh)}

Điều này có nghĩa là một cái gì đó như yes | .\simple-cat-program.ps1(mặc dù yeskhông thực sự tồn tại, nhưng bất cứ điều gì) sẽ không hoạt động vì yessẽ không bao giờ hoàn thành. Nếu chúng ta có thể làm điều ForEach-Object -InputObject(yes) | .\simple-cat-program.ps1đó thì (về lý thuyết) sẽ hoạt động.

Tìm hiểu về ForEach và ForEach-Object trên Microsoft "Hey, Scripting Guy!" Blog.

Vì vậy, tất cả những đoạn đó đang giải thích tại sao if($input){$input}tồn tại. Chúng tôi lấy một tham số đầu vào được tạo tự động đặc biệt nếu có đầu vào đường ống, kiểm tra xem nó có tồn tại không và nếu có, hãy xuất nó.

Sau đó, chúng tôi lấy đầu vào từ người dùng (read-host)thông qua luồng STDIN riêng biệt và luồng write-hostra ngoài, với -ncờ (viết tắt là -NoNewLine). Lưu ý rằng điều này không hỗ trợ đầu vào độ dài tùy ý, vì read-hostsẽ chỉ hoàn thành khi nhập nguồn cấp dữ liệu (về mặt kỹ thuật khi người dùng nhấn "Enter", nhưng tương đương về chức năng).

Phù.

¹ Nhưng có những lựa chọn khác:

Ví dụ, nếu chúng ta quan tâm đến việc chỉ đầu vào đường ống, và chúng tôi không đòi hỏi một chương trình đầy đủ, bạn có thể làm một cái gì đó như | $_đó sẽ chỉ ra bất cứ điều gì là đầu vào. _{(Nói chung, điều đó hơi dư thừa, vì PowerShell có đầu ra ngầm của những thứ "bị bỏ lại phía sau" sau khi tính toán, nhưng đó là một bên.)}

Nếu chúng tôi chỉ quan tâm đến đầu vào của người dùng tương tác, chúng tôi có thể sử dụng chỉ write-host(read-host)-n.

Thêm vào đó, chức năng này có những đứa tính năng chấp nhận dòng lệnh đầu vào, ví dụ .\simple-cat-program.ps1 "test"sẽ cư (và sau đó đầu ra) các $abiến.

Hình khối , 6 5 byte

Bây giờ xử lý byte rỗng!

@_i?o

Cubix là một esolang 2 chiều, dựa trên ngăn xếp. Cubix khác với các lang 2D khác ở chỗ mã nguồn được bao bọc bên ngoài khối lập phương.

Kiểm tra nó trực tuyến! Lưu ý: có độ trễ 50 ms giữa các lần lặp.

Giải trình

Điều đầu tiên trình thông dịch làm là tìm ra khối lập phương nhỏ nhất mà mã sẽ phù hợp. Trong trường hợp này, độ dài cạnh là 1. Sau đó, mã được đệm bằng no-op .cho đến khi tất cả sáu mặt được lấp đầy. Khoảng trắng được xóa trước khi xử lý, vì vậy mã này giống hệt như trên:

  @
_ i ? o
  .

Bây giờ mã được chạy. IP (con trỏ lệnh) bắt đầu ở phía bên trái, chỉ về hướng đông.

Char đầu tiên mà IP gặp phải là _gương phản chiếu IP xung quanh nếu nó quay mặt về hướng bắc hoặc nam; Hiện tại nó đang hướng về phía đông, vì vậy điều này không có gì. Tiếp theo là i, đầu vào một byte từ STDIN. ?xoay IP sang trái nếu mục trên cùng là âm hoặc phải nếu nó dương. Có ba con đường có thể ở đây:

• Nếu byte được nhập là -1 (EOF), IP sẽ rẽ trái và chạm @, kết thúc chương trình.
• Nếu byte được nhập vào là 0 (byte null), IP chỉ cần tiếp tục đi thẳng, xuất ra byte với o.
• Nếu không, IP rẽ phải, đi qua mặt dưới và chạm vào gương _. Điều này xoay nó lại, gửi nó trở lại ?, nó quay lại đúng và xuất ra byte.

Tôi nghĩ rằng chương trình này là tối ưu. Trước khi Cubix có thể xử lý byte null (EOF là 0, không phải -1), chương trình này hoạt động cho mọi thứ trừ byte null:

.i!@o

Tôi đã viết một chuyên gia vũ phu để tìm tất cả các chương trình mèo 5 byte. Mặc dù phải mất ~ 5 phút để hoàn thành, phiên bản mới nhất đã tìm thấy 5 chương trình:

@_i?o   (works as expected)
@i?o_   (works in exactly the same way as the above)
iW?@o   (works as expected)
?i^o@   (false positive; prints U+FFFF forever on empty input)
?iWo@   (works as expected)

Vitsy, 2 byte

zZ

znhận được tất cả các ngăn xếp đầu vào và đẩy nó vào ngăn xếp chương trình hoạt động. Zin ra tất cả các ngăn xếp hoạt động để STDOUT.

Phương pháp luân phiên:

Tôi \ il \ O
Tôi \ Lặp lại ký tự tiếp theo cho chiều dài của ngăn xếp đầu vào.
  i Lấy một mục từ đầu vào.
   l \ Lặp lại ký tự tiếp theo cho độ dài của ngăn xếp chương trình hiện đang hoạt động.
     O Xuất ra mục trên cùng của ngăn xếp dưới dạng ký tự.

MarioLANG , 11 byte

,<
."
>!
=#

Tôi không hoàn toàn chắc chắn điều này là tối ưu, nhưng nó là ngắn nhất tôi tìm thấy.

Điều này hỗ trợ các luồng vô hạn và sẽ chấm dứt với một lỗi khi đạt EOF (ít nhất là việc triển khai tham chiếu Ruby không).

Có một phiên bản khác biến Mario thành một ninja có thể nhảy đôi:

,<
.^
>^
==

Trong cả hai trường hợp, Mario bắt đầu rơi xuống cột bên trái, trong đó ,đọc một byte và .ghi một byte (điều này gây ra lỗi tại EOF vì ,không trả về một ký tự hợp lệ). >đảm bảo rằng Mario đi bên phải ( =chỉ là một mặt đất để anh ta đi bộ). Sau đó, anh ta di chuyển lên, thông qua một cú nhảy đôi bằng ^hoặc qua thang máy ( "và #cặp) trước khi <bảo anh ta quay trở lại cột bên trái.

rs , 0 byte

Nghiêm túc. rs chỉ in bất cứ thứ gì nó nhận được nếu tập lệnh đã cho hoàn toàn trống rỗng.

GolfScript, 3 byte

:n;

Các chương trình trống lặp lại đầu vào tiêu chuẩn. Ngôn ngữ không thể xử lý các luồng vô hạn. Tuy nhiên, nó nối thêm một dòng mới, như @Dennis đã đề cập. Nó làm như vậy bằng cách gói toàn bộ ngăn xếp trong một mảng và gọi puts, được định nghĩa là print n print, nơi nlà một dòng mới. Tuy nhiên, chúng ta có thể định nghĩa lại nlà STDIN, và sau đó làm trống ngăn xếp, đó chính xác là những gì :n;.

Xe bị hỏng một nửa trong lưu lượng lớn , 9 + 3 = 12 byte

#<
o^<
 v

Một nửa chiếc xe bị hỏng trong giao thông nặng (HBCHT) nhận đầu vào là dòng lệnh lập luận, vì vậy hãy chạy như

py -3 hbcht cat.hbc -s "candy corn"

Lưu ý rằng +3 dành cho -scờ, xuất ra dưới dạng ký tự. Ngoài ra, HBCHT dường như không xử lý NUL, vì tất cả các số 0 được loại bỏ khỏi đầu ra (ví dụ: 97 0 98đầu ra là hai ký tự ab).

Giải trình

Trong HBCHT, xe của bạn bắt đầu tại ovà mục tiêu của bạn là lối ra #. ^>v<chỉ đạo chuyển động của xe, đồng thời sửa đổi băng giống như BF ( ^>v<dịch sang +>-<). Tuy nhiên, như tên ngôn ngữ cho thấy, xe của bạn chỉ có thể rẽ phải - mọi nỗ lực rẽ trái đều bị bỏ qua hoàn toàn (bao gồm cả hiệu ứng bộ nhớ của chúng). Lưu ý rằng điều này chỉ dành cho quay đầu - xe của bạn hoàn toàn có khả năng lái về phía trước / đảo chiều.

Các phần thú vị khác về HBCHT là hướng ban đầu của xe của bạn là ngẫu nhiên và lưới là hình xuyến. Vì vậy, chúng tôi chỉ cần chiếc xe để đi đến lối ra mà không sửa đổi băng cho cả bốn hướng ban đầu:

• Lên và xuống là đơn giản, hướng thẳng đến lối ra.

• Đối với bên trái, chúng tôi bọc và thực hiện <và tăng với ^. Chúng ta không thể rẽ trái ở lần tiếp theo <để chúng ta kết thúc và giảm dần v, phủ nhận mức tăng trước đó. Vì chúng ta đang đi xuống bây giờ, chúng ta có thể rẽ phải tại <và thoát, đã di chuyển con trỏ hai lần và sửa đổi không có giá trị ô.

• Đối với bên phải, chúng tôi làm tương tự như bên trái nhưng bỏ qua lần đầu tiên ^vì chúng tôi không thể rẽ trái.

Chỉnh sửa : Hóa ra trình thông dịch HBCHT không cho phép bạn thực thi chỉ một đường dẫn thông qua cờ dòng lệnh, ví dụ:

py -3 hbcht -d left cat.hbc

Tuy nhiên, cờ không chỉ quá đắt đối với câu hỏi cụ thể này (ít nhất là 5 byte cho " -d u"), có vẻ như tất cả các đường dẫn vẫn cần có thể đưa nó đến lối ra để mã thực thi.

Chồn , 5 byte

od?.O

Hãy thử nó ở đây.

Giải trình

ođọc một ký tự từ đầu vào và đẩy mã ASCII của nó lên ngăn xếp ( 0nếu đầu vào trống). dsau đó nhân đôi đỉnh ngăn xếp (ký tự vừa đọc). ?là một tấm bạt lò xo có điều kiện, trong đó không có lệnh nhảy tiếp theo của đỉnh ngăn xếp 0. Nếu đầu vào trống, thì .không được nhảy và chương trình tạm dừng. Nếu không, Oxuất ra đầu ngăn xếp như một ký tự. Bản chất hình xuyến của Minkolang có nghĩa là vòng lặp này bắt đầu từ đầu.

INTERCALL , 133 byte

wat

INTERCALL IS A ANTIGOLFING LANGUAGE
SO THIS HEADER IS HERE TO PREVENT GOLFING IN INTERCALL
THE PROGRAM STARTS HERE:
READ
PRINT
GOTO I

V , 0 byte

Hãy thử trực tuyến!

Ý tưởng về "bộ nhớ" của V chỉ là một mảng các ký tự 2D khổng lồ. Trước khi bất kỳ chương trình nào được chạy, tất cả đầu vào nó được tải vào mảng này (được gọi là "Bộ đệm"). Sau đó, ở cuối bất kỳ chương trình nào, tất cả văn bản trong bộ đệm được in.

Nói cách khác, chương trình trống là chương trình mèo.

Người tuyết 1.0.2 , 15 ký tự

(:vGsP10wRsp;bD

Lấy trực tiếp từ examplesthư mục của Snowman . Đọc một dòng, in một dòng, đọc một dòng, in một dòng ...

Lưu ý rằng do một chi tiết triển khai, khi STDIN trống, vgsẽ trả về điều tương tự như đối với một dòng trống. Do đó, điều này sẽ liên tục in các dòng mới trong một vòng lặp vô hạn sau khi STDIN được đóng lại. Điều này có thể được sửa trong một phiên bản trong tương lai.

Giải thích về mã:

(        // set two variables (a and f) to active—this is all we need
:...;bD  // a "do-loop" which continues looping as long as its "return value"
         // is truthy
  vGsP   // read a line, print the line
  10wRsp // print a newline—"print" is called in nonconsuming mode; therefore,
         // that same newline will actually end up being the "return value" from
         // the do-loop, causing it to loop infinitely

FireType , 7 byte

,
&
_
=

Yêu cầu một số thay đổi tôi chỉ cần đẩy . Các quy tắc nói:

Không giống như các quy tắc thông thường của chúng tôi, vui lòng sử dụng ngôn ngữ (hoặc phiên bản ngôn ngữ) ngay cả khi nó mới hơn thử thách này.

Vì vậy, tôi rõ ràng!

Phân hạch , 4 byte

R?J!

Thật tuyệt khi bạn đánh bại các chương trình mẫu trong kho lưu trữ của ngôn ngữ? :) Để tham khảo, nó có giải pháp 7 byte

R?J0;0!

Giải trình

Vì vậy, Rbắt đầu dòng điều khiển với một nguyên tử đi đúng. ?đọc một ký tự từ STDIN vào khối lượng của nguyên tử. Miễn là chúng ta đọc các ký tự, năng lượng vẫn bằng không, do đó, khối lượng Jlà không có tác dụng và !in ký tự. Các vòng lặp nguyên tử trở lại từ đầu ( Rbây giờ là không hoạt động) và lặp lại toàn bộ quá trình.

Khi chúng ta nhấn EOF, ?sẽ đặt năng lượng của nguyên tử thành 1, do đó, khối Jsẽ bỏ qua lệnh in. Nhưng khi một nguyên tử tấn công ? sau khi EOF đã được trả lại, nó sẽ phá hủy nguyên tử thay vào đó, nó chấm dứt chương trình.

(Giải pháp từ tác giả của ngôn ngữ sử dụng một tường minh ;để chấm dứt chương trình, được bỏ qua với hai 0cổng khác.)

Shtriped , 20 byte

e )
"
 r )
 s )
 "
"

Điều này táo bạo chứng minh rằng gần như bất kỳ chuỗi ASCII có thể in nào là một định danh hợp lệ trong Shtriped.

Làm thế nào nó hoạt động:

e )   \ declares a variable named )
"     \ defines a function with 0 arguments named "
 r )  \ gets a line of string input, saving it to )
 s )  \ prints ) as a string
 "    \ recursively calls ", effectively looping forever
"     \ calls " from the main scope to get things started

Không có cách nào thực sự để phát hiện EOF, vì vậy vòng lặp này mãi mãi giống như câu trả lời của Python .

Bạn có thể dễ dàng làm cho nó dừng lại khi một dòng trống được đưa ra mặc dù (30 byte):

e )
"
 r )
 d ) \ tries to decrement ), if it was the empty string, aka 0, it can't, so 0 is returned all the way up
 i ) \ increment ) to put it back to normal after possibly decrementing
 s )
 "
"

Lưu ý rằng I / O Shtriped chỉ hỗ trợ ASCII có thể in , các tab, nguồn cấp dữ liệu, trả về vận chuyển, tab dọc và nguồn cấp mẫu (tổng cộng 100 ký tự). Điều này là do bên trong, các chuỗi được biểu diễn dưới dạng các số nguyên chính xác tùy ý không âm và phải có một bảng chữ cái hữu hạn của các ký tự để có thể mã hóa tất cả các chuỗi.