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.
This commit is contained in:
Cody Boone Ferguson committed
1 parent
5d02b1f325
commit
73fc551f70
32 files changed
+117
-117
No files matched your search
+2
-2
@@ -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 <flames about the contest will be kindly #ifdef'ed out> /\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
|
||||
|
||||
@@ -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!
|
||||
|
||||
+1
-1
@@ -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.
|
||||
|
||||
+2
-2
@@ -57,7 +57,7 @@ X <assume a standard 8 character tab stop>
|
||||
|
||||
* 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
|
||||
|
||||
+2
-2
@@ -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
|
||||
|
||||
+2
-2
@@ -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
|
||||
|
||||
+2
-2
@@ -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
|
||||
|
||||
+2
-2
@@ -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
|
||||
|
||||
+3
-3
@@ -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.
|
||||
|
||||
+3
-3
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
+3
-3
@@ -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.
|
||||
|
||||
+4
-4
@@ -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
|
||||
|
||||
+4
-4
@@ -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
|
||||
|
||||
+4
-4
@@ -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
|
||||
|
||||
+4
-4
@@ -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
|
||||
|
||||
+6
-6
@@ -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
|
||||
|
||||
+5
-5
@@ -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
|
||||
|
||||
+5
-5
@@ -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
|
||||
|
||||
+1
-1
@@ -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
|
||||
|
||||
+5
-5
@@ -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
|
||||
|
||||
+5
-5
@@ -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
|
||||
|
||||
+5
-5
@@ -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
|
||||
|
||||
+5
-5
@@ -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
|
||||
|
||||
+5
-5
@@ -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
|
||||
|
||||
+5
-5
@@ -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
|
||||
|
||||
+7
-7
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
+7
-7
@@ -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
|
||||
|
||||
+7
-7
@@ -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
|
||||
|
||||
+1
-1
@@ -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
|
||||
|
||||
+1
-1
@@ -3312,7 +3312,7 @@ Contest </I></FONT></CENTER><BR>
|
||||
<LI><A HREF="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1987/hines/hines.alt.c">hines.alt.c</A>
|
||||
</UL>
|
||||
<A NAME="1987_korn"></A>
|
||||
<P><B>korn</B> - one-liner that prints a message on a Un*x system</P>
|
||||
<P><B>korn</B> - one-liner that prints a message on a Unix system</P>
|
||||
|
||||
<UL TYPE=square>
|
||||
<LI><A HREF="https://github.com/ioccc-src/temp-test-ioccc/blob/master/1987/korn/korn.c">korn.c</A>
|
||||
|
||||
Reference in new issue
Block a user