接続のもう一方の端で使用するシリアルコンソールプログラム¹には、リモート側にファイルを送信する何らかの方法があります。どの程度正確に実行するかは、リモートシステムで使用可能なリソースによって異なります。
I持っているlrzszか、kermitリモート側で
最も簡単なケースは、lrzszまたはなどのリモート側に固体バイナリファイル転送プログラムがインストールされている場合kermitです。これはかつて今日よりも一般的でしたが、特定のシステムにはまだこれらのいずれかがある可能性があります。
ローカル側で使用しているシリアルコンソールプログラムには、ZmodemまたはKermitのアップロードを行う方法がほぼ確実にあり、必要なものを直接送信できます。
Zmodemの場合rz、リモートシステムで入力するだけで、ローカルシリアル端末が理解できる特別な文字列が送信され、ファイルピッカーダイアログがポップアップ表示されます。
Kermitはより単純なプロトコルなので、その場合は手動で転送を開始する必要があります。
バイナリファイル転送プログラムはありませんが、持っていますuuencode/base64
lrzszまたはのような適切なバイナリファイル転送プログラムを使用することにはいくつかの利点がありますkermit。効率、チェックサム、自動再試行、転送再開の中止、複数ファイル転送などです。しかし、これらは贅沢です。1つのファイルのみを送信する必要がある場合、またはファイルを送信する頻度が低い場合は、ASCIIアップロードで問題を回避できます。
ターミナルプロトコルは、バイナリデータファイルで発生するバイト値の多くを解釈するため、同じ接続を介してファイルを直接送信することはできません。そうすると、どちらかの側の端末エミュレーションコードがデータの一部を解釈しようとし、データが破損し、端末処理コードも混乱する可能性があります。
これを回避するには、バイナリデータをローカル側でASCIIの安全なサブセットにエンコードし、リモート側でそれを元のバイナリデータに戻します。これはuuencodeとのbase64プログラムが行うことで、マイナーなアルゴリズムの選択のみが異なります。
ローカルシステムで、ファイルをエンコードします：²
$ uuencode -o sbf.uue some-binary-file.gz some-binary-file.gz
次に、リモートシステムで次のコマンドを入力し、ローカルシリアルコンソールの「ASCIIアップロード」機能を使用してファイルを送信します。
$ cat | uudecode
ファイルのアップロードが終了したら、Ctrl-Cを押してから抜け出しcatます。これで、望みどおりにリモートシステムにデコードされたファイルができました。
しかし、送信するファイルがたくさんあり、印刷可能なASCIIトランスコーディングは苦痛です！
より高いレベルの技術にブートストラップすることは難しくありません。リモートシステムにCコンパイラがある場合、以前の手法を使用して、lrzszソースコードのコピーをリモートシステムに送信できます。ローカル側で：
$ uuencode -o lrzsz.tgz.uue lrzsz-0.12.20.tar.gz lrzsz-0.12.20.tar.gz
次に、リモートシステムで、シリアルコンソールプログラムを使用してこれを入力します。
$ cat | uudecode
^C
$ tar xvf lrzsz-0.12.20.tar.gz
...build lrzsz normally
最初のコマンドを開始した後lrzsz.tgz.uue、リモートシステムへのファイルの「ASCIIアップロード」を実行します。パイプラインはuuencodeされたデータを受け入れ、それをバイナリtarballにデコードします。これを解凍してビルドできます。
しかし、リモートシステムにCコンパイラがありません
あなたも、リモート・システム上のコンパイラを持っていない場合は、できるクロスコンパイルrzローカルシステム上（または任意の）プログラムをし、上記の技術を使用してリモートシステムに送信します。
脚注：
minicom、picocom、PuTTY、VanDyke CRT ...
このバージョンに入力ファイル名をuuencode2回指定する必要があります。1回は入力データのソースに名前を付け、再びデータを出力ファイルにデコードするときにリモートシステムがファイルを呼び出す必要があることを宣言します。おそらく、リモートシステムの出力ファイルに別の名前を付けることができます。
のローカルバージョンのuuencode動作が異なる場合があります。