From 73fc551f70794a392e2615968c8015a5d7857ade Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Wed, 11 Oct 2023 05:14:25 -0700 Subject: [PATCH] sgit -e 's/Un\*x/Unix/g' -e 's/UN\*X/UNIX/g' . This is not only to help with formatting - especially important in markdown files - but it's no longer really necessary to do it. One might not feel the need to do it in non-markdown files but I did it anyway to be consistent. Thus instead of showing Un*x/UN*X it shows Unix/UNIX. A question of whether or not it should all be the same case is another thing entirely but if this is desired at some point it should be easy to do anyway - with some care in case it's in formatted text. A note about the glob: why '.' when there are C files and other file types where it could be dangerous to modify? Because I did a git grep first so I knew that it was safe. --- 1984/rules.txt | 4 ++-- 1987/biggar/README.md | 2 +- 1987/korn/README.md | 2 +- 1987/rules.txt | 4 ++-- 1988/rules.txt | 4 ++-- 1989/rules.txt | 4 ++-- 1990/rules.txt | 4 ++-- 1991/rules.txt | 4 ++-- 1992/guidelines.txt | 6 +++--- 1993/guidelines.txt | 6 +++--- 1993/rince/README.md | 2 +- 1994/guidelines.txt | 6 +++--- 1995/guidelines.txt | 8 ++++---- 1996/guidelines.txt | 8 ++++---- 1998/guidelines.txt | 8 ++++---- 2000/guidelines.txt | 8 ++++---- 2001/guidelines.txt | 12 ++++++------ 2004/guidelines.txt | 10 +++++----- 2005/guidelines.txt | 10 +++++----- 2005/mynx/README.md | 2 +- 2006/guidelines.txt | 10 +++++----- 2011/guidelines.txt | 10 +++++----- 2012/guidelines.txt | 10 +++++----- 2013/guidelines.txt | 10 +++++----- 2014/guidelines.txt | 10 +++++----- 2015/guidelines.txt | 10 +++++----- 2018/guidelines.txt | 14 +++++++------- 2019/diels-grabsch1/guidelines.txt | 14 +++++++------- 2019/guidelines.txt | 14 +++++++------- 2020/guidelines.txt | 14 +++++++------- all/summary.txt | 2 +- years.html | 2 +- 32 files changed, 117 insertions(+), 117 deletions(-) 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