UNIX マシンにもいろいろある．CPU の語長も 16 から 64 ビット，語内のバイトの順番もさまざま，OS もいろいろだ (UNIX は確か OS の名前だったのだが)．これらのマシン間でまとまった量のデータをやりとりするのに使う媒体はやはり磁気テープ，そしてネットワークだろう．いずれにしろ，物理的にビットを送るところから，相手の意図した情報を受理するレベルまで，すべて整ってやっとデータ交換といえる．
磁気テープは，まず書かれたデータが読めなければ始まらないが，受け取ったテープをセットする装置はあるか? JIS や ISO で規格が定まっているのは，リール巻きの1/2インチテープ，コンパクトカセットと同じサイズのデータカセット，1/4インチテープカートリッジ (QIC) などである．これ以外のカートリッジテープには，OS やパッチの供給のために装備されているものの，独自装置のことがある．8mm テープを媒体とするヘリキャルスキャンの装置は標準規格にはなっていないが，供給会社がひとつなので，かえって流通性が高い．ところで，これのブランドは Exabyte という．exa とは giga, tera, peta の次の数詞で 1018 を表わす．ギガのギガ倍であるが，もちろんそんなには記録できない．2.3Gbyte と圧縮記録する 5Gbyte のフォーマットがある†．
フォーマットを合わせることと共に，書かれたときと同じブロッキングファクターを指定することを忘れてはいけない．フォーマットは，装置，ホストのデバイスドライバの両方が対応していれば，正しい special file (/dev/rst1など) を指定すればよい．ブロッキングファクターは tar, dump, dd などのコマンドで指定できるので，テープごとに違うことがありうる．この値は，書き読みの速度，容量に大きく影響するのでよく指定されるが，指定したときは必ずそれを記録し，読む側に伝えること．また，コマンドの標準の値が違うことがあるので，書くときにはできるだけ指定したほうがよい (まれに，指定ができない機種があるので要確認)．また，tar はファイルのパス名の長さに制限がある．ディレクトリ階層を深くすれば簡単に制限を越えるので注意が必要である．また，他に送るファイルのパス名に漢字を使うのは避けるべきだ．
さて，これでやっとテープの内容をファイルとして読むことができた．ファイルのビット列を意味のある情報として利用する準備が整ったといえよう．コードやエンディアン，ネットワークによるデータ転送について次号に述べる．
† 最近は非圧縮 80GByte の容量があるそうだ．これは 8mm テープではない．[2003.7.18]
前号では，磁気テープを使ってホスト間でファイルをやりとりするときの注意を示した．このファイルの内容を意図した情報として扱うのだが，プロセッサの語長やバイトの順番 (エンディアン)，浮動小数点の内部フォーマットが異なるようなホスト間では，なんらかの符号化 / 複号化が必要である．このように情報維持のために符号，複号をすることをマーシャリング (marshaling, 原義は整列化) と呼んでいる．
ひとつの方法は，テキストファイルとしてしまうことだ．ファイルが大きくなったり，浮動小数点数の書き読みで誤差が生じる可能性があるが，一般的でかなり有効である． 得たファイルをすぐにテキストエディタなどで操作できるという副作用もある．ただし，テキストといってもいわゆる ASCII (JIS X0201 7単位符号ローマ文字用図形キャラクタ集合と間隔文字) 以外の漢字符号などが含まれるときは別に注意がいる．漢字コードは，JIS X0208 に従うべきだ．また，○ に1など，JIS にない文字が一部機種にあるが，使ってはいけない．
テキストでなく，バイナリフォーマットを使うのなら，SUN の XDR (eXternal Data Representation, RFC 1014)，OSI の ASN.1 (Abstract Syntax Notation One)，CCITT の X.409, ISO 8825 など，定められている標準フォーマットを使うべきだ．ただ，標準がこんなにあっても，お互いで使えるものでなければ意味がない．
ネットワークで情報を交換するときにも同様である．TCP/IP のファイル転送の FTP (RFC 959) も，ASCII タイプの転送ができることは must だが，IMAGE タイプ (バイナリ) は recommended である．ASCII 転送が FTP のデフォルトであるのもここからきている．バイナリファイルの転送前には bin コマンドを忘れないこと．TCP/IP のネットワーク管理に使われている SNMP (RFC 1157他) では ASN.1を使っている．電子メールも 7ビットデータしか送れないと考えるべきだ．バイナリのデータは uuencode と uudecode を使って送ることがよく行なわれる．
だが，例えばソケットを用いてホスト間を接続したとき，long 型のデータひとつ送るのにも ASN.1 を使うのではおおげさだ．TCP/IP では，ヘッダの情報などはすべてビッグエンディアンのバイト順で送ることが定められている (RFC 1340) ので，ntohl や htonl といったライブラリ関数が用意されていることが多い．それぞれ network to host long と hostto network long の意味で，これを使うだけもずいぶん交換性はよくなる．RPC (Remote Procedure Call) パッケージでは，マーシャリングをスタブ内で行ない，利用者の便をはかっているものもある．
CCITT は 1993年3月1日から名前を ITU-T に変更しました．[2003.7.3]
そのプログラムをインストールした人やシステムの管理者に常に浴びせられる言葉だ．会話は続く．「何か，メッセージは出ましたか．」「あっ，出たような気もしますが，ちょっと憶えてないです．」もともと人が寄ってきたり，電話を掛けてくるのは，相談か頼みごとと決まっている． だから電話を掛けてきて動かないとだけ言っても，情報は何も増えない．バグの報告，コマンド動作の相談には，次のような情報が必要である (すぐ相談がいるようなプログラムを提供したほうのことは，ここではおいておく)．
郵便や電話より，いや会話より，電子メールでコミュニケーションしている人がずいぶんいる．論文投稿など，生活のかかったメールも飛び交っている．しかし，メールはネットワークや計算機の保守管理なしには働かない．多くの人手によって動いていることは心にとめておこう．
届いたメールを読んだりファイルに整理する，メールを書く，といったユーザインタフェースには多くの種類がある．エディタで等で書かれたメールはヘッダを整えて sendmail プログラムに渡される．ヘッダの仕様は RFC 822に定められている．sendmail の主な役割は，送り先アドレスを解釈して，適切なメーラにメールを渡すことである．メーラとは，メール配送の実際の通信を行なうもので，自分のホスト内であれば，/bin/mail，電話を使った uucp で送るなら uux, TCP/IP によるネットワークで直接交信ができるホストでは [IPC] と選ぶ．senmdail プログラムは TCP/IP によるメールの送受信のルーティンを内蔵しているので，これを使うのが，[IPC] メーラである．解釈ルールは，sendmail.cf ファイルに生成規則として記述される．
TCP/IP でのメール配送は RFC 821に記述されている SMTP (Simple Mail Transfer Protocol) に従って行なわれる． TCP 接続を確立したあと，二つのホストがテキストベースのプロトコルに従ってメールを送る．つまり，メールの送信は，基本的に 1対1 通信である．このままだと，メールを送る可能性のあるすべてのホストの IP アドレス等を知らなければ通信できないので，アドレスを階層化し，アドレス名から指定されたメール配送先の IP アドレスを動的に得るため DNS (Domain Name System) が使われている．DNS はメール配送先 (MX と呼ばれる．直接の相手ホストのアドレスでなく，そのホストへのメール配送に責任をもつホストでも構わない) 情報だけでなく，そのホスト自体の IP アドレス等，種々の情報を蓄えた分散データベースである．
sendmail も SMTP も米国産であるので，漢字など ASCII 以外の文字を送受するには不便があった．メールヘッダやボディの ASCII 以外の文字は送られる保証はない．しかし，最近は各国の文字セットを ASCII 文字のサブセットに符号化して送受する仕様がまとまりつつある．MIME (RFC 1341, Multipurpose Internet Mail Extensions) は文字だけでなく，画像や音声もメールで送るための符号化をめざしている． これを使ってメールヘッダに漢字を埋め込んだメールもずいぶん見かけるようになった．
このころは，sendmail くらいしかありませんでした．MTA, MUA という言葉もあまり聞かなかった．[2003.5.24]
いまや，ネットワークから離れているマシンは想像しがたい．ネットは電子メール，ファイル転送といった古典的な応用から，世界中の先端最新情報のビジュアルなアクセスまで，利用範囲は拡大する一方である．だが，マシンは能動的でかつネットは双方向であるから，マシンをネットに接続するにあたっては正しく設定をして，ネット上の既存のマシン (場合によっては，世界中のマシンが対象である) に悪い影響を与えないこと，他からみだりに侵入されるような穴を作らないことが重要となる．
以下，注意項目を上げる．
ネットワークは必須であるが，それなりに管理の手間もかかる．NFS を使うなら，マシン同士の時計合わせも重要である．最低限，他に迷惑を掛けないだけの設定はしよう．
UNIX の通常ファイルの種類は，バイトの列，という 1 種類だけである．レコードファイルやキー付きファイルといった形式のファイルはユーザレベルプログラムで実現することはあるが，UNIX カーネルのサービスではない．また，ファイル自体には，ファイルの属性を示すものは含まれない． ファイルの許可モードなどはファイルシステムが別に保持している．だから，C プログラムをコンパイルしてできた a.out ファイルを Emacs で編集するようなことをしても，システムに影響はない (kanji-mode オンの NEmacs ではやらないほうがよい)．
このようにカーネルはファイルの構造には立ち入らないが，ただ，exec 関連のシステムコールでは，さすがにファイルの構造を規定している．実行にあたっての仮想記憶機構の使い方，プログラムコードの大きさ，実行時に用意すべき記憶空間の大きさなどはファイルの先頭にシステムによって決められたバイト数 (例えば 32 バイト) だけ，おさめられている．特に最初の 4バイト (初期のころは 2バイト) にはマジックナンバーが含まれている．これはカーネルソースにハードコーディングされている数値である．そのシステムで使っているマジックナンバーはインクルードファイル sys/exec.h に記述されているだろう．man a.out もこれに関連した情報が得られる．最近はマジックナンバー部分に CPU タイプもいれてあるものが多い．そして，ファイルの先頭の #! はこのマジックナンバー部分にあたるものである．この # と ! もカーネルにハードコーディングされていて，#! に続くパス名をインタプリタのファイル名として，これを改めて実行し，元のファイル名を引数として渡す．#! のないファイルも実行可能の許可ビットを立てれば，その内容を順に実行するファイルになるが，この場合は，はじめにコマンドを受取るシェルが自分で解釈し (必要ならプロセスを生成して) 実行するのに対し，#! はカーネルレベルで指定したプログラムを実行するところが異なる．
このように #! はカーネルがファイルの内容のテキスト解釈まで行なっている．便利なものであるが，set user id ビットを付けた #! による実行ファイルは，重大なセキュリティーホールとなる可能性があるので，set user id はすべきでない．
# はシェルスクリプトでコメントの開始を意味する．#! はシェルにすれば単なるコメントだ．[2003.7.23]