Merge pull request #11 from xexyl/updates-post-birthday

Updates post birthday

1992/rules

@@ -142,7 +142,7 @@ into a file named is 'prog.c'.  The resulting file must follow rule #2.
 
        If possible, we request that you hold off on emailing your entries
        until 1-Mar-92 0:00 UTC.  Early entries will be accepted, however.
-       We will attempt to email a confirmation to the the first author for
+       We will attempt to email a confirmation to the first author for
        all entries received after 1-Mar-92 0:00 UTC.
 
     9) Each person may submit up to 8 entries per contest year.  Each entry

1993/guidelines

@@ -408,7 +408,7 @@ end
     With the exception of the header, all text outside of the entry
     format may be ignored.  That is, don't place text outside of the
     entry and expect the judges to see it.  (Our decoding tools aren't
-    AI progs!) If you need tell the the something, put it in the
+    AI progs!) If you need tell the something, put it in the
     ---remark--- section, or send an email to the judges at:
 
 	...!{apple,pyramid,sun,uunet}!hoptoad!judges	(not the address for

1993/rules

@@ -163,7 +163,7 @@ into a file named is 'prog.c'.  The resulting file must follow rule #2.
 
        If possible, we request that you hold off on emailing your entries
        until 1-Mar-93 0:00 UTC.  Early entries will be accepted, however.
-       We will attempt to email a confirmation to the the first author for
+       We will attempt to email a confirmation to the first author for
        all entries received after 1-Mar-93 0:00 UTC.
 
     9) Each person may submit up to 8 entries per contest year.  Each entry

1994/guidelines

@@ -492,7 +492,7 @@ end
     With the exception of the header, all text outside of the entry
     format may be ignored.  That is, don't place text outside of the
     entry and expect the us to see it.  (Our decoding tools are		      |
-    not AI progs!) If you need tell the the something, put it in 	      |
+    not AI progs!) If you need tell the something, put it in 	      |
     the	 ---remark--- section, or send an email to the us at:		      |
 
 	...!{apple,pyramid,sun,uunet}!hoptoad!judges	(not the address for

2000/tomx/README.md

@@ -1,4 +1,4 @@
-Most Complete Program:
+# Most Complete Program:
 
     Thomas P John
     Mishybi Plamoottil
@@ -9,106 +9,109 @@ Most Complete Program:
     http://tomx.tripod.com/
 
 
-Judges' Comments:
+## Judges' Comments:
+### To use:
 
-    To build:
+    make tomx
 
-	make tomx
+### Try:
 
-    Try:
+    rm -f ./tomx
+    sh tomx.c
+    ./tomx
 
-	rm -f ./tomx
+If sh is your shell:
-	sh tomx.c              
-	./tomx
 
-    If sh is your shell:
+    rm -f ./tomx
+    chmod +x ./tomx.c
+    ./tomx.c
+    ./tomx
 
-	rm -f ./tomx
+### Also try:
-	chmod +x ./tomx.c
-	./tomx.c 
-	./tomx
 
-    Also try:
+    rm -f ./tomx
-
+    make -f tomx.c
-	rm -f ./tomx
+    ./tomx
-	make -f tomx.c
-	./tomx
-
-    Polyglots have come and gone, but this was the first one we'd seen
-    where one language *used* another to perform its tasks.  An interesting
-    approach.  Admittedly, it's not all that obfuscated - but there's more
-    to it than you might think, since you have to make sure that your
-    changes don't change the shell code or the makefile.
 
 
-Selected Author's Comments:
+### Selected Judges Remarks
 
-    Summary
+Polyglots have come and gone, but this was the first one we'd seen
-    -------
+where one language *used* another to perform its tasks.  An interesting
-    This program works as a C source file, a Makefile and also as a
+approach.  Admittedly, it's not all that obfuscated - but there's more
-    Shell (/bin/sh) script. But unlike some other multi-language prog-
+to it than you might think, since you have to make sure that your
-    rams, this one is NOT meant to print "Hello, world" in all 3 cases
+changes don't change the shell code or the makefile.
-    (At least in the true sense ;-)). The C, make and shell code build
-    upon each other to create a C program (?) which when executed as a
-    shell script will compile itself through the C compiler using a
-    makefile! - Pretty useful, Eh?.
 
-    Probably, this is the first entry ever to fully satisfy Rule #1
-    ("Your entry must be a complete program") in the strictest sense;-)
 
-    Top 5 reasons (IMHO) why this code is an entry for IOCCC
+### Selected Author's Comments:
-    --------------------------------------------------------
-    1. A glance at the source itself will tell U that most of the
-       Obfuscation is NOT in the C code per se, but in the comments
-       to the C code. (But sadly, I could not find an "International
-       Obfuscated C COMMENT contest". So I HAD to sent this entry
-       here to the IOCCC itself).
 
-    2. Of the 3 languages in the source, the least obfuscated is
+### Summary
-       C (But again, there was NO obfuscated make/shscript contest)
-       (Does this hint for a rule in IOCCC-2001 that the major
-       obfuscation should be in C and not elsewhere???. Mmmmm...)
 
-    3. Extending Argument #2... Obfuscation done in the C code
+This program works as a C source file, a Makefile and also as a
-       (comments?) create obfuscated code for the other 2 languages.
+Shell (/bin/sh) script. But unlike some other multi-language prog-
-       This opens new possibilities to be explored in depth in future
+rams, this one is NOT meant to print "Hello, world" in all 3 cases
-       IOCCCs
+(At least in the true sense ;-)). The C, make and shell code build
+upon each other to create a C program (?) which when executed as a
+shell script will compile itself through the C compiler using a
+makefile! - Pretty useful, Eh?.
 
-    4. LOOKS like a makefile, WORKS like a shell script and COMPILES
+Probably, this is the first entry ever to fully satisfy Rule #1
-       like a C program
+("Your entry must be a complete program") in the strictest sense;-)
 
-    5. Does something useful (See Notes #1, #2)
+### Top 5 reasons (IMHO) why this code is an entry for IOCCC
 
-    Notes
+1. A glance at the source itself will tell you that most of the
-    -----
+   Obfuscation is NOT in the C code per se, but in the comments
-    1. The program could have been something other than the simple
+   to the C code. (But sadly, I could not find an "International
-       "Hello, world" program that it is. It is possible to do
+   Obfuscated C COMMENT contest". So I HAD to send this entry
-       #include "prog2.c" in the place of the main(), leaving the
+   here to the IOCCC itself).
-       complexities of the C file elsewhere and making this source
-       still acceptable to "make" and "sh". The following modif-
-       ication to the last few lines will compile IOCCCs famous
-       "mkentry.c"
 
-        .PHONY: /* true clean */
+2. Of the 3 languages in the source, the least obfuscated is
-        #undef   true
+   C (But again, there was NO obfuscated make/shscript contest)
-      	#include "mkentry.c"
+   (Does this hint for a rule in IOCCC-2001 that the major
+   obfuscation should be in C and not elsewhere???. Mmmmm...).
 
-       Ain't that useful?
+3. Extending Argument #2... Obfuscation done in the C code
+   (comments?) create obfuscated code for the other 2 languages.
+   This opens new possibilities to be explored in depth in future
+   IOCCCs.
 
-    2. By extending this program's idea, It is possible to do some
+4. LOOKS like a Makefile, WORKS like a shell script and COMPILES
-       very interesting things like generating C code on execution
+   like a C program.
-       by adding additional code in  make/sh (open up a loop????).
-       This opens the possibilities of generating & compiling some
-       [obfuscated?] C code.(Maybe should try this if this program
-       fails at IOCCC 2000)
 
-    3. Changing the "%:%.c" dependency to a "$(PROG):$(PROG).c" form
+5. Does something useful (See Notes #1, #2).
-       can compile this program with some other make-s (I got it to
-       work in Windows using nmake and Gnuwin32's sh ;-)
 
-    4. Interesting things to do: try "$ ./tomx.c clean". This will
-       do the same as "make clean" :-)). Also: "$ ./tomx.c all"
 
-    5. Be careful about the Tabs in the source code. Removing them
+### Notes
-       or converting Tabs to spaces can be disasterous
+
+1. The program could have been something other than the simple "Hello, world"
+program that it is. It is possible to do `#include "prog2.c"` in the place of
+the main(), leaving the complexities of the C file elsewhere and making this
+source still acceptable to "make" and "sh". The following modification to the
+last few lines will compile the IOCCC's famous `mkentry.c`.
+
+
+	    .PHONY: /* true clean */ 
+	    #undef   true 
+	    #include "mkentry.c"
+
+
+    Ain't that useful?
+
+2. By extending this program's idea, It is possible to do some
+very interesting things like generating C code on execution
+by adding additional code in  make/sh (open up a loop????).
+This opens the possibilities of generating & compiling some
+[obfuscated?] C code. (Maybe should try this if this program
+fails at IOCCC 2000)
+
+3. Changing the `%:%.c` dependency to a `$(PROG):$(PROG).c` form
+can compile this program with some other `make`s (I got it to
+work in Windows using nmake and Gnuwin32's sh ;-)
+
+4. Interesting things to do: try `./tomx.c clean`. This will
+do the same as `make clean` :-)). Also: `./tomx.c all`
+
+5. Be careful about the Tabs in the source code. Removing them
+or converting Tabs to spaces can be disastrous.
 

2001/guidelines

@@ -784,7 +784,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,      |
     and test our Makefile.  This review process typically takes a few weeks.   |
 									       |
-    Sometime after the initial announcement, and once the the review by	       |
+    Sometime after the initial announcement, and once the review by	       |
     the winners has been completed (perhaps Feb or Mar 2002), the winning      |
     source will be posted to the IOCCC web site:		               |
 									       |

2001/herrmann1/herrmann1.c

@@ -51,7 +51,7 @@ q D H y ## z
 d c 0    & 0
 d R i    W v
 d   B           Initializing...
-d   L    V   /* the turing    */
+d   L    V   /* the Turing    */
 d   M    Y(O)/* state to      */
 d S(x)   T(O,1, start       ##x)
 #else

2001/herrmann1/herrmann1.gcd

@@ -35,7 +35,7 @@
 #define st13_I  I, right, st13
 #define st14_O  O, left , st_next_iteration
 #define st14_I  O, right, st14
-/* The state "st_next_iteration" means the the turing machine
+/* The state "st_next_iteration" means the Turing machine
    is about to do the next iteration of the Euklid algorithm.
    (That is, during that state, there are two numbers on the
    tape with the same gcd as the initial numbers.) */

2004/guidelines

@@ -492,7 +492,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,
     and test our Makefile.  This review process typically takes a few weeks.
 
-    Sometime after the initial announcement, and once the the review
+    Sometime after the initial announcement, and once the review
     by the winners has been completed, the winning source will be
     posted to the IOCCC web site:
 

2005/guidelines.txt

@@ -499,7 +499,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,
     and test our Makefile.  This review process typically takes a few weeks.
 
-    Sometime after the initial announcement, and once the the review
+    Sometime after the initial announcement, and once the review
     by the winners has been completed, the winning source will be
     posted to the IOCCC web site:
 

2006/guidelines.txt

@@ -502,7 +502,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,
     and test our Makefile.  This review process typically takes a few weeks.
 
-    Sometime after the initial announcement, and once the the review
+    Sometime after the initial announcement, and once the review
     by the winners has been completed, the winning source will be
     posted to the IOCCC web site:
 

2011/guidelines.txt

@@ -538,7 +538,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,
     and test our Makefile.  This review process typically takes a few weeks.
 
-    Sometime after the initial announcement, and once the the review
+    Sometime after the initial announcement, and once the review
     by the winners has been completed, the winning source will be
     posted to the IOCCC web site:
 

2012/guidelines.txt

@@ -648,7 +648,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,
     and test our Makefile.  This review process typically takes a few weeks.
 
-    Sometime after the initial announcement, and once the the review
+    Sometime after the initial announcement, and once the review
     by the winners has been completed, the winning source will be
     posted to the IOCCC web site:
 

2013/guidelines.txt

@@ -725,7 +725,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,
     and test our Makefile.  This review process typically takes a few weeks.
 
-    Sometime after the initial announcement, and once the the review
+    Sometime after the initial announcement, and once the review
     by the winners has been completed, the winning source will be
     posted to the IOCCC web site:
 

2014/guidelines.txt

@@ -740,7 +740,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,
     and test our Makefile.  This review process typically takes a few weeks.
 
-    Sometime after the initial announcement, and once the the review
+    Sometime after the initial announcement, and once the review
     by the winners has been completed, the winning source will be
     posted to the IOCCC web site:
 

2015/endoh1/prog.c

@@ -15,7 +15,7 @@ u[1]=y/2    ;w.send(d.slice(0,x<0?0:             2));x=y=-\
 ,lu,lv,    z;void*f;typedef unsigned              long long
 l;l*p,t[  99]={0x67452301,0xEFCDAB89,            0x98BADCFE
 ,308438*  881,3285377520       },i,j,k           ,n,m[204];
-#include        /*io*/          <stdio.h>        /*turing*/
+#include        /*io*/          <stdio.h>        /*Turing*/
 void s(){  ;     for(  k          =0;k++<7 *  2  *9;)for(i=
 0;++i<127; )      e=d +  i* 4   +512*k,1[e]      +=(i-u)*(i
 -u)+(k-v)* (k- v  )<20?*e+=UV_DROP:0;}l*q=  m,   g=1LL<<32;

2015/guidelines.txt

@@ -806,7 +806,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,
     and test our Makefile.  This review process typically takes a few weeks.
 
-    Sometime after the initial announcement, and once the the review
+    Sometime after the initial announcement, and once the review
     by the winners has been completed, the winning source will be
     posted to the IOCCC web site:
 

2018/bellard/README.md

@@ -68,7 +68,7 @@ Wikipedia and were resized to a width of 1024 pixels. Warning: the
 program is not protected against invalid input.
 
 The program should be portable on any Unix system. On Windows the line
-"_setmode(0, 32768); _setmode(1, 32768);" must be added at the start of
+`_setmode(0, 32768); _setmode(1, 32768);` must be added at the start of
 the main() function to avoid unwanted carriage return characters in
 the output.
 

2018/burton2/README.txt

@@ -0,0 +1,71 @@
+tac comes with a small suite of support programs to test and validate against.
+Untar tests and variations in the same dir as the sources,
+or change runtest and unob.sh to look elsewhere for the keyword and test files.
+
+keywords is a critical file, created from ioccc.kw.freq by mkkeywords.
+Only ioccc.kw.freq produces results compatible with iocccsize.c;
+however, any of the variations can be used instead:
+
+	mkkeywords c11 > keywords
+
+unob.sh uses the same input file as mkkeywords to control spaces after keywords.
+The script allows an environment variable, KW, to override this.
+Use it simply:
+
+	unob.sh prog.c | less
+	unob.sh -p prog.c | less
+	KW=c11 unob.sh prog.c | less
+
+To handle obscure command line defines, use the environment variable DEF:
+
+	DEF="-D'g(o)'='goto o;'" KW=c11 unob.sh -p prog.c | less
+
+It does an amazingly good job for such a simple script.
+
+Manifest
+
+prog.c                  the reason for this README
+keywords		the file #included in prog.c, output of mkkeywords
+mkkeywords		reads one of the files from variations, produces string for prog.c
+ioccc.kw.freq		keywords used by iocccsize, sorted by frequency in 201x ioccc winners
+unob.sh			a more robust unobfuscation script; requires variations/c11 in cur dir
+tokenfix		patches up prog -t output for ::, >>>, ...
+src.doc.rot13		the answers, or at least significant help
+tac.c			more clearly written code, offered as a replacement of iocccsize.c
+patch			fixes single quotes in iocccsize.c, adds #ifndef, removes "I"
+fixed_iocccsize.c	iocccsize with patch applied, and nop -c argument added
+
+tests/*
+runtest			script to run the tests; ./runtest | diff results -
+results			results without -k
+results.k		results with -k; opt=kcrs ./runtest | diff results.k -
+test*.c			various test cases looking for compatability
+iocccbug*.c		various test cases demonstrating problems with iocccsize
+spotcheck		script to test a lot of files vs iocccsize
+spotdiff		summarize the results of spotcheck, showing only differences
+discrepancies		text file of the differences found using all the ioccc winning entries
+
+to test prog:
+
+	runtest | diff - results
+	opt=kcrs runtest | diff - results.k
+	find ~/src/obc -type f -a -name "*.c" | xargs spotcheck prog
+		[ | spotdiff | diff -bw - discrepancies ]
+
+to test tac:
+
+	prog=tac runtest | diff - results
+	prog=tac opt=krs runtest | diff - results.k
+	find ~/src/obc -type f -a -name "*.c" | xargs spotcheck tac
+
+variations/*		as described in the remarks, and in each file below
+ansi	
+c++11
+c++14
+c++98
+c11
+c99
+java8
+kandr
+kandr2
+v7unix

2018/ferguson/.gitignore

@@ -1,5 +1,5 @@
+prog
 prog-simple
 prog.orig
 weasel
-weasel-simple
+weasel-simple
-prog

2018/ferguson/README.md

@@ -119,7 +119,7 @@ from the infamous *UNIX-HATERS Handbook*.
 
 **[Winning thoughts](#winning):** What it means to me to win as well as some
 dedications and thanks. Here too I include a link to a website which will be
-dedicated to this entry beyond what will be published on the IOCCC website
+dedicated to this entry beyond what will be published on the IOCCC website.
 
 [FILES]: FILES
 [rpm.md]: rpm.md
@@ -238,8 +238,14 @@ paragraph; the first sentence in fact: the answer to the judges' question and
 the definition. Can you get the program to search the primorial prime of 97
 without passing in specially?
 
-**On user errors:** if the generation reaches **`SIZE_MAX - 1`** I consider it a
+I was quite proud that when the next contest came the judges removed that
-user (or monkey) error; if the user insists on being so petulant as to try such
+question. Later 2018 and all of 2019 was difficult for me so it was like I won a
+second time for the same entry.
+
+### On user errors
+
+If the generation reaches **`SIZE_MAX - 1`** I consider it a
+user (or monkey) error; if the user insists on being so petulant enough as to try such
 a ridiculous set of parameters in an attempt to make it be no more successful
 than a monkey typing *then it shouldn't be any more successful than a monkey; if
 it by chance reaches the target it's because a monkey could too!* Either way
@@ -256,7 +262,7 @@ Fish Theorem*). So although the user might not be a monkey the program makes the
 assumption that **the user could in fact be a monkey called Eric** *although it
 isn't insolent enough to say the user is a monkey for certain!*
 
-[genetic algorithm]: http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html
+[genetic algorithm]: https://web.archive.org/web/20180308131613/http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html
 [2018 guidelines]: http://ioccc.org/2018/guidelines.txt
 
 
@@ -476,32 +482,38 @@ So in this case I joined the options in the following order:
 
 1.  **`-q`**
 
-Quiet output.
+    Quiet output.
+
 
 2.  **`-r101`**
 
-Mutation rate 101 (out of range).
+    Mutation rate 101 (out of range).
+
 
 3.  **`-r5`**
 
-Mutation rate of 5 but note that during parsing I only print invalid mutation
+    Mutation rate of 5 but note that during parsing I only print invalid mutation
 rate (only after parsing do I print the final mutation rate whatever it ends up
 being); so while it appears there is a bug, showing mutation rate out of range
 three times, this is expected (given the next one, **`-r101`**). This means here
 the typewriter was taken from Eric the monkey.
 
+
 4.  **`-r101`**
 
-Mutation rate to 101: this too is out of range (this is the second mutation rate
+    Mutation rate to 101: this too is out of range (this is the second mutation rate
 out of range message). The typewriter returns to Eric.
 
+
 5.  **`-r1`**
 
-Set mutation rate to 1. Take that typewriter away!
+
+    Set mutation rate to 1. Take that typewriter away!
+
 
 6.  **`-r`**
 
-Set mutation rate to 0; when there are no valid characters passed to
+    Set mutation rate to 0; when there are no valid characters passed to
 **`strtol()`** it should return 0: this is the third message about being out of
 range. Note here that **`rand()`** returns an **`int`** and **`strtol()`**
 returns a **`long`** but I compare the return value of **`rand()`** to the
@@ -509,9 +521,10 @@ mutation rate; if there are any systems where the widths differ this *shouldn't
 matter* because of truncation but I do in any case specifically check for **`R <
 0 || R > 100`**. Either way the invalid range returns the typewriter to Eric. 
 
+
 7.  **`test`**
 
-Finally I requested it find the string **`test`** (will search for **`TEST`**).
+    Finally I requested it find the string **`test`** (will search for **`TEST`**).
 
 Given that it was a short string it did find the answer relatively quickly, even
 in monkey mode.

2018/ferguson/rpm.md

@@ -1,22 +1,26 @@
-What? Install an IOCCC entry? I realise it seems odd so why did I make a rpm
+## An RPM: what kind of absolute MADNESS is this ?
-spec file and why did I hint at building RPMs for others? I can't say precisely;
+
-**certainly I'm under no impression that anyone else will want to use it** *but
+What kind of crazy idea is this? Install an IOCCC entry? I realise it seems odd
-the entry was fun enough for me that I actually will* (a number of my programs
+(at best) so why did I make a rpm spec file and why did I hint at building RPMs
-over the years are programs I actually install and I already have done so with
+for others? I can't say precisely; **certainly I'm under no impression that
-this entry). I already have my own RPM repository and initially after having won
+anyone else will want to use it** *but the entry was fun enough for me that I
-I set it up so that I could host the weasel rpm (binary and source) there. At
+actually will* (a number of my programs over the years are programs I actually
-the same time though I feel the entry belongs on the IOCCC website; that is to
+install and I already have done so with this entry).
-say the only place the raw files should be downloadable from is the IOCCC
+
-website itself. Simon Cooper (the judge who deals with setting up the entries on
+I already have my own RPM repository and initially after having won I set it up
-the IOCCC website) asked me if there is any real attachment in having the RPM
+so that I could host the weasel rpm (binary and source) there. At the same time
-built as part of the entry and the answer is 'no'. He did suggest too that if
+though I feel the entry belongs on the IOCCC website; that is to say the only
-I were to have the RPM hosted on the IOCCC website not only would it place a
+place the raw files should be downloadable from is the IOCCC website itself.
-burden on me to keep it up to date but it would place a burden on the judges -
+Simon Cooper (the judge who at the time dealt with setting up the entries on the
-in other words he himself. Even if it wasn't a burden to me I agree on the other
+IOCCC website) asked me if there is any real attachment in having the RPM built
-part and so I have instead come to the following ideas:
+as part of the entry and the answer is 'no'. He did suggest too that if I were
+to have the RPM hosted on the IOCCC website not only would it place a burden on
+me to keep it up to date (not that it ever needed to be updated) but it would
+place a burden on the judges. This is no longer true with GitHub but anyway
+since this was for personal reasons I decided that:
 
 
-*   I will not host the actual source code or scripts on my website; they will
+*   I would not host the actual source code or scripts on my website; they will
 remain on the IOCCC website. This will most likely never change; instead I would
 link to the entry directory so that they remain where they belong: the IOCCC
 website itself. I have set up an [errata page][] however should there be anything
@@ -25,12 +29,14 @@ requiring a fix.
 *   I am keeping the weasel.spec file in the entry as it was part of my
 submission but I do not explain here how to set up the build environment or how
 to build a RPM: if you know how to use **`rpmbuild`** then you should be able to
-work it out.
+work it out. Again that's a crazy idea but again it was there and it was part of
+the judges' comments (which I liked a lot) which is yet another reason I kept
+it.
 
-*   Because I strongly suspect I am the only one who has any desire for actually
+*   Because I strongly suspect (in other words since I know) I am the only one
-installing an IOCCC entry I will not worry about setting up a repository; if I
+who has any desire for actually installing an IOCCC entry I did not do anything
-do set up a repository in the future I will include information on it somewhere
+further. Nevertheless more information on my entry can be found at
-at [https://ioccc.xexyl.net/2018/weasel][].
+[https://ioccc.xexyl.net/2018/weasel][].
 
 [errata page]: https://ioccc.xexyl.net/2018/weasel/errata
 [https://ioccc.xexyl.net/2018/weasel]: https://ioccc.xexyl.net/2018/weasel

2018/ferguson/weasel.1

@@ -1,4 +1,4 @@
-.TH weasel 1 "20 February 2018" "weasel" "IOCCC 2018"
+.TH weasel 1 "15 February 2023" "weasel" "IOCCC 2018"
 .SH NAME
 weasel \- The IOCCC 2018 Implementation of Richard Dawkins's Weasel program
 .SH SYNOPSIS
@@ -187,6 +187,6 @@ find it!
 .PP
 <\fBhttps://en.wikipedia.org/wiki/Weasel_program\fP>
 .PP
-<\fBhttp://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html\fP>
+<\fBhttps://web.archive.org/web/20180308131613/http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html\fP>
 .SH AUTHOR
 Cody Boone Ferguson <\fBweasel@xexyl.net\fP>

2018/ferguson/weasel.man

@@ -1,4 +1,4 @@
-.TH weasel 1 "20 February 2018" "weasel" "IOCCC 2018"
+.TH weasel 1 "15 February 2023" "weasel" "IOCCC 2018"
 .SH NAME
 weasel \- The IOCCC 2018 Implementation of Richard Dawkins's Weasel program
 .SH SYNOPSIS
@@ -187,6 +187,6 @@ find it!
 .PP
 <\fBhttps://en.wikipedia.org/wiki/Weasel_program\fP>
 .PP
-<\fBhttp://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html\fP>
+<\fBhttps://web.archive.org/web/20180308131613/http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/hmw/article1.html\fP>
 .SH AUTHOR
 Cody Boone Ferguson <\fBweasel@xexyl.net\fP>

2018/guidelines.txt

@@ -892,7 +892,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,
     and test our Makefile.  This review process typically takes a few weeks.
 
-    Sometime after the initial announcement, and once the the review
+    Sometime after the initial announcement, and once the review
     by the winners has been completed, the winning source will be
     posted to the IOCCC web site:
 

2019/guidelines.txt

@@ -900,7 +900,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,
     and test our Makefile.  This review process typically takes a few weeks.
 
-    Sometime after the initial announcement, and once the the review
+    Sometime after the initial announcement, and once the review
     by the winners has been completed, the winning source will be
     posted to the IOCCC web site:
 

2020/guidelines.txt

@@ -935,7 +935,7 @@ ANNOUNCEMENT OF WINNERS:
     the winning authors are given a chance to review the judges comments,
     and test our Makefile.  This review process typically takes a few weeks.
 
-    Sometime after the initial announcement, and once the the review
+    Sometime after the initial announcement, and once the review
     by the winners has been completed, the winning source will be
     posted to the IOCCC web site:
 

CONTRIBUTING.md

@@ -5,7 +5,7 @@
 0. Verify that the <A HREF="https://www.ioccc.org/index.html#enter">IOCCC is open</A> for submissions.
 1. If the IOCCC is open, you need to register as a contestant.
 See: <A HREF="https://www.ioccc.org/index.html#enter">how to enter</A> for how to register.
-2. Once you have been registered, you will receive and email message for how to
+2. Once you have been registered, you will receive an email message for how to
 prepare your entries for submission,
 and how to upload the compressed tarballs to our submission portal.
 3. Once the <A HREF="https://www.ioccc.org/index.html#enter">IOCCC</A> closes,
@@ -15,8 +15,8 @@ notify the winners via email using their previously registered email address,
 and upload the winning code to the <A HREF="https://github.com/ioccc-src/winner">ioccc-src/winner</A> repo
 which in turn will cause them to be displayed on the  <A HREF="https://www.ioccc.org/years.html">IOCCC winners page</A>.
 
-## Update your winning entry
+## Updating your winning entries
 
-If you are an IOCCC winner, you may update your entry (meta-data as well as source code)
+If you are an IOCCC winner, you may update your entries (meta-data as well as source code)
 by using a <A HREF="https://github.com/ioccc-src/winner/pulls">GitHub pull request</A>
 against the master branch of the  <A HREF="https://github.com/ioccc-src/winner">ioccc-src/winner</A> repo.

README.md

@@ -1,6 +1,6 @@
 ### This is NOT the official IOCCC web site!
 
-Please visit www.ioccc.org for the official IOCCC web.
+Please visit www.ioccc.org for the official IOCCC web site.
 
 Please do NOT bookmark or link to this [experimental web site](https://ioccc-src.github.io/temp-test-ioccc/).
 

all/summary.txt

@@ -44,7 +44,7 @@
 1989 jar.1	char*_="Hello world.\n";
 1989 jar.2	lisp interpreter, compressed
 1989 ovdluhe	monkey-typer following template, 'APE' identifiers
-1989 paul	print fibonacci base 2 by simulating turing machine
+1989 paul	print Fibonacci base 2 by simulating Turing machine
 1989 robison	apl-expression interpreter (binary), written in C--
 1989 roemer	prints e, script-pi shaped layout, _31415 identifiers
 1989 tromp	squished tetris

bin/sgit

@@ -1,12 +1,12 @@
 #!/usr/bin/env bash
 #
-# sgit - sed -i on all files under git control
+# sgit - run sed (by default with -i) on all files under git control
 #
-# usage: sgit -e 'sed command'... <glob...>
+# This script allows one to run sed under git control without having to come up
-#
+# with a list of files first and then passing those to the command.
-# This script will allow one to update files under git control without having to
+# It allows for multiple sed commands and multiple globs. By default it uses -i
-# come up with a list of files and then passing those to the command. It allows
+# to edit the file in place (without backup extension) but this can be
-# for multiple sed commands (all with in-place editing) and multiple globs.
+# overridden with the -I option. See -h option for all the options.
 #
 # DISCLAIMER AND WARNING: this is something of a hack and might be error prone.
 # It works for what is needed but possibly could be improved. Even so I like it
@@ -20,22 +20,36 @@
 # - Cody Boone Ferguson (@xexyl)
 #
 
-export SGIT_VERSION="0.0.2-1 13-02-2023" # format: major.minor.patch-release DD-MM-YYYY
+export SGIT_VERSION="0.0.5-1 16-02-2023" # format: major.minor.patch-release DD-MM-YYYY
 
-USAGE="usage: $(basename "$0") [-h] [-V] [-v level] [-e command] <glob...>
+USAGE="usage: $(basename "$0") [-h] [-V] [-v level] [-x] [-I] [-o sed_options] [-s sed] [-e command] <glob...>
 
     -h			    print help and exit
     -V			    print version and exit
     -v level		    set verbosity level
-    -e command		    append sed command to execute on globs
+    -x			    turn on tracing (set -x)
+    -I			    disable in place editing
+    -o			    sed options (don't pass '-')
+    -s sed		    set path to sed
+    -e command		    append sed command to to list to execute on globs
 
 sgit version: $SGIT_VERSION"
 
+SED="$(type -P sed)"
+export SED
+export SED_OPTIONS=""
+export I_FLAG=
 export VERBOSITY=0
-export SED_COMMANDS=
+
+# we need an array for sed commands
+declare -a SED_COMMANDS
+
+# we need to remove ' ' from the IFS!
+IFS=$'\t\n'
+
 # parse args
 #
-while getopts :hVv:e: flag; do
+while getopts :hVv:xIo:s:e: flag; do
     case "$flag" in
     h)	echo "$USAGE" 1>&2
 	exit 2
@@ -45,7 +59,15 @@ while getopts :hVv:e: flag; do
 	;;
     v)	VERBOSITY="$OPTARG";
 	;;
-    e)	SED_COMMANDS="$SED_COMMANDS -e $OPTARG"
+    x)	set -x
+	;;
+    I)	I_FLAG="-I"
+	;;
+    o)	SED_OPTIONS="-$OPTARG"
+	;;
+    s)	SED="$OPTARG"
+	;;
+    e)	SED_COMMANDS+=(-e "$OPTARG")
 	;;
     :)	echo "$0: ERROR: option -$OPTARG requires an argument" 1>&2
 	echo 1>&2
@@ -62,13 +84,31 @@ shift $(( OPTIND - 1 ));
 # firewall
 
 # check that SED_COMMANDS is not empty!
-if [[ -z "$SED_COMMANDS" ]]; then
+if [[ -z "${SED_COMMANDS[*]}" ]]; then
     echo "$(basename "$0"): ERROR: you must specify at least one sed command" 1>&2
     echo 1>&2
     echo "$USAGE" 1>&2
     exit 2
 fi
 
+# check that sed is executable
+if [[ -z "$SED" ]]; then
+    echo "$(basename "$0"): ERROR: sed cannot be empty" 1>&2
+    echo 1>&2
+    echo "$USAGE" 1>&2
+    exit 2
+elif [[ ! -f "$SED" ]]; then
+    echo "$(basename "$0"): ERROR: sed is not a regular file: $SED" 1>&2
+    echo 1>&2
+    echo "$USAGE" 1>&2
+    exit 2
+elif [[ ! -x "$SED" ]]; then
+    echo "$(basename "$0"): ERROR: sed is not an executable file: $SED" 1>&2
+    echo 1>&2
+    echo "$USAGE" 1>&2
+    exit 2
+fi
+
 # also check number of remaining args
 if [[ "$#" -eq 0 ]]; then
     echo "$(basename "$0"): ERROR: you must specify at least one glob" 1>&2
@@ -86,22 +126,22 @@ if [[ "$status" -ne 0 ]]; then
 fi
 
 if [[ $VERBOSITY -gt 1 ]]; then
-    echo "debug[2]: sed commands: $SED_COMMANDS" 1>&2
+    echo "debug[2]: sed commands:  ${SED_COMMANDS[*]}" 1>&2
 fi
 
-# This is not the best performance because it does this on all files of the glob
+# This might not the best performance because it does this on all files of the
-# rather than only those files matched by the glob with matching text but it's
+# glob rather than only those files matched by the glob with matching text but
-# better than it used to be (it used to run git ls-files on the repo for each
+# it's better than it used to be (it used to run git ls-files on the repo for
-# sed command so the more you had the slow it would become as it had to get the
+# each sed command so the more you had the slow it would become as it had to get
-# list of files each time!).
+# the list of files each time!).
 #
 # A better approach would be to somehow use git grep to find files that match
 # but this would complicate the command line (at least in anyway I can think of
 # how to do it) so we do it on all files in the repo.
 #
 # But these would possibly require additional args to the command and
-# unnecessarily complicate matters. Anyway it's a hack so it doesn't have to be
+# unnecessarily complicate matters. Anyway it's something of a hack so it
-# perfect (not that there even is such a thing as perfect).
+# doesn't have to be perfect (not that there even is such a thing as perfect).
 #
 if [[ "$VERBOSITY" -gt 1 ]]; then
     echo "debug[2]: looping through all globs" 1>&2
@@ -112,12 +152,34 @@ while [[ "$i" -le "$#" ]]; do
 	echo "debug[2]: found glob: $1" 1>&2
     fi
     if [[ "$VERBOSITY" -ge 1 ]]; then
-	echo "debug[1]: about to run: git ls-files $1 | xargs sed -i '' $SED_COMMANDS" 1>&2
+	if [[ -z "$I_FLAG" ]]; then
+	    if [[ -n "$SED_OPTIONS" ]]; then
+		echo "debug[1]: about to run: git ls-files $1 | xargs $SED -i\"\" $SED_OPTIONS ${SED_COMMANDS[*]}" 1>&2
+	    else
+		echo "debug[1]: about to run: git ls-files $1 | xargs $SED -i\"\" ${SED_COMMANDS[*]}" 1>&2
+	    fi
+	else
+	    if [[ -n "$SED_OPTIONS" ]]; then
+		echo "debug[1]: about to run: git ls-files $1 | xargs $SED $SED_OPTIONS ${SED_COMMANDS[*]}" 1>&2
+	    else
+		echo "debug[1]: about to run: git ls-files $1 | xargs $SED ${SED_COMMANDS[*]}" 1>&2
+	    fi
+	fi
+    fi
+
+    if [[ -z "$I_FLAG" ]]; then
+	if [[ -n "$SED_OPTIONS" ]]; then
+	    git ls-files "$1" | xargs "$SED" -i"" "$SED_OPTIONS" "${SED_COMMANDS[@]}"
+	else
+	    git ls-files "$1" | xargs "$SED" -i"" "${SED_COMMANDS[@]}"
+	fi
+    else
+	if [[ -n "$SED_OPTIONS" ]]; then
+	    git ls-files "$1" | xargs "$SED" "$SED_OPTIONS" "${SED_COMMANDS[@]}"
+	else
+	    git ls-files "$1" | xargs "$SED" "${SED_COMMANDS[@]}"
+	fi
     fi
-    # shellcheck disable=SC2086
-    # SC2086 (info): Double quote to prevent globbing and word splitting. We can't
-    # quote this because we need to have word splitting.
-    git ls-files "$1" | xargs sed -i '' $SED_COMMANDS
     ((i++))
     shift 1
 done