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.

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