diff --git a/1984/rules.txt b/1984/rules.txt index 819a4bafa..d3bb47438 100644 --- a/1984/rules.txt +++ b/1984/rules.txt @@ -6,7 +6,7 @@ from both Landon Curt Noll and Larry Bassel. I'm sure you have all seen gross, or down right structurally obscene C source code before. Some people who deal with various parts of the -UN*X source wonder if some folks try rather hard to produce such +UNIX source wonder if some folks try rather hard to produce such down right smelly code. Now you have the chance to compete with the worst C hackers around @@ -37,7 +37,7 @@ but dont let the lack of a 780 or 4.2 discourage you! chongo /\CC/\ -UN*X is a trademark of Usenet Hackers Anonymous +UNIX is a trademark of Usenet Hackers Anonymous WARNING: The rules and mailing address for the contest change from year to year. Be sure that you consult the current set of rules diff --git a/1987/biggar/README.md b/1987/biggar/README.md index 09a7575d4..3429f8c80 100644 --- a/1987/biggar/README.md +++ b/1987/biggar/README.md @@ -32,7 +32,7 @@ want. This is a very efficient way to transfer source, though it increases the size of Makefiles. With only slight variations, this program can be set to many uses. -Consider how easy it would be to release `Un*x` source in this form; +Consider how easy it would be to release `Unix` source in this form; so what if the Makefiles grow a little! :-) One vendor's lint got hung in an infinite loop over this entry! diff --git a/1987/korn/README.md b/1987/korn/README.md index 4c67c6dec..a5f3bced8 100644 --- a/1987/korn/README.md +++ b/1987/korn/README.md @@ -16,7 +16,7 @@ make all ## Judges' remarks: The Judges believe that this is the best one line entry ever received. -Compile on a `UN*X` system, or at least using a C implementation that +Compile on a `UNIX` system, or at least using a C implementation that fakes it. Very few people are able to determine what this program does by visual inspection. I suggest that you stop reading this section right now and see if you are one of the few people who can. diff --git a/1987/rules.txt b/1987/rules.txt index 0c601faf9..86f71af74 100644 --- a/1987/rules.txt +++ b/1987/rules.txt @@ -57,7 +57,7 @@ X * If you give a 'postal address', please include your Country. - * Give the machine and operating system (i.e., Un*x version) on + * Give the machine and operating system (i.e., Unix version) on which your program ran. * The 'remarks' item is not optional. Please indicate: @@ -149,7 +149,7 @@ JUDGING: Points will be taken away for programs that: - * are very hardware or Un*x version specific + * are very hardware or Unix version specific * dump core or have compiler warnings (we won't take points away if you warn us in the remark item) * fail to compile diff --git a/1988/rules.txt b/1988/rules.txt index e19c5dfa6..08f21353f 100644 --- a/1988/rules.txt +++ b/1988/rules.txt @@ -158,12 +158,12 @@ POINTS TO PONDER: We tend to dislike programs that: * are very hardware specific - * are very OS or Un*x version specific + * are very OS or Unix version specific (index/strchr differences are ok, but socket/streams specific code is likely not to be) * dump core or have compiler warnings (it is ok only if you warn us in the 'remark' header item) - * won't compile under both BSD or SYS V Un*x + * won't compile under both BSD or SYS V Unix * use an excessively long compile line to get around the size limit * are longer than they need to be diff --git a/1989/rules.txt b/1989/rules.txt index 30e109e9a..bc0409feb 100644 --- a/1989/rules.txt +++ b/1989/rules.txt @@ -154,12 +154,12 @@ POINTS TO PONDER: We tend to dislike programs that: * are very hardware specific - * are very OS or Un*x version specific + * are very OS or Unix version specific (index/strchr differences are ok, but socket/streams specific code is likely not to be) * dump core or have compiler warnings (it is ok only if you warn us in the 'remark' header item) - * won't compile under both BSD or SYS V Un*x + * won't compile under both BSD or SYS V Unix * use an excessively long compile line to get around the size limit * are longer than they need to be diff --git a/1990/rules.txt b/1990/rules.txt index 605a06c69..8ca63254b 100644 --- a/1990/rules.txt +++ b/1990/rules.txt @@ -174,12 +174,12 @@ POINTS TO PONDER: We tend to dislike programs that: * are very hardware specific - * are very OS or Un*x version specific + * are very OS or Unix version specific (index/strchr differences are ok, but socket/streams specific code is likely not to be) * dump core or have compiler warnings (it is ok only if you warn us in the 'remark' header item) - * won't compile under both BSD or SYS V Un*x + * won't compile under both BSD or SYS V Unix * use an excessively long compile line to get around the size limit * are longer than they need to be * are similar to previous winners diff --git a/1991/rules.txt b/1991/rules.txt index b3b9c60ac..fde90e4e2 100644 --- a/1991/rules.txt +++ b/1991/rules.txt @@ -209,12 +209,12 @@ POINTS TO PONDER: We tend to dislike programs that: * are very hardware specific - * are very OS or Un*x version specific + * are very OS or Unix version specific (index/strchr differences are ok, but socket/streams specific code is likely not to be) * dump core or have compiler warnings (it is ok only if you warn us in the 'remark' header item) - * won't compile under both BSD or SYS V Un*x + * won't compile under both BSD or SYS V Unix * use an excessively long compile line to get around the size limit * obfuscate by excessive use of ANSI trigraphs * are longer than they need to be diff --git a/1992/guidelines.txt b/1992/guidelines.txt index ce32b7b82..c8206c1ae 100644 --- a/1992/guidelines.txt +++ b/1992/guidelines.txt @@ -136,12 +136,12 @@ OUR LIKES AND DISLIKES: We tend to dislike programs that: * are very hardware specific - * are very OS or Un*x version specific + * are very OS or Unix version specific (index/strchr differences are ok, but socket/streams specific code is likely not to be) * dump core or have compiler warnings (it is ok only if you warn us in the 'remark' header item) - * won't compile under both BSD or SYS V Un*x + * won't compile under both BSD or SYS V Unix * abusing the build file to get around the size limit * obfuscate by excessive use of ANSI trigraphs * are longer than they need to be @@ -250,7 +250,7 @@ rule: 1992 title: chonglab entry: 0 date: Mon Feb 17 13:58:57 1992 -host: Un*x v6, pdp11/45 +host: Unix v6, pdp11/45 2.9BSD, pdp11/70 ---remark--- This is a non-obfuscated obfuscated C program. diff --git a/1993/guidelines.txt b/1993/guidelines.txt index fac8a5c0f..29de41d9c 100644 --- a/1993/guidelines.txt +++ b/1993/guidelines.txt @@ -161,12 +161,12 @@ OUR LIKES AND DISLIKES: We tend to dislike programs that: * are very hardware specific - * are very OS or Un*x version specific + * are very OS or Unix version specific (index/strchr differences are ok, but socket/streams specific code is likely not to be) * dump core or have compiler warnings (it is ok only if you warn us in the 'remark' header item) - * won't compile under both BSD or SYS V Un*x + * won't compile under both BSD or SYS V Unix * abusing the build file to get around the size limit * obfuscate by excessive use of ANSI trigraphs * are longer than they need to be @@ -275,7 +275,7 @@ fix: n title: chonglab entry: 0 date: Mon Mar 1 08:45:20 1993 -host: Un*x v6, pdp11/45 +host: Unix v6, pdp11/45 2.9BSD, pdp11/70 ---remark--- This is a non-obfuscated obfuscated C program. diff --git a/1993/rince/README.md b/1993/rince/README.md index fccb1a902..270e01cd4 100644 --- a/1993/rince/README.md +++ b/1993/rince/README.md @@ -171,7 +171,7 @@ Alliant FX2800 Conentrix 3.0.0 fxc --- \* I never said it worked! The guidelines state that you dislike programs that -won't *compile* under both BSD or SysV `Un*x`. This compiles, and indeed runs +won't *compile* under both BSD or SysV `Unix`. This compiles, and indeed runs on all the others (both BSD and SysV) correctly. Alas, on Solaris it compiles, but mysteriously stops displaying output diff --git a/1994/guidelines.txt b/1994/guidelines.txt index a1cf9c9e0..ea266ba41 100644 --- a/1994/guidelines.txt +++ b/1994/guidelines.txt @@ -173,12 +173,12 @@ OUR LIKES AND DISLIKES: We tend to dislike programs that: * are very hardware specific - * are very OS or Un*x version specific + * are very OS or Unix version specific (index/strchr differences are ok, but socket/streams specific code is likely not to be) * dump core or have compiler warnings (it is ok only if you warn us in the 'remark' header item) - * won't compile under both BSD or SYS V like Un*x systems | + * won't compile under both BSD or SYS V like Unix systems | * abusing the build file to get around the size limit * obfuscate by excessive use of ANSI trigraphs * are longer than they need to be @@ -345,7 +345,7 @@ fix: n title: chonglab entry: 0 date: Thu Mar 3 13:23:14 1994 -host: Un*x v6, pdp11/45 +host: Unix v6, pdp11/45 2.9BSD, pdp11/70 ---remark--- This is a non-obfuscated obfuscated C program. diff --git a/1995/guidelines.txt b/1995/guidelines.txt index 083aa44da..fb8f7fb75 100644 --- a/1995/guidelines.txt +++ b/1995/guidelines.txt @@ -245,15 +245,15 @@ OUR LIKES AND DISLIKES: .Xdefaults. If you must do so, be sure to note the required lines in the ---remark--- section. - While we recognize that UN*X is not a universal operating system, the | + While we recognize that UNIX is not a universal operating system, the | contest does have a bias towards such systems. In an effort to expand | the scope of the contest, we phrase our bias in terms of POSIX P1003.1 | - and P1003.2 standards. This will allow certain non-UN*X OS users to | + and P1003.2 standards. This will allow certain non-UNIX OS users to | submit entries. On the other hand, this is a guideline and not a rule. | We will not reject an entry based on some POSIX technicality. | When dealing with OS and application environments, we suggest that you | - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will | + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will | evolve but not as much as the contest, so avoid stuff like POSIX real | time, security, etc. | @@ -356,7 +356,7 @@ fix: y title: chonglabram entry: 0 date: Mon Oct 23 07:04:32 1995 -host: Un*x v6, pdp11/45 +host: Unix v6, pdp11/45 2.9BSD, pdp11/70 ---remark--- This is a not-very-obfuscated C program. It is likely not to win a diff --git a/1996/guidelines.txt b/1996/guidelines.txt index 248b2eff0..c0100bac9 100644 --- a/1996/guidelines.txt +++ b/1996/guidelines.txt @@ -252,15 +252,15 @@ OUR LIKES AND DISLIKES: .Xdefaults. If you must do so, be sure to note the required lines in the ---remark--- section. - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest, so avoid stuff like POSIX real time, security, etc. @@ -369,7 +369,7 @@ fix: y title: chonglabram entry: 0 date: Mon Oct 28 00:47:00 1996 -host: Un*x v6, pdp11/45 +host: Unix v6, pdp11/45 2.9BSD, pdp11/70 ---remark--- This is a not-very-obfuscated C program. It is likely not to win a diff --git a/1998/guidelines.txt b/1998/guidelines.txt index 79690b068..ead6e5a49 100644 --- a/1998/guidelines.txt +++ b/1998/guidelines.txt @@ -272,15 +272,15 @@ OUR LIKES AND DISLIKES: .Xdefaults. If you must do so, be sure to note the required lines in the ---remark--- section. - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest, so avoid stuff like POSIX real time, security, etc. @@ -389,7 +389,7 @@ fix: y title: chlejhse entry: 0 date: Mon Oct 28 00:47:00 1998 -host: Un*x v6, pdp11/45 +host: Unix v6, pdp11/45 2.9BSD, pdp11/70 ---remark--- This is a not-very-obfuscated C program. It is likely not to win a diff --git a/2000/guidelines.txt b/2000/guidelines.txt index 1071dff5f..47efba3ce 100644 --- a/2000/guidelines.txt +++ b/2000/guidelines.txt @@ -242,15 +242,15 @@ OUR LIKES AND DISLIKES: .Xdefaults. If you must do so, be sure to note the required lines in the ---remark--- section. - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest, so avoid stuff like POSIX real time, security, etc. @@ -359,7 +359,7 @@ fix: y title: chlejhse entry: 0 date: Wed Feb 2 00:47:00 2000 | -host: Un*x v6, pdp11/45 +host: Unix v6, pdp11/45 2.9BSD, pdp11/70 ---remark--- This is a not-very-obfuscated C program. It is likely not to win a diff --git a/2001/guidelines.txt b/2001/guidelines.txt index 286d23ead..cd63d87a3 100644 --- a/2001/guidelines.txt +++ b/2001/guidelines.txt @@ -194,7 +194,7 @@ OUR LIKES AND DISLIKES: if you show some amount of restraint. | You should try to restrict commands used on the build file to | - POSIX-like or common Un*x-like commands. You can also compile | + POSIX-like or common Unix-like commands. You can also compile | and use your own programs. If you do, try to build and execute | from the current directory. This restriction is not a hard and | absolute one. The intent is to ensure that the building if your | @@ -268,15 +268,15 @@ OUR LIKES AND DISLIKES: .Xdefaults. If you must do so, be sure to note the required lines in the ---remark--- section. - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest, so avoid stuff like POSIX real time, security, etc. @@ -305,7 +305,7 @@ OUR LIKES AND DISLIKES: your while to write a remarkable ---remark--- section. | We dislike C code with trailing control-M's (\r or \015) that results | - in compilation failures. Some non-Un*x/non-Linux tools such as | + in compilation failures. Some non-Unix/non-Linux tools such as | MS Visual C and MS Visual C++ leave trailing control-M's on lines. | Users of such tools should strip off such control-M's before submitting | their entries. In some cases tools have a "Save As" option that will | @@ -407,7 +407,7 @@ fix: y title: chlejhse entry: 0 date: Wed Feb 2 00:47:00 2001 | -host: Un*x v6, pdp11/45 +host: Unix v6, pdp11/45 2.9BSD, pdp11/70 ---remark--- This is a not-very-obfuscated C program. It is likely not to win a diff --git a/2004/guidelines.txt b/2004/guidelines.txt index 1eaf7ceba..6e0906330 100644 --- a/2004/guidelines.txt +++ b/2004/guidelines.txt @@ -195,7 +195,7 @@ OUR LIKES AND DISLIKES: if you show some amount of restraint. You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your @@ -269,15 +269,15 @@ OUR LIKES AND DISLIKES: .Xdefaults. If you must do so, be sure to note the required lines in the program "remarks". - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest, so avoid stuff like POSIX real time, security, etc. @@ -306,7 +306,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/2005/guidelines.txt b/2005/guidelines.txt index dbe13365d..eb8045b1b 100644 --- a/2005/guidelines.txt +++ b/2005/guidelines.txt @@ -198,7 +198,7 @@ OUR LIKES AND DISLIKES: if you show some amount of restraint. You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your @@ -272,15 +272,15 @@ OUR LIKES AND DISLIKES: .Xdefaults. If you must do so, be sure to note the required lines in the program "remarks". - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest, so avoid stuff like POSIX real time, security, etc. @@ -309,7 +309,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/2005/mynx/README.md b/2005/mynx/README.md index 80db5e74a..c4d60c86f 100644 --- a/2005/mynx/README.md +++ b/2005/mynx/README.md @@ -108,7 +108,7 @@ Manifest: ``` mynx.c - makefile pre-built generic Un*x + makefile pre-built generic Unix README.TXT manual.html makefile.in makefile template diff --git a/2006/guidelines.txt b/2006/guidelines.txt index 413d05727..cf1ae9e48 100644 --- a/2006/guidelines.txt +++ b/2006/guidelines.txt @@ -201,7 +201,7 @@ OUR LIKES AND DISLIKES: if you show some amount of restraint. You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your @@ -275,15 +275,15 @@ OUR LIKES AND DISLIKES: .Xdefaults. If you must do so, be sure to note the required lines in the program "remarks". - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest, so avoid stuff like POSIX real time, security, etc. @@ -312,7 +312,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/2011/guidelines.txt b/2011/guidelines.txt index 7468260a5..152b0f6b0 100644 --- a/2011/guidelines.txt +++ b/2011/guidelines.txt @@ -217,7 +217,7 @@ OUR LIKES AND DISLIKES: if you show some amount of restraint. You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your @@ -291,15 +291,15 @@ OUR LIKES AND DISLIKES: .Xdefaults. If you must do so, be sure to note the required lines in the program "remarks". - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest, so avoid stuff like POSIX real time, security, etc. @@ -331,7 +331,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/2012/guidelines.txt b/2012/guidelines.txt index 333181beb..8449972c1 100644 --- a/2012/guidelines.txt +++ b/2012/guidelines.txt @@ -248,7 +248,7 @@ OUR LIKES AND DISLIKES: | bytes of -D's in order to try and squeeze the source under the size limit. You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your @@ -341,15 +341,15 @@ OUR LIKES AND DISLIKES: | Happy Birthday song some people believe is copyrighted even if such | copyrights appear to be bogus and blatant abuses of the copyright system. - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will | evolve but not as much as the contest. You might not be prohibited from failing to not partly misunderstand @@ -384,7 +384,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/2013/guidelines.txt b/2013/guidelines.txt index c2eb6d6ee..177ed2c27 100644 --- a/2013/guidelines.txt +++ b/2013/guidelines.txt @@ -298,7 +298,7 @@ OUR LIKES AND DISLIKES: bytes of -D's in order to try and squeeze the source under the size limit. You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your @@ -401,15 +401,15 @@ OUR LIKES AND DISLIKES: | (even if such copyrights appear to be bogus and/or blatant abuses of | the copyright system). - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest. | You very well might not be prohibited from failing to not partly @@ -444,7 +444,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/2014/guidelines.txt b/2014/guidelines.txt index d3026c26a..35cbc01b9 100644 --- a/2014/guidelines.txt +++ b/2014/guidelines.txt @@ -301,7 +301,7 @@ OUR LIKES AND DISLIKES: | varation as it is possible to have on Earth. :-) You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your @@ -409,15 +409,15 @@ OUR LIKES AND DISLIKES: (even if such copyrights appear to be bogus and/or blatant abuses of the copyright system). - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest. | You very well might not be completely prohibited from failing to not @@ -453,7 +453,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/2015/guidelines.txt b/2015/guidelines.txt index 82feb05e2..415de7008 100644 --- a/2015/guidelines.txt +++ b/2015/guidelines.txt @@ -345,7 +345,7 @@ OUR LIKES AND DISLIKES: | variation as it is possible to have on Earth. :-) You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your @@ -459,15 +459,15 @@ OUR LIKES AND DISLIKES: (even if such copyrights appear to be bogus and/or blatant abuses of the copyright system). - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest. You very well might not be completely prohibited from failing to not @@ -504,7 +504,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/2018/guidelines.txt b/2018/guidelines.txt index fa0486fe9..15d1982d5 100644 --- a/2018/guidelines.txt +++ b/2018/guidelines.txt @@ -383,14 +383,14 @@ OUR LIKES AND DISLIKES: variation as it is possible to have on Earth. :-) You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your program is reasonably portable. -| We prefer programs that are portable across a wide variety of Un*x-like -| operating systems (i.e., Linux, BSD, Un*x, etc.). +| We prefer programs that are portable across a wide variety of Unix-like +| operating systems (i.e., Linux, BSD, Unix, etc.). You are in a maze of twisty guidelines, all different. @@ -500,15 +500,15 @@ OUR LIKES AND DISLIKES: (even if such copyrights appear to be bogus and/or blatant abuses of the copyright system). - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest. You very well might not be completely prohibited from failing to not @@ -545,7 +545,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/2019/diels-grabsch1/guidelines.txt b/2019/diels-grabsch1/guidelines.txt index d4166f5d8..f0005ca3d 100644 --- a/2019/diels-grabsch1/guidelines.txt +++ b/2019/diels-grabsch1/guidelines.txt @@ -385,14 +385,14 @@ OUR LIKES AND DISLIKES: variation as it is possible to have on Earth. :-) You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your program is reasonably portable. - We prefer programs that are portable across a wide variety of Un*x-like -| operating systems (i.e., Linux, GNU Hurd, BSD, Un*x, etc.). + We prefer programs that are portable across a wide variety of Unix-like +| operating systems (i.e., Linux, GNU Hurd, BSD, Unix, etc.). You are in a maze of twisty guidelines, all different. @@ -503,15 +503,15 @@ OUR LIKES AND DISLIKES: (even if such copyrights appear to be bogus and/or blatant abuses of the copyright system). - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest. You very well might not be completely prohibited from failing to not @@ -553,7 +553,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/2019/guidelines.txt b/2019/guidelines.txt index c69005577..caa19af19 100644 --- a/2019/guidelines.txt +++ b/2019/guidelines.txt @@ -385,14 +385,14 @@ OUR LIKES AND DISLIKES: variation as it is possible to have on Earth. :-) You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your program is reasonably portable. - We prefer programs that are portable across a wide variety of Un*x-like -| operating systems (i.e., Linux, GNU Hurd, BSD, Un*x, etc.). + We prefer programs that are portable across a wide variety of Unix-like +| operating systems (i.e., Linux, GNU Hurd, BSD, Unix, etc.). You are in a maze of twisty guidelines, all different. @@ -503,15 +503,15 @@ OUR LIKES AND DISLIKES: (even if such copyrights appear to be bogus and/or blatant abuses of the copyright system). - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest. You very well might not be completely prohibited from failing to not @@ -553,7 +553,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/2020/guidelines.txt b/2020/guidelines.txt index 5e179808f..44671ed29 100644 --- a/2020/guidelines.txt +++ b/2020/guidelines.txt @@ -418,14 +418,14 @@ OUR LIKES AND DISLIKES: variation as it is possible to have on Earth. :-) You should try to restrict commands used on the build file to - POSIX-like or common Un*x-like commands. You can also compile + POSIX-like or common Unix-like commands. You can also compile and use your own programs. If you do, try to build and execute from the current directory. This restriction is not a hard and absolute one. The intent is to ensure that the building if your program is reasonably portable. - We prefer programs that are portable across a wide variety of Un*x-like - operating systems (i.e., Linux, GNU Hurd, BSD, Un*x, etc.). + We prefer programs that are portable across a wide variety of Unix-like + operating systems (i.e., Linux, GNU Hurd, BSD, Unix, etc.). You are in a maze of twisty guidelines, all different. @@ -537,15 +537,15 @@ OUR LIKES AND DISLIKES: (even if such copyrights appear to be bogus and/or blatant abuses of the copyright system). - While we recognize that UN*X is not a universal operating system, the + While we recognize that UNIX is not a universal operating system, the contest does have a bias towards such systems. In an effort to expand the scope of the contest, we phrase our bias in terms of POSIX P1003.1 - and P1003.2 standards. This will allow certain non-UN*X OS users to + and P1003.2 standards. This will allow certain non-UNIX OS users to submit entries. On the other hand, this is a guideline and not a rule. We will not reject an entry based on some POSIX technicality. When dealing with OS and application environments, we suggest that you - be reasonable with a nod towards vanilla UN*X-like systems. POSIX will + be reasonable with a nod towards vanilla UNIX-like systems. POSIX will evolve but not as much as the contest. You very well might not be completely prohibited from failing to not @@ -587,7 +587,7 @@ OUR LIKES AND DISLIKES: while to write remarkable program "remarks". We dislike C code with trailing control-M's (\r or \015) that results - in compilation failures. Some non-Un*x/non-Linux tools such as + in compilation failures. Some non-Unix/non-Linux tools such as MS Visual C and MS Visual C++ leave trailing control-M's on lines. Users of such tools should strip off such control-M's before submitting their entries. In some cases tools have a "Save As" option that will diff --git a/all/summary.txt b/all/summary.txt index 36fbbd275..23062667e 100644 --- a/all/summary.txt +++ b/all/summary.txt @@ -25,7 +25,7 @@ 1987 biggar program: "P;" defined on command line 1987 heckbert obfuscated fold program 1987 hines counts goto's, all ids anagrams of 'goto', all flow w goto -1987 korn one-liner that prints a message on a Un*x system +1987 korn one-liner that prints a message on a Unix system 1987 lievaart very good othello player 1987 wall roman numeral -> decimal and vice versa conversion 1987 westley individually palindromic lines prints a palindrome diff --git a/years.html b/years.html index 3f7140054..350456032 100644 --- a/years.html +++ b/years.html @@ -3312,7 +3312,7 @@ Contest
  • hines.alt.c -

    korn - one-liner that prints a message on a Un*x system

    +

    korn - one-liner that prints a message on a Unix system