### Your Programs:

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:

* [Programs may take input via GUI prompts](https://codegolf.meta.stackexchange.com/a/2459/69304) and command-line prompts if you want
* [Programs may output by displaying it on screen](https://codegolf.meta.stackexchange.com/a/7139/69304) This includes GUI dialogs
* [Programs may take input via command-line arguments](https://codegolf.meta.stackexchange.com/a/2449/69304)
* [Programs may output to STDERR](https://codegolf.meta.stackexchange.com/a/2451/69304) but still can't actually throw errors.

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
* Your programs have read-write permissions for that 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

### This is code-golf, and your score is the sum of bytes from both programs.