あなたのプログラム:
2つのプログラム(両方とも同じ言語)を作成します。ストレージプログラムはSTDINから文字列を取得し、永続的な場所に保存し(以下を参照)、エラーなしで終了します。検索プログラムは入力を受け取らず、保管されたストリングを検索して、それをSTDOUTに出力します。
永続性の客観的テスト:
ローカルマシンでストレージプログラムを実行し、ローカルマシンの電源を入れ直し、ローカルマシンで検索プログラムを呼び出すことができるはずです。この再起動テストに合格する限り、(Web上でも)必要に応じて文字列を隠しておくことができます。
テストケース:
ストレージと検索:
echo foo | Store
Retrieve
foo
繰り返しストアは上書きする必要があります(set()メソッドのように):
echo foo | Store
echo bar | Store
Retrieve
bar
繰り返し取得は非破壊的です(get()メソッドのように):
echo foo | Store
Retrieve
foo
Retrieve
foo
ストレージを呼び出す前の取得:
これについて心配する必要はありません。検索プログラムは、ストレージプログラムが過去のある時点で実行されたと想定できます。
入力/出力の柔軟性。
人々は、これを厳密なSTDIN / STDOUTから標準のIOルールに拡張するように頼まれました。抜け穴が多すぎるため、できません。一部の標準IOオプションでは、入力が永続的な方法ですでに保存されています。たとえば、「プログラムはファイルから入力を取得できます」。厳密なSTDINとSTDOUTよりも柔軟になりたいが、水門を開かない。
標準のIOルールスレッドから、課題を解決しないものを選択しています。
必要に応じて、プログラムはGUIプロンプトおよびコマンドラインプロンプトを介して入力を取得できます。
プログラムは画面に表示することで出力できます。これにはGUIダイアログが含まれます
プログラムはSTDERRに出力できますが、実際にはエラーをスローすることはできません。
代替を使用する場合、ユーザー対話型である必要があります。ユーザーは、入力をプログラムにパイプする、プログラムが提供するプロンプトに入力する、またはプログラムのコマンドライン引数として入力を入力する以外に、他の作業を行う必要はありません。ユーザーは、検索プログラムを実行して画面に出力を表示したり、STDOUTまたはSTDERRに送信したりする以外に何もする必要はありません。
許可される仮定:
- 2つのプログラムは同じディレクトリで実行されます
- プログラムには、そのディレクトリに対する読み取り/書き込み権限があります
- 作成したファイルは再起動後も存続します(一時ディレクトリにはありません)
- 文字列の一部ではなかった1つの末尾の改行が許可されます。他の末尾の空白はありません
これはコードゴルフであり、スコアは両方のプログラムのバイトの合計です。
Store
か?
echo $@>x
そしてcat x
有効ですか?