A quine is a computer program that takes no input and produces a copy of its own source code as its only output. The standard terms for these programs in the computability theory and computer science literature are "self-replicating programs", "self-reproducing programs", and "self-copying programs".
A quine is a fixed point of an execution environment, when that environment is viewed as a function transforming programs into their outputs. Quines are possible in any Turing-complete programming language, as a direct consequence of Kleene's recursion theorem. For amusement, programmers sometimes attempt to develop the shortest possible quine in any given programming language.
The name "quine" was coined by Douglas Hofstadter, in his popular 1979 science book Gödel, Escher, Bach, in honor of philosopher Willard Van Orman Quine (1908–2000), who made an extensive study of indirect self-reference, and in particular for the following paradox-producing expression, known as Quine's paradox:
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
John von Neumann theorized about self-reproducing automata in the 1940s. Later, Paul Bratley and Jean Millo's article "Computer Recreations: Self-Reproducing Automata" discussed them in 1972.[1] Bratley first became interested in self-reproducing programs after seeing the first known such program written in Atlas Autocode at Edinburgh in the 1960s by the University of Edinburgh lecturer and researcher Hamish Dewar.
The "download source" requirement of the GNU Affero General Public License is based on the idea of a quine.[2]
The shortest non-trivial quine in a major programming language (a "proper" quine) known as of 2020 is the 21 character JavaScript ES6 program ($=_=>`($=${$})`).[3]
In general, the method used to create a quine in any programming language is to have, within the program, two pieces: code used to do the actual printing and data that represents the textual form of the code. The code functions by using the data to print the code (which makes sense since the data represents the textual form of the code), but it also uses the data, processed in a simple way, to print the textual representation of the data itself.
Here are three small examples in Python3:
c: str = 'c: str = %r; print(c %% c)'; print(c % c)
The following classic Java code (Java 1.5) demonstrates the basic structure of a quine.
This code was adapted from an original post from c2.com, where the author, Jason Wilson, posted it as a minimalistic version of a Quine, without Java comments.[4]
Following the introduction of the text blocks feature in Java 15,[5] a more readable and simpler version is possible:[6]
This is an example of a modern version of Java 25 code:
The same idea is used in the following SQL quine:
Some programming languages have the ability to evaluate a string as a program. Quines can take advantage of this feature. For example, this Ruby quine:
Lua can do:
In Python 3.8:
In many functional languages, including Scheme and other Lisps, and interactive languages such as APL, numbers are self-evaluating. In TI-BASIC, if the last line of a program returns a value, the returned value is displayed on the screen. Therefore, in such languages a program consisting of only a single digit results in a 1-byte quine. Since such code does not construct itself, this is often considered cheating.
In some languages, particularly scripting languages, an empty source file is a fixed point of the language, being a valid program that produces no output.
Such an empty program, submitted as "the world's smallest self reproducing program", once won the "worst abuse of the rules" prize in the International Obfuscated C Code Contest.[7] The program was not valid C (lacking a main function) and was not actually compiled, but came with a Makefile which used cp to copy the empty file into another file, which would be executed as a shell script to print nothing.[8]
Quines, per definition, cannot receive any form of input, including reading a file, which means a quine is considered to be "cheating" if it looks at its own source code. The following shell script is not a quine:
cat $0
A shorter variant, exploiting the behaviour of shebang directives:
Other questionable techniques include making use of compiler messages; for example, in the GW-BASIC environment, entering "Syntax Error" will cause the interpreter to respond with "Syntax Error".
Quine code can also be outputted visually, for example it's used to visualize the neutral zone in Yars' Revenge, along with syntactic saccharin, to obfuscate the source code.
The quine concept can be extended to multiple levels of recursion, giving rise to "ouroboros programs", or quine-relays. This should not be confused with multiquines.
This Java program outputs the source for a C++ program that outputs the original Java code.
int main(int argc, char* argv[]) ", "
1 1"[13,213].max_by
| s.size |
/#}/.i rescue##/
eval eval"[eval||=9,instance_eval||=9].max_by
| s.size |
Using relational programming techniques, it is possible to generate quines automatically by transforming the interpreter (or equivalently, the compiler and runtime) of a language into a relational program, and then solving for a fixed point.[9]
A hashquine is a file that contains its own cryptographic hash. It is related to a quine but works differently. A quine is a program that produces its own source as output, while a hashquine is usually a static file, such as an image or binary, that has been constructed so that its cryptographic digest (for example SHA-256) appears inside the file itself.
Creating a hashquine normally involves giving the file a region of adjustable bytes and then searching for values that cause the final hash to match the value embedded inside the file. Some hashquines appear as images where the displayed hash is part of the picture and the entire image also hashes to that same value.
Hashquines do not execute or print anything. They illustrate fixed points in cryptographic hash functions and are considered a conceptual relative of quines rather than a type of quine in the strict programming sense.
"Reflections on Trusting Trust" (Communications of the ACM, 27(8):761-3)
