# The recode configurator documentation (and a fun way to explore my 2020 IOCCC Enigma simulator) N.B. At the end of this file I have given a fun exercise that can be used to explore my Enigma simulator. It's especially worth doing if you you like good chocolate and could use a delicious [Double-layered Chocolate Fudge Cake][]. Alternatively if you just want the recipe you could look at my Snake entry 'Don't tread on me award' since it's also there and not enciphered. - [What is recode and why is it recommended?](#recode) - [Options](#options) * [Protecting against the same I/O file](#samefile) * [File options parser limitation](#fileoptions) * [-R option validation?](#validation) - [Piping commands to recode](#pipingtorecode) - [Piping recode to the Enigma simulator](#pipingtoenigma) - [Manually test the recode program with the Enigma program](#manuallytest) - [Only write config file](#onlyconfig) - [Reusing a configuration](#reuseconfig) - [Write config file, read data file and pass to Enigma simulator](#passtoenigma) - [Piping directly to the Enigma code once (with randomised settings, saved)](#directlytoenigma) - [Usage conclusion](#conclusion) - [Example additions](#additions) - [Example uses](#exampleuses) - [Delicious Enigma: Double-layered Chocolate Fudge Cake](#cake) # What is recode and why is it recommended? To demonstrate how to and why you should use the recode program with the Enigma simulator I have included some examples here as well as brief ('brief?!' I am sure many would think but it's brief for me) commentary. It would not be possible to do all that the recode program does in my entry itself but I wanted to demonstrate the features of my entry and this seemed the best way to do that. It also enhances the use of the simulator to make it reusable etc. The recode name idea is that it recodes the input (validating first) to be input for the simulator itself. It can pseudo-randomly select all the settings, it can write the settings to a file, read from input file (e.g. for the text to encipher if piped to the simulator) etc. Basically it's a configurator for the Enigma simulator that makes it easier to use the simulator as well as to reuse the configuration to decipher messages that have been enciphered by those settings. But it also tries to make it look more like the real thing in that it shows the actual rotors (labelling them with the Roman numeral), the reflectors (labelling them with B, C and showing the actual strings) etc. In this file I will show an example of each feature and then get to the wonderful 'challenge' for everyone. # Options usage: ./recode [options] -v display selected settings -r pseudo-randomly select settings -f read file for Enigma input -R init settings from settings string or file -o write settings to file `-r` randomises settings. It won't prompt you for settings but it will for input if you don't give the option to read in a file for input. `-v` shows selected settings. For example combining `-r` and `-v`: $ echo IOCCC | ./recode -r -v Ring 1: ( I) EKMFLGDQVZNTOWYHXUSPAIBRCJ Ring 2: ( V) VZBRGITYUPSDNHLXAWMJQOFECK Ring 3: ( IV) ESOVPZJAYQUIRHXLNFTGKDCMWB Ring settings: WAR Ring positions: XKE Reflector: (B) YRUHQSLDPXNGOKMIEBFZCWVJAT Plugboard pair #01: XE Plugboard pair #02: HJ Plugboard pair #03: SA Plugboard pair #04: PY Plugboard pair #05: CI Plugboard pair #06: ZB Plugboard pair #07: WD Plugboard pair #08: QN Plugboard pair #09: RU Plugboard pair #10: VG 1WX5AK4RE1XEHJSAPYCIZBWDQNRUVGIOCCC Though you won't find such strings in recode.c or prog.c. (You will find the Roman numerals for the rotors and the 'A' and 'B' for the reflectors in recode.c though). Yes the 'WAR' for the Ringstellung (Ring settings) is an amusing coincidence *but it really did happen!* As for `-f` the contents would be output with the settings e.g. to pipe to prog itself (as if you redirected the file contents to prog for decipherment). If the file cannot be opened it sets back to stdin. `-o` outputs the settings to the file. If the file cannot be opened for writing or is the same file name (see below) then only stdout will be used. Example of randomised output going to a file: $ ./recode -r -oconfig IOCCC 3PP4UB5GG1ELGTKFCOPVBNUYXJAWSDIOCCC $ cat config 3PP4UB5GG1ELGTKFCOPVBNUYXJAWSD$ Notice that a terminating newline isn't added. Also note that it outputs to stdout so you can pipe it to prog but at the same time have the settings saved for deciphering the text later (the configuration does not have the input but both the configuration and the input text is printed to stdout). If you want to initialise the settings from previously saved settings (as a string or an input file that has the same format) use the `-R` option. Again note that this does not validate input! Although it detects out of range for the arrays it doesn't detect duplicates. This is because it wasn't meant to be any given file nor anything but the direct output of a previous run (thus validated). I'm not even guaranteeing that I got the array tests valid in recode.c -R option! ## Protecting against the same I/O file Because some file systems are case-insensitive I have implemented a case-insensitive strcmp(); if the input file name is the same as the output file name I won't write to it. From a quick test this is important particularly if neither file exist because if both calls to stat() fail then the inodes will be the same (since what else could they be set to but the same initial value?). This might be overprotective but I believe it better to prevent user error where possible. Of course if neither file exists it might be argued that it's not necessary to worry since you can't read from a file that doesn't exist. But then what about if one exists but the other does not? ## File options parser limitation Due to the way the parsing of options is done (no spaces between option char and argument) shell expansion will not work right so for example doing: $ ./recode -R~/config Will not read the file 'config' in the home directory. I show another way to achieve this later. This limitation also applies to the `-f` and `-o` options! ## -R option validation? Again the `-R` option does not validate input. For validation you have to run the program interactively. # Piping commands to recode If stdin is not a tty (`!isatty(0)`) and neither randomised mode nor reading in from a file is specified then you might just see something like: $ echo testing test tests | ./recode 1AB2BB3CC1testing test tests $ echo testing test tests | ./recode | ./prog - 2>/dev/null mfrwxan lzng ofnlu $ echo testing test tests | ./recode | ./prog - 2>/dev/null | ./recode 1AB2BB3CC1mfrwxan lzng ofnlu $ echo testing test tests | ./recode | ./prog - 2>/dev/null | ./recode | ./prog - 2>/dev/null testing test tests In other words just the defaults. This was to simplify the problems with prompting again for input if it's invalid (though as you'll see it does a good job at this anyway). # Piping recode to the Enigma simulator If you're using recode to recode the input so you don't have to type in the input manually (if you randomise or read in from previously saved file no input need be done at all) then make sure to redirect stderr to /dev/null. If you don't you might see something like: $ ./recode -r | ./prog - Ring 1: IOCCC Setting 1: Position 1: Ring 2: Setting 2: Position 2: Ring 3: Setting 3: Position 3: Reflector: Plugboard pair 1: Plugboard pair 2: Plugboard pair 3: Plugboard pair 4: Plugboard pair 5: Plugboard pair 6: Plugboard pair 7: Plugboard pair 8: Plugboard pair 9: Plugboard pair 10: DEVIY What happened is that `Ring 1: ` is printed to stderr but since it's not been redirected to /dev/null it prints this out; at this point however it prompts for input. Why or how it shows the first prompt instead of later on I do not know. Anyway at this point the simulator is already expecting input to en/decipher. That's why after I sent EOF it printed out the remaining strings to stderr. # Manually test the recode program with the Enigma program $ cat input IOCCC $ ./recode -finput Rotors: (1) I: EKMFLGDQVZNTOWYHXUSPAIBRCJ (2) II: AJDKSIRUXBLHWTMCQGZNPYFVOE (3) III: BDFHJLCPRTXVZNYEIWGAKMUSQO (4) IV: ESOVPZJAYQUIRHXLNFTGKDCMWB (5) V: VZBRGITYUPSDNHLXAWMJQOFECK Input rotor 1 (1 - 5): 1 Input rotor 2 (1 - 5): 2 Input rotor 3 (1 - 5): 3 Input setting 1 (A - Z): A Input setting 2 (A - Z): A Input setting 3 (A - Z): A Input position 1 (A - Z): A Input position 2 (A - Z): A Input position 3 (A - Z): A Reflector: (1) (B) YRUHQSLDPXNGOKMIEBFZCWVJAT (2) (C) FVPJIAOYEDRZXWGCTKUQSBNMHL Input reflector (1 - 2): 2 Input plugboard pair 1: AB Input plugboard pair 2: CD Input plugboard pair 3: .. Input plugboard pair 4: EF Input plugboard pair 5: GH Input plugboard pair 6: IJ Input plugboard pair 7: KL Input plugboard pair 8: MN Input plugboard pair 9: OP Input plugboard pair 10: QR 1AA2AA3AA2ABCD..EFGHIJKLMNOPQRIOCCC Notice that I skipped a plugboard pair; this can be done in a number of ways but two dots is one. Notice also that it's in a different order than the simulator: because with the size restrictions on my entry I saved bytes by using the same loop where I could. It just felt more natural to have them grouped together in a configurator for the simulator. $ echo 1AA2AA3AA2ABCD..EFGHIJKLMNOPQRIOCCC | ./prog - 2>/dev/null HQNVO $ echo 1AA2AA3AA2ABCD..EFGHIJKLMNOPQRIOCCC | ./prog - 2>/dev/null | echo 1AA2AA3AA2ABCD..EFGHIJKLMNOPQRHQNVO | ./prog - 2>/dev/null IOCCC As you can see the recode program prompts for the settings and outputs the input for the Enigma program. I then copied/pasted that output to the program and got the result HQNVO. Following this I piped the original output (of recode) to the simulator and then piped that to the echo of the input settings (replacing the IOCCC with the Enigma enciphered output) and then got the result IOCCC: the original input! (This was before I implemented the `-R` option to greatly simplify things.) Of course the last command was redundant in that I didn't need to show the first part again; I could have just done the latter part but I wanted to show the way the pipeline works with settings etc. What happens if the plugboard pairs are the same but in a different order? It's the same output: $ echo 1AA2AA3AA2AB..CDEFGHIJKLMNOPQRIOCCC|./prog - 2>/dev/null HQNVO Also if you flip the order of the letters in the pair e.g. the AB as BA instead: $ echo 1AA2AA3AA2BA..CDEFGHIJKLMNOPQRIOCCC|./prog - 2>/dev/null HQNVO # Only write config file $ ./recode -v -oconfig -finput >/dev/null Rotors: (1) I: EKMFLGDQVZNTOWYHXUSPAIBRCJ (2) II: AJDKSIRUXBLHWTMCQGZNPYFVOE (3) III: BDFHJLCPRTXVZNYEIWGAKMUSQO (4) IV: ESOVPZJAYQUIRHXLNFTGKDCMWB (5) V: VZBRGITYUPSDNHLXAWMJQOFECK Input rotor 1 (1 - 5): 1 Input rotor 2 (1 - 5): 2 Input rotor 3 (1 - 5): 3 Input setting 1 (A - Z): A Input setting 2 (A - Z): C Input setting 3 (A - Z): E Input position 1 (A - Z): B Input position 2 (A - Z): D Input position 3 (A - Z): F Reflector: (1) (B) YRUHQSLDPXNGOKMIEBFZCWVJAT (2) (C) FVPJIAOYEDRZXWGCTKUQSBNMHL Input reflector (1 - 2): 2 Input plugboard pair 1: AB Input plugboard pair 2: CD Input plugboard pair 3: EF Input plugboard pair 4: GHIJ Input plugboard pair 5: IJ Input plugboard pair 6: KL Input plugboard pair 7: MN Input plugboard pair 8: OP Input plugboard pair 9: QR Input plugboard pair 10: ST Ring 1: ( I) EKMFLGDQVZNTOWYHXUSPAIBRCJ Ring 2: ( II) AJDKSIRUXBLHWTMCQGZNPYFVOE Ring 3: (III) BDFHJLCPRTXVZNYEIWGAKMUSQO Ring settings: ACE Ring positions: BDF Reflector: (C) FVPJIAOYEDRZXWGCTKUQSBNMHL Plugboard pair #01: AB Plugboard pair #02: CD Plugboard pair #03: EF Plugboard pair #04: GH Plugboard pair #05: IJ Plugboard pair #06: KL Plugboard pair #07: MN Plugboard pair #08: OP Plugboard pair #09: QR Plugboard pair #10: ST Notice that I redirect stdout to /dev/null so that the config is only written to the file config. But also notice that for plugboard pair 4 I typed in `GHIJ` and it didn't report an error. Neither did it complain about `IJ` in the next pair. This is because it consumes input overflow. It shouldn't be this way for the simulator though because that could cause inconsistent number of characters expected before the text to encipher. $ cat config 1AB2CD3EF2ABCDEFGHIJKLMNOPQRST $ ( cat config ; cat input ) | ./prog - 2>/dev/null LRAVE $ ( cat config ; cat input ) | ./prog - 2>/dev/null | ( cat config ; echo LRAVE ) | ./prog - 2>/dev/null IOCCC What if you don't want to worry about having to specify input but just have the settings written? You can do that too by either sending a newline or else directly type ctrl-d (or whatever you have EOF set to) or give it an empty file. The following are all equivalent in that they will write to a settings file (the first one will print a newline with the echo but that won't matter): $ echo | ./recode -r -osettings $ echo -n | ./recode -r -osettings $ > empty $ ./recode -r -osettings < empty $ cat empty | ./recode -r -osettings $ ./recode -r -osettings ^D (Above ^D was not shown but I typed it.) The way it works: if nothing is read the buffer remains NULL and so I don't print it but still do print the settings file. Actually even if getdelim() fails you're supposed to free the buffer so I set another variable to indicate if it should be printed. # Reusing a configuration $ echo -n|./recode -r -oconfig 4UH5II1RJ1SPIFEJLYGZWRTBHVCAMN$ $ cat input.txt IOCCC 2020 Enigma simulator example text file This is a sentence. This is another sentence. $ ( cat config ; cat input.txt ) | ./prog - 2>/dev/null > output $ cat output AAPRT 2020 Dkemny tpgnjsjai xpovrgl jvgs wxra Fytt ly m xyiilaqh. Ybbp ox dmuzerm oscwgytb. $ ( cat config ; cat output ) | ./prog - 2>/dev/null > io $ diff io input.txt $ Alternatively you can just use the `-R` and `-f` options: $ ./recode -finput.txt -Rconfig | ./prog - 2>/dev/null > output2 $ diff output output2 $ # Write config file, read data file and pass to Enigma simulator $ ./recode -finput.txt -oconfig | ./prog - 2>/dev/null > output Rotors: (1) I: EKMFLGDQVZNTOWYHXUSPAIBRCJ (2) II: AJDKSIRUXBLHWTMCQGZNPYFVOE (3) III: BDFHJLCPRTXVZNYEIWGAKMUSQO (4) IV: ESOVPZJAYQUIRHXLNFTGKDCMWB (5) V: VZBRGITYUPSDNHLXAWMJQOFECK Input rotor 1 (1 - 5): 2 Input rotor 2 (1 - 5): 5 Input rotor 3 (1 - 5): 3 Input setting 1 (A - Z): C Input setting 2 (A - Z): O Input setting 3 (A - Z): D Input position 1 (A - Z): E Input position 2 (A - Z): L Input position 3 (A - Z): O Reflector: (1) (B) YRUHQSLDPXNGOKMIEBFZCWVJAT (2) (C) FVPJIAOYEDRZXWGCTKUQSBNMHL Input reflector (1 - 2): 2 Input plugboard pair 1: TR Input plugboard pair 2: SN Input plugboard pair 3: OG Input plugboard pair 4: ME Input plugboard pair 5: XY Input plugboard pair 6: WZ Input plugboard pair 7: UV Input plugboard pair 8: AB Input plugboard pair 9: CD Input plugboard pair 10: FI $ cat config 2CE5OL3DO2TRSNOGMEXYWZUVABCDFI Besides a famous book that I happen to love (who doesn't? Ah, but what is it Cody?) there's also a reference to code which I also love (just as all participants of the IOCCC do). But what matters is the output: $ cat output DBFAF 2020 Ittejg ltblwriac uqdfqvr dhqh ghhf Jsjy ce v pxdmullo. Sara tj rtaayak uxfhjcti. $ ./recode -Rconfig -foutput | ./prog - 2>/dev/null IOCCC 2020 Enigma simulator example text file This is a sentence. This is another sentence. # Piping directly to the Enigma code once (with randomised settings, saved) This is like the above only randomised: $ ./recode -r -oconfig|./prog - 2>/dev/null IOCCC UGEVP Note that I typed in IOCCC and sent EOF (ctrl-d); the settings were written to the config file (for deciphering later) and then all of it was piped to the Enigma entry resulting in the line below IOCCC. But let's verify it worked out okay: $ cat config 2BM4GJ3HK1LNCBXWRMGKSYIAZUTPVJ Without having to copy/paste intermediate results: $ echo IOCCC | ./recode -Rconfig | ./prog - 2>/dev/null | ./recode -Rconfig | ./prog - 2>/dev/null IOCCC You can also use a string for the `-R` option. I'll use command substitution and actual pasting to demonstrate: $ echo IOCCC | ./recode -R$(cat config) | ./prog - 2>/dev/null | ./recode -R2BM4GJ3HK1LNCBXWRMGKSYIAZUTPVJ | ./prog - 2>/dev/null IOCCC # Usage conclusion That should give you an idea of how to use the recode program. I leave it as an exercise to the reader to implement additional features but here are some ideas of what could be done and how this entry might be used (including that delicious challenge). # Example additions * Add code (to prog.c) that tries to determine possible decipherments based on a given crib (or set of cribs). # Example uses * Take an actual key sheet and message for that day and try and decipher the message (might help if you know German!). I haven't actually done this for reasons I explained in the remarks (including that I cannot easily verify one particular as well as the fact that there were different procedures, different machines etc. - plus my vision is not good enough for the quality of the pictures). * Try making sense of a politician's speeches by putting them into the simulator. It might not make much sense but can it honestly be that much worse ? :) Actually yes it could be (and we don't need the Enigma helping them either) and I can think of a whole host of other things more entertaining including watching dry paint stay dry on a wall but why not poke fun at politicians anyway? * Best idea: try the below experiment! # Delicious Enigma: Double-layered Chocolate Fudge Cake As I was making the above silly list something occurred to me. My other entries this year include a recipe for a wonderful double-layered chocolate fudge cake but why would it not be included in this one too? But then if that's the case why on Earth should it be unscrambled? So this is what I offer: if you take one of the settings below and run the simulator on the file [chocolate-cake.html][] you will have a wonderful chocolate cake recipe (that even my late stepmum who didn't even like chocolate loved - it's a speciality of my mum's and they were the best of friends too). If you're lazy just go and look at my other entry. Then again if you're lazy you're probably not reading this far! :) The settings is one of the below but a couple questions you might ask yourself: 1. Are any invalid input? 2. Is there some other kind of trickery involved here? I can think of the best way to answer these and I think I need not even mention it. Have fun and enjoy! BTW: Depending on where you are in this world and how warm it is the icing can be a bit of an issue - I give some ideas in the file on what can be done for this. At worst though the icing won't come out as good as it usually does. Hints: 1. It's not the middle one. 2. Yes there are some things kind of spelt here. These include things about cake and chocolate. Some things spelt mean nothing whatever and can be considered coincidences. Some were randomised. 3. There is an obscure thing about my entry that can help locate the proper key of the 16 given below! The questions are what is it and is is it worth going this way? (I think the second answer is 'no' but that's me.) 4. The above points might or might not be relevant. What is relevant is one will reveal a wonderful [Double-layered Chocolate Fudge Cake][] recipe: 142CHOCOLATESVCAKESTBJLKMUMVWX 0EZ4PC1CC0PGTAQSOXWNMDRYKFUZEI 3UY0XF4QG1GTJQLARPKHBEMCOFVUIN 0WE1HK4PL0RVSGXFDKENZYTPCMAHUW 2LV0KC1IE0HTFPCLWOJDBQIRVMEAGN 1SS4QX2RY1SRAQGKUYHCBLPFJDVTNZ 3IW1QR0TZ0GQEDWIYJUPMFZBRAONHS 3OP1KN4MO0HPFZCEAKYQIRXGVMOTUW 4OC2CC0AK1CODELUVRSNGKIZBJPTMY 4MU0MS1CA1KELUVRSXTABJNOCDMQFG 0MU4MC2HO1CLATEFBJMONPQRVWXYZD 125CHOCOLATESEXCAKESJADFNOPQRS 0CH3OC1OL1ATEMBJNOCDLSIFWHRVXY 4MU1MS3CA0KECHOLATBJSNPXVUFGZY 4VW0SL1YB0IYJSLBECKTNAXGPUVHRF 0MC4OH2CO1LATEUMBJCDFGHINOPRQS BTW: What's the middle of a list with even numbered items anyway? [chocolate-cake.html]: chocolate-cake.html [Double-layered Chocolate Fudge Cake]: chocolate-cake.html ----------------------------------------------------------------------------------------------------- (c) Copyright 1984-2020, [Leo Broukhis, Simon Cooper, Landon Curt Noll][judges] - All rights reserved This work is licensed under a [Creative Commons Attribution-ShareAlike 3.0 Unported License][cc]. [judges]: http://www.ioccc.org/judges.html [cc]: http://creativecommons.org/licenses/by-sa/3.0/ -----------------------------------------------------------------------------------------------------