# Shortest code in your language to persist a string across a reboot

You'll write two programs (both in the same language). The storage program takes a string from STDIN and stores it somewhere persistent (see below) and then exits without error. The retrieval program takes no input, retrieves the string that was stored, and prints it to STDOUT.

### Objective test of Persistence:

You should be able to run the storage program on your local machine, then power-cycle your local machine, then call the retrieval program on your local machine. You can stash the string however you want (even on the web) as long as you pass this reboot test.

### Test Cases:

Storage then retrieval:

echo foo | Store
Retrieve
foo


Repeated Stores should overwrite (like a set() method):

echo foo | Store
echo bar | Store
Retrieve
bar


Repeated Retrieval is non-destructive (like a get() method):

echo foo | Store
Retrieve
foo
Retrieve
foo


Retrieval before any invocation of Storage:

You don't need to worry about this. Your retrieval program can assume that the storage program has been run at some point in the past.

### Input/Output flexibility.

People have asked me to expand this from strict STDIN/STDOUT to the standard IO rules. I can't because it would introduce too many loopholes. Some standard IO options already have the input stored in a persistent way, eg "programs may take input from a file". I'd like to be more flexible than just strict STDIN and STDOUT, but without opening the floodgates.

From the standard IO rules thread I'm cherry-picking the ones that don't break the challenge:

If you use an alternate it must be user-interactive. The user shouldn't have to do any other work besides piping their input to your program, typing it into a prompt your program provides, or typing input as a command-line-arg of your program. The user shouldn't have to do anything other than running your retrieve program to see the output displayed on screen or sent to STDOUT or STDERR.

### Allowed assumptions:

• Your two programs will be run in the same directory
• Files you create will survive the reboot (not in a temp dir)
• One trailing newline that wasn't part of the string is allowed. No other trailing whitespace

• so just echo $@>x and cat x is valid? – Adám Jul 5 '18 at 23:30 • Your spec doesn't mention the ability to store multiple times, but you do have an example case that does so. May we assume a clean environment for each invocation of Store? – Adám Jul 5 '18 at 23:40 • @EriktheOutgolfer Why would it not be valid? Even if there is a loophole discussed on meta that doesn't prevent a challenge from specifically allowing it. – dylnan Jul 5 '18 at 23:45 • Web restrictions are usually about pulling stuff from the web as a loophole to get out of doing the work of creating that stuff. In this case, if it's on the web it's because you did the work of putting it there. – Jared K Jul 6 '18 at 0:18 • Somebody needs to write an answer for a computer with magnetic-core memory. – Mark Jul 6 '18 at 23:30 ## 40 Answers # Sed, 2+2 bytes: Stores to file f: wf  Reads from file f: rf  Try a demo online! # SmileBASIC (v3+), 23 + 14 = 37 bytes Simple filesystem-based answer. Works in all known SmileBASIC environments v3.x or above. Be careful, in case you happen to have an important text file named A! ## Store, 23 bytes LINPUT S$SAVE"TXT:A",S$ ## Retrieve, 14 bytes ?LOAD("TXT:A")  # SmileBASIC (v2), 21 + 16 = 37 bytes Adjusted to work on old SmileBASIC (Petit Computer/mkII for DSi). ## Store, 21 bytes LINPUT MEM$SAVE"MEM:A


## Retrieve, 16 bytes

LOAD"MEM:A
?MEM$ I'm honestly kinda amazed both versions work out to the same total byte count. # Cgam, 7 bytes ### Store, 4 bytes qSow  ### Retrieve, 3 bytes Sog  Unfortunately, there is not yet a web interpreter, all you can do is download the code, build it, and run it yourself... # Powershell | 26 bytes ## Store (store.ps1 | 24 bytes) "$s='$input'">>$profile


## Retrieve (retrieve.ps1 | 2 bytes)

Open#1,"t","w"
?#1s$Close#1  ### Getter Open#1,"t","r" Input#1t$
Close#1
?t\$
`

Try it online!