UNIX を厳密に X/Open の認定をうけたものとして考えると Linux は UNIX ではない。FreeBSD も NetBSD も同じ。ただし、ソースがあるという点では、Solaris, HP-UX, AIX, Degital UNIX なんかよりも UNIX 的である。
Windows95 も UNIX も OS なので、純粋に Windows95 上で UNIX が動く(逆も)というのはない。しかし、エミュレーションなら、Windows95 対応の UNIX エミュレーションソフトがあって、その中で、UNIX ソフトを動かすという構造はありえる。
echo. で空行が出る。それ以外にも、echo: echo\ echo+ なども同様。
(UNIX上にあった read only のファイルを DOS に移したところ，read only 属性が失われていなかった。ファイル属性の情報はファイルの何処に含まれているのか? )
ファイル自身には含まれない。ファイル属性などの情報 (属性、ファイル作成日付など)は、ファイルの管理領域 (UNIX では i-node，DOS では Directory 及び File Allocation Table(FAT)) に書き込まれるものである。UNIX 上にある 555 のファイルを DOS 上にもってきて Read Only の属性が失われなかったのは、たまたまそういうソフト (属性などを制限はあっても反映してくれる) を使ったからにすぎない。
gcc -o test test.c
等とコンパイルして、
test
とやると、UNIX に（少なくとも、Linux にはある）test というコマンドがあるので、それが実行されてしまう。
FTP や Telnet といった対話型プログラムを自動化したい場合は、expect を使うとよい。expect は、スクリプトに従って、他の対話型プログラムに "話しかける" プログラムであり、プログラムから何を期待され、正しい応答が何であるべきかをスクリプトで記述することができる。シェルスクリプトとは違って、プログラムとユーザの対話が必要なプログラムを実行するのに便利である。
以下は、とある Anonymous サイトから、ある特定のファイルを受信する例。
#!/usr/bin/expect
set anonymous-ftp.site.hoge
set email mymail-address@mydomain.hoge
spawn ftp $site
expect "*ame*:" { send "anonymous\n" }
expect "assword:" { send "$email\n" }
expect "*> " { send "cd pub/RFC\n" }
expect "*> " { send "ascii\n" }
expect "*> " { send "hash\n" }
expect "*> " { send "get rfc-index.txt\n" }
expect "*> " { send "quit\n" }
send_user "script end\n"
close
exit 0
DOS でも読めるテキストファイルに出力する方法としては、
$ man hogehoge | col -b > hogehoge.txt
ただし、この後改行コードを DOS の形式にする必要がある。
あるいは、
% man hogehoge | perl -pe 's/.\010//g' > hogehoge.txt
また、FreeBSD の man ならば -t オプションを付けると Postscript を吐き出すので、これを lpr に redirect してやれば印刷できる。ポストスクリプトに対応しているプリンタがあれば、
% man -t hogehoge | lpr
できれいに整形されたマニュアルの印刷物ができる。
rdist を使えば可能。
例えば、distfile に次のようなエントリを作り、
backup:
/home/myhome -> localhost
install -oremove,quiet /mo/myhome;
% rdist -f distfile backup
としたり、
rdist -oremove -c /home/myhome localhost:/mo/myhome
とすれば良い。
FMR シリーズ(FMVではない事に注意)は、富士通独自のアーキテクチャのマシンなので、当たり前だが
PC/AT 互換でも PC98 でもない。よって、FreeBSD を動かすには、FMR
専用で動作するものを誰かが書いていれば…
(富士通から 10〜50万円ぐらいで XENIX とが売られていたかもしれない)
ちなみに CPU は 386 の 20MHz で、メモリも一般的な SIMM などは使えず、専用メモリである。現在入手できるのかは不明。
(ld.so: warning: /usr/openwin3/lib/libXmu.so.4.0 has older revision than expected 20 というメッセージが出て、立ち上がらない。)
ld.so: warning とは、シェアードライブラリの問題に対する警告である。
ライブラリには、プログラムをコンパイルする時に組み込むライブラリと、プログラムが実行される時に組み込まれるライブラリというものがある。前者がスタティックライブラリ、後者がシェアードライブラリと呼ばれる。
シェアードライブラリだと、実行する時に組み込まれるため、ディスク上のプログラムサイズを少なくすることが可能である。実行される時に組み込まれるため、スタティックライブラリより、実行されるまで時間が掛かりそうな気がするが、実際はプログラムサイズが小さくなり、メモリーにロードする時間が少なくなるため、この違いが感じられない。
質問でのメッセージは、実行時にシェアードライブラリを組み込もうとしたところ (この処理をするのが、ld.so である) バージョンが古いという警告の出力である。更にそのために解決できなかったシンボル (ライブラリないに該当する部品がない) があって、起動に失敗したようである。
man -k keyword
ネットワーク経由で root としてログインする行為は、セキュリティ上危険であることから、最近の UNIX 系 OS では、デフォルトでは禁止する設定になっているものが多い。
無論 root としての login を telnet 経由で許す設定も可能だが、まずは root 以外の一般ユーザを作り、そのユーザとして (telnet で) login し、その上で必要に応じて su することが推奨される。
参考までに、RedHat Linux 5.2 では /etc/securetty に root でログインできる tty の名前が一覧化される。よって、ここに ttyp0 等を書き加えておけば、telnet による root での login が可能になる。
load とは、ある瞬間におけるそのマシンの負荷 (アクティブなプロセスやスレッドの数) である。load average は、ある期間の負荷の平均値を示している。uptime, w のオンラインマニュアルによると、load average として表示される値は「最後の 1 分、5 分、15 分間の実行待ち行列における平均ジョブ数」ということになる。
要するにある瞬間に動いているジョブのうち入力・ファイルアクセス待ちであったり sleep(2) 等の呼び出し中であったりするジョブを除いた、「実行可能状態」になっているジョブの個数が load であり、それを時間で平均した値が load average になる。
一概には言えないが、load が CPU の数の X 倍になったとすると、マシンの性能が少なくとも 1/X になったようにユーザからは見えるだろう。実際にはプロセスの切り替えに色々な手間がかかるので、1/X より悪い性能に感じると思われる。特に、アクティブなプロセスの使っているメモリ量の合計が、サーバの実メモリ量を越えると、極端に性能が低下する。通常より急に重くなった場合、なにか暴走しているプロセスがあると疑った方がよいかもしれない。
直接 ppid を変えることはできないが、親が先に死ぬと init が引き取って養子にしてくれる。方法としては、(シェル等の) 親から起動されたプロセス(子...自分)が、すぐに fork() で孫プロセスを作って、自分は即自殺 ( _exit()) してしまえばよい。daemon はこうなってるのが多い。
SunOS とかでは /usr/lib/newsyslog が、35 行程度の簡単なシェルスクリプトを cron が定期的に実行して行っている。これを元にカスタマイズして実現すればよいだろう。(Debian なら savelog に、RedHat なら logrotate にそれぞれ該当する)
あるいは、
http://www.iaehv.nl/users/grimaldo/chklogs.shtml
等もある。
リンク処理を直接 ld で行なうと、スタートアップルーチンやランタイムライブラリの libc (標準Cライブラリ) がリンクされない。それがエラーの原因だと考えられる。
ld を直接呼び出す代わりに gcc 等のコンパイラドライバーにリンク処理も任せてしまえばよい。ld はコンパイラドライバが呼び出してくれる。
だいたい MS-DOS と同じものがそのまま使えるだろう。ただ、MS-DOS や UNIX 自体が機構的にその機能を実現しているわけではなく、あとからいくらでも追加できるようなものである。
「MS-DOS のエスケープシーケンス」というのは、正確には「表示機器がサポートする画面制御シーケンス」で、PC-9801 シリーズなら CON デバイス、PC 互換機なら ANSI.SYS がこれを実現している。
UNIX でこれと同じことを実現するのは、端末デバイスドライバー経由で出力先としてつながっている、ハードウエア端末あるいは端末エミュレーターで、RS-232C 回線で接続されている VT-100 端末とか、X Window System のクライアントプログラムである xterm や kterm などがそれにあたる。
PC-9801 の CONデバイスや PC 互換機の ANSI.SYS はいずれも一部の独自機能 (カーソル表示/非表示やキーのリマップなど) を除いて、画面制御シーケンスの規格である ANSI X3.64 の (小さな) サブセットを実現している。一方、xterm や kterm は同じ規格のほとんどフルセットを実現しているし、HP 製の端末エミュレーターを除けば、現在ではほとんどが ANSI 準拠である。
従って、MS-DOS のプログラムで使っていた「エスケープシーケンス」は、UNIX 上のプログラムでもほぼそのまま使えると思われる。