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.

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

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