2007/07/31

サーバOS変更と文字コードについて

以前書いたとおり、我が家でファイルサーバ・IMAPサーバとして使っているOSをPlamo Linux 4.2.1からDebian GNU/Linux 4.0に変更しました。


懸念事項として、Plamo Linux 4.2.1からDebian GNU/Linux 4.0の変更に伴い、日本語ファイル名やフォルダ名の文字コードに変更があったことです。
EUC-JPからUTF-8になりました。

2007年7月31日現在においては、保存される日本語ファイル名はPlamo Linux 4.2.1の環境で使用していたEUC-JPとなっています。
その環境で、クライアントで文字化けしないようにするための文字コードの変換作業については下記のとおりとなっています。
多分。

NFSでSambaと同様に文字コードの変換って出来ないのでしょうか?
[linux-users:99504] NFSサーバーでEUCをShift-JISに変換してエクスポートできますか?」を読んだ感じでは出来なさそうですが・・・。
ちょっと調べてみたいです。

また、OSのデフォルトの文字コードが変わることによりどこまで影響が出るのか分かっていないので、こちらもちびちび調べたいと思います。

2007/07/30

KCheckGMailをRPMパッケージ化

KontactのRSSリーダ(Akregator)のようにKDEのシステムトレイに入ってくれるタイプのGMailチェッカーを探したところ、KCheckGmail 0.5.5というのがありました。

KCheckGmail 0.5.7というのもあったのですが、こちらはmake出来ませんでした。
$ make
WARNING: use unsermake instead of make or
use a wrapper script, e.g. makeobj!!!
unsermake all
make: unsermake: コマンドが見つかりませんでした
make: *** [all] エラー 127

unsermakeとやらが無いというエラーのようです。
unsermakeを使わないようなオプションがあればよいのですが、ちょっと分かりませんでした。

また、usermakeを入れるのは大変らしいという情報と、調べた限りではunsermakeの入手先が見つからなかったため、0.5.7は早々にあきらめました。
KDE関連のサイトを重点的に調べてみたのですが、力及ばず見つけることが出来ませんでした。


RPMファイルの作成については、Vine Linuxのドキュメントを参考に自分でSPECファイルを作成することにしました。
随分前にもSPECファイルを作ったことはありましたが、今回以上にテキトーでした。


一番悩んだのがファイルリスト部です。
結局以下のようにファイル名をそのまま列挙しました。
%files
%defattr(-,root,root)
/usr/share/apps/kcheckgmail/eventsrc
/usr/share/apps/kcheckgmail/icons/crystalsvg/32x32/
apps/kcheckgmail.png
/usr/share/apps/kcheckgmail/icons/crystalsvg/128x128/
apps/kcheckgmail.png

〜以下省略〜


実際に配布されているSRPMファイルのSPECを見ると環境変数マクロを多用していますが、今回私は使いませんでした。
よく分からなかったもので。

標準で定義されているマクロは /usr/lib/rpm/macrosに書かれているとのことですが、見てみると結構色々あります。


出来上がったKCheckGMailのスクリーンショットです。
日本語が文字化けしていますが、まあそれほど気にならないです。

メールが届くと音声で案内されます。

あるファイルを含むパッケージを調べる(RPM)

Vine Linux 4.1で、あるファイルを含むパッケージを調べる。
$ rpm -q -f /usr/bin/klaptop_acpi_helper
kdeutils-3.5.7-0vl1.1

2007/07/29

文字コード調査(テキトー)

Debian GNU/Linuxの文字コードがUTF-8のようですので、勉強のためにうちのシステムの文字コードについて調べてみました。

よく分からずにテキトーにやってます。

以下の記述は私のテキトーな調査を基に記述しています。
けっして信じないでください。


日本語名のフォルダを作成してみます。
以下のフォルダ作成は、Vine Linux 4.1のGNOMEターミナルエディタからDebian GNU/Linux 4.0にtelnet接続して行いました。
$ mkdir UTFです      <-- GNOMEターミナルをUTF8に設定し、
フォルダ"UTFです"を作成

$ mkdir EUC鐃叔わ申 <-- GNOMEターミナルをEUC-JPに設定し、
フォルダ"EUCです"を作成
(入力中に文字化けします)

$ ls <-- GNOMEターミナルをEUC-JPに設定
(日本語名のフォルダは全て文字化けしてしまいます)
??能?? Comic_etc EUC?任? Game HONDA KOUSHIEN TV_Cinema
UTF�с™ WallPaper WallPaper2 Web

$ ls <-- GNOMEターミナルをUTF8に設定
(UTF-8の日本語名のフォルダだけ正常に表示されます)
??ǽ?? Comic_etc EUC?Ǥ? Game HONDA KOUSHIEN TV_Cinema
UTFです WallPaper WallPaper2 Web

ここまででフォルダなどを作成したところをVine Linux 4.1のKonquerorで参照したのが下記です。
Vine Linux 4.1の文字コードはEUC-JPです。

日本語のフォルダ名がついているのは下記の3つです。
芸能人・・・Debian GNU/Linux (UTF-8の環境)に変更する以前から作成してあったフォルダ名EUC-JPのフォルダ

UTFです・・・上でGNOMEターミナルをUTF-8に設定した後に作成したフォルダ(化けてます)

EUCです・・・上でGNOMEターミナルをEUC-JPに設定した後に作成したフォルダ

GNOMEターミナルをUTF-8にして入力したフォルダ名はUTF-8で、GNOMEターミナルをEUC-JPにして入力したフォルダ名はEUC-JPで保存されていると思われます。


自分で作ったファイル名/フォルダ名の文字コードを調べるスクリプト(信頼性0)で調べると次のようになりました。
��ǽ�� (Directory)->
EUC-JP <-- 狙い通り!
Comic_etc (Directory)->
ASCII
EUC�Ǥ� (Directory)->
EUC-JP <-- 狙い通り!
Game (Directory)->
ASCII
HONDA (Directory)->
ASCII
KOUSHIEN (Directory)->
ASCII
TV_Cinema (Directory)->
ASCII
UTFです (Directory)->
UTF-8 <-- 狙い通り!
WallPaper (Directory)->
ASCII
WallPaper2 (Directory)->
ASCII
Web (Directory)->
ASCII


一応私の意図通りになっているようです。
(フォルダ名のエンコードもスクリプトの動作も)
繰り返しますが、信頼性0です。

ちなみにスクリプトの中身はこうです。
信頼性0です。
私はシェルスクリプトなんて作ったことろくにありません。
よく分かりません。
(というか、誰か教えて・・・)

中でnkfを--guessオプションをつけて使用しています。
おそらくnkf 2.0.4以降が必要だと思います。
#!/bin/sh

error_flag=1 # Initial valuable (ERROR)

for name in *; do
if [ -L "$name" ];then
# Symbolic link
type="Symbolic link"
error_flag=1
elif [ -d "$name" ]; then
# directory
type="Directory"
error_flag=0 # success
elif [ -f "$name" ]; then
# file
type="File"
error_flag=0 # success
else
# unknown
type="Unknown type"
error_flag=1 # error
fi

if [ $error_flag = 0 ]; then
echo "$name ($type)->"
echo -n " "
echo -n "$name" | nkf -guess
else
echo "$name ($type)"
fi
done

exit 0

2007/07/28

IMAPサーバをDebian上に復活させる

Debian GNU/Linux 4.0をIMAPサーバにします。
uw-imapdを使用します。
# dpkg -l|grep imapd
ii uw-imapd 2002edebian1-13.1 remote mail folder access server


/etc/c-client.cfを準備します。
julie:~# cat /etc/c-client.cf
I accept the risk for IMAP toolkit 4.1.
set new-folder-format mbx
set mail-subdirectory Mail
set disable-plaintext 0


/etc/cram-md5.pwdを準備します。
# cat /etc/cram-md5.pwd
xxx(ユーザ名) yyy(パスワード)
# ls -l /etc/cram-md5.pwd
-rw------- 1 root root 18 Jul 28 04:58 /etc/cram-md5.pwd


/etc/hosts.allowでimapdの接続を許可するホストを指定します。
imapd: xxx.xxx.xxx.xxx/yyy.yyy.yyy.yyy



--
Debianのデフォルトから変更したのはこれくらいだと思います。
一応IMAP利用可能になったみたいです。

UTF-8によるscreen文字化け

家内ネットワークのファイル/IMAPサーバとして使いはじめたDebian GNU/Linux 4.0の日本語環境はデフォルトがUTF-8みたいです。
xxx@julie:~$ echo $LANG
ja_JP.UTF-8

ついにうちにもUTF-8の環境が出来てしまったみたいです。


で、EUC-JPのVine Linux 4.1からtelnetでDebian GNU/Linux 4.0にアクセスした際に文字化けする現象が発生していました。
(後述しますが、私の設定の問題です。)


次のような文字化けの現象が発生していました。

・KDEのKonsole(以下Konsole)の「設定」ー「エンコーディング」をutf8にしても文字化けが解消されない
・GNU Screen(以下screen)を使用していない状態でKDEのKonsoleの「設定」ー「エンコーディング」をutf8に変更すると文字化けしない


screenを使用せずにKonsoleをUTF-8の設定にすれば文字化けしないので、どうやらscreenの設定が悪いようです。
そういえば、.screenrcではろくに設定をしていませんでした。
escape ^L^L
hardstatus alwayslastline "screen |%c %m/%d | %w"

ネットで調べると.screenrcの設定例は色々見つかるのですが、自分の場合は少しずつ設定を追加していこうかと思っています。


screenのマニュアルを調べたところ、次のような対策があるみたいです。
もちろん他にもあるとは思いますが、私が簡単に見つけられた方法の中で手軽だと思ったのが下記の2つでした。
Konsoleのエンコーディングはutf8に変更することが前提です。

(1) "-U"オプションをつけて起動する
screenのマニュアルには次のようにあります。
-U   UTF-8 モードで screen を動作させる。
このオプションは、ユーザの端末が UTF-8 エンコードされた
文字を理解し、また送信してくることをscreenに伝える。
また新規ウィンドウのデフォルトエンコーディングが
`utf8' になる。


(2) screenのコマンドモードでutf8コマンドを使用する
utf8 [on|off [on|off]]
現在のウィンドウが用いるエンコーディングを変更する。
utf8 を on にすると、ウィンドウに送られる文字列は
UTF-8 エンコードされる (逆も同じ)。 パラメータを
省略すると状態をトグルする。二つ目のパラメータを
与えると、ディスプレイのエンコーディングも同時に
変更される (これは screen の "-U"オプションで
指定するほうが良いが)。 "defutf8" も参照のこと。
これは新規に生成されるウィンドウのデフォルトを変更する。


うちの場合、デフォルトはVine Linux 4.1のEUC-JPで使用しているため、必要な時に(2)の方法を用いる(screenのコマンドモードに入り、"utf8 on on"というコマンドを使用してUTF-8に変更する)方がいい気がします。
多分。

Sambaの設定でつまずいた

Debian GNU/Linux 4.0を導入して設定をいじっていますが、Sambaの設定でつまずいてしまいました。

Sambaの設定はいつもどこかでつまずいている気がします。
情けないです。

インストールしてあるSambaのバージョンです。
$ dpkg -l|grep samba
ii samba 3.0.24-6etch4 a LanManager-like file and printer server fo
ii samba-common 3.0.24-6etch4 Samba common files used by
both the server a
ii samba-doc 3.0.24-6etch4 Samba documentation



Sambaパスワードの設定は次のように行いました。
# smbpasswd -a xxx
New SMB password:
Retype new SMB password:
Added user xxx.


(1) SWATにアクセスできない
これは/etc/hosts.denyと/etc/hosts.allowで許可されていないことが原因でした。

/etc/hosts.allowに次の行を追加したところ、動作するようになりました。
swat : xxx.xxx.xxx.xxx/yyy.yyy.yyy.yyy



(2) Samba公開フォルダにアクセスできない

SWATでいくら設定を変更してもクライアントから公開フォルダにアクセスできない現象が発生していました。

syslogを見ると次のようなエラーが出力されてsmbdが起動していませんでした。
Jul 28 09:01:55 localhost smbd[4309]:
[2007/07/28 09:01:55, 0] smbd/server.c:main(960)
Jul 28 09:01:55 localhost smbd[4309]:
ERROR: failed to setup guest info.


smb.confを見ると[global]セクションに次のような行がありました。
  guest account =


SWATで「guest account」の「項目のデフォルト値」を押すと「guest accout」には「nobody」が設定され、この状態でsmbdを再起動したところエラーにはならずにsmbdが起動し、クライアントからSambaの公開フォルダを参照することが出来ました。


現在のsmb.confは次のようになっています。
# Samba config file created using SWAT
# from xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
# Date: 2007/07/28 09:05:53

[global]
dos charset = CP932
# unix charset = UTF-8
unix charset = eucJP-ms
workgroup = XXXXX
server string = Julie Samba [Debian GNU/Linux]
update encrypted = Yes
ldap ssl = no

[share]
comment =
path = /mnt/share
read only = No
hosts allow = xxx.xxx.xxx.0
veto files = /mnt/share/yyyy/

(2007/7/28 追記)
"dos charset = CP932", "unix charset = eucJP-ms" を追加。
"print command =", "lpq command =", "lprm command =" を削除。


日本語表示のため、「dos charset」と「unix charset」を追加しました。
unix charsetをeucJP-msにしたのは、現状ではSamba公開フォルダ内の日本語のフォルダ名はEUC-JPにしてあるからです。
(「日本語文字化けをどうにかする (その4)」参照)

Debian を導入してみた

ファイルサーバ(Samba/NFS)、IMAPサーバに使用しているPlamo LinuxをDebian GNU/Linux 4.0にしてみました。
下図のJULIEです。


理由はセキュリティホール発見時などのアップデートを簡単に済ませたかったからです。

Plamo Linuxを使っているときも一応セキュリティホールが見つかったときは気にしていて、必要であればmakeしてPlamo用のパッケージを作成してインストールしていました。

ところが最近はちょっとその気力が無くなってきて、お手軽にアップデート出来るディストリビューションにかえてみようと思いました。


さすがDebian、パッケージ数がものすごいです。
Debian JPのホームページによると、18,000以上あるそうです。

なかなか面白そうなパッケージもあります。

私はサーバ用途のみのCUIで使う予定なのですが、クライアントの方もVineから浮気しても面白そうです。

2007/07/26

印刷時にPDF出力する

うちではVine Linux 4.1を使用しています。
konquerorは印刷時にデフォルトでPDFに出力することが出来るみたいですが、firefoxは出来ません。

調べたところCUPS-PDFというのがあり、それを入れるとfirefoxでもPDFに出力できることが分かりましたので、入れてみることにしました。

Vine Linux 4.1用のCUPS-PDFは見つからなかったのですが、Vine Seed用にはありました(cups-pdf-2.4.6-0vl2.src.rpm)。

うちでは何の問題もなくリビルドし、インストールすることが出来ました。
$ rpm --rebuild cups-pdf-2.4.6-0vl2.src.rpm
$ su
パスワード(P):
# cd ~xxx(ユーザ名)/rpm/RPMS/i386
# rpm -ivh cups-pdf-2.4.6-0vl2.i386.rpm


今回はVine Linuxのドキュメントにあるようにブラウザからプリンタの設定を行いました。
(第8章 CUPSによる印刷環境の設定方法と使用方法)

(1) CUPSの管理画面を表示します。


(2) プリンタの追加を選びます


(3) プリンタの名前などを入力します
私は深く考えず適当に入力しました。


(4) デバイスを選択します
「CUPS-PDF (Virtual PDF Printer)」を選択しました。


(5)モデル名/ドライバを選択します
「メーカ名」は「Postscript」を選択しました。


「モデル名」は「Generic postscript color printer rev4 (en)」を選択しました。
"color"がついている方がいいだろうという安易な考えからです。


(6)プリンタ設定終了
無事終了したみたいです。



----
早速PDF出力してみました。

保存先などは特に聞かれずに終了してしまい、どこにPDFファイルが出来たのか分からず探してしまいましたが、デスクトップ($HOME/Desktop)に出来ていました。

割り付け印刷する

Windowsから印刷する時は1シートに2ページの割り付け印刷を行うことが多く、同様のことをLinux (Vine Linux 4.1)で実現できないかと考えました。

Windowsの場合は印刷時のプリンタプロパティの設定などで行っていましたがLinuxの場合はどうすればよいのか、少し確認してみました。

以前書いたとおり、うちのLinuxのプリンタ設定はCUPSを使用してLinux用のプリンタドライバが無い場合の設定となっています。
(本当はあります)

後述しますが、最初はfirefoxの印刷設定だけをみてpdftkやpdfjam、konq-pdfをインストールしました。

ところが、下記の(1)を終えた後で気づいたのですが、konquerorの印刷オプションには割り付け印刷の設定があります。
アプリ毎に対応状況が異なっているのでしょうか?


(1) firefoxから印刷する場合
firefoxから印刷する場合のオプションには割り付け印刷に使用するような項目がありませんでした。

たまたま見つけたkonq-pdfの説明にPDF2ページを1シートに割り付けるような設定があります。
そこで、firefoxでの印刷時はPDFに出力し、konq-pdfなどを使用してPDFを割り付け保存してから印刷するようにします。


firefoxで印刷時のPDF出力はこちらに書いた方法を用いました。
印刷時にPDF出力する


konq-pdfのインストールは、まずはkonq-pdfに説明にあるpdftkとpdfjamをインストールし、続けてkonq-pdfをインストールしました。

pdftkはVineのパッケージにあったため、Synapticを使用してインストールしました。
pdfjamはVineのパッケージが見つからなかったため、Fedora JPからpdfjam-1.20-5.fc6.src.rpmをいただいてきてリビルドしました。
$ rpm --rebuild pdfjam-1.20-5.fc6.src.rpm


konq-pdfはthemeファイルをコピーするだけです。
$ tar xzvf konq-pdf-0.1.tar.gz
$ cd konq-pdf-0.1
$ cp *.desktop ~/.kde/share/apps/konqueror/servicemenus/


konq-pdfをインストールする前はkonquerorでPDFファイルを右クリックして「アクション」を選択してもPDF関連のメニューはありませんでしたが、


konq-pdfインストール後には「アクション」ー「Paginate」に割り付けのオプションが追加されました。


早速2ページを1シートに割り付けてみました。



(2) konquerorから印刷する場合
(1)をやってみた後に気づいたのですが、konquerorでWebなどを参照している際には印刷時のオプションに「用紙あたりのページ数」というのがあります。


これを使用してみましたが、割り付けできていました。


(1)と(2)の比較
上記(1)と(2)で印刷した際の比較ですが、まあ大差無い気がします。

使っているのがkonquerorの場合は印刷時にオプションを使った方が手軽なのでは。


----
余談なのですが、ページの境目に画像がある場合に画像が切れてしまういます。
WindowsでIE7やfirefoxを使用している際も同様で、プレビュー見ながら自力で調整していました。

今回の(1)や(2)で例に印刷した際も境目の画像が切れてしまいました。


何かいい方法やツールは無いのでしょうか?

2007/07/25

仮想PC上のWindows 98でゲームをしたい (4)

仮想PC上のWindows 98でゲームをしたい (3)」の続きです。

前回は次のように書きました。
ただ、それでも出ていない音がある気がしますが、今のところ困ってもいないのでちゃんと確認していません。

ちょっと確認してみたところ、ゲーム中で最初出ていたCD音源が途中から出なくなる現象が発生しているようです。

ゲームプレイ中はよくわかりませんでしたが、ゲームCDのCD音源をWindows付属のCDプレイヤーで聴いて確認することが出来ました。

トラックの移動が発生した後に音が出なくなるような気がします。


そこでいくつか設定を変更しながら試してみたのですが、「Virtual Machie Settings」のCD-ROM設定で「Legacy Emulation」のチェックを外すと上記の音が出なくなる問題が発生しなくなる気がします。

仮想PC上のWindows 98でゲームをしたい (3)

仮想PC上のWindows 98でゲームをしたい (2)」の続きです。

○ VMware Serverをインストールしてみた
VirtualBoxはとりあえずあきらめ、ノートPCのVine Linux 4.1でもVMware Serverを使用することにしました。

VMware-server-1.0.3-44356.i386.rpmをダウンロードしてきてインストールしました。

インストールに使用するVMware Serverの各ドライブは次の通りです。
・フロッピードライブ
Windows Me起動ディスクから抜き出したイメージ
・CDドライブ
ホストOSの物理CDドライブとWindows 95インストールディスクのISOイメージの2つ
(理由は後述)


VMware Serverのインストールでは次のような問題がありました。

(1) 使用しているWindows 98インストールディスクがアップグレード版のため途中でWindows 95のインストールディスクを認識させる必要があるが、その際にインストールディスクを入れ換えるとWindows 98インストール作業がフリーズしてしまう。

そこでVMware ServerにはホストOSの物理CDドライブとWindows 95インストールディスクのISOイメージの2つをCDドライブと認識させ、古いOSの確認の際はWindows 95インストールディスクのISOイメージをマウントしている方のドライブを指定させるだけにしました。

その結果インストールを完了させることが出来ました。

「VMware Tools」もインストールし、色数はHigh Color(16bit)、解像度1024x768にすることが出来ました。


(2) サウンド関連のドライバが認識されない
まったく音が出ないという訳では無いのですが、サウンド関連のドライバが認識されていませんでした。

検索してみたところ同じと思われる現象の対策がありました。

createのサイトではWindows98に対応したドライバを見つけることが(英語のサイトなので私には)出来なかったのですが、別のところから「SBPCI128Setupus_w9x.exe」というのを持ってきてインストールしたところ、ドライバを認識させることが出来ました。


ただ、それでも出ていない音がある気がしますが、今のところ困ってもいないのでちゃんと確認していません。


----
一番やりたかった「ルナティックドーン 開かれた前途」を行っている際のスクリーンショットです。


Full Screen表示です。


この位のゲームの方が昨今の3Dゲームより好きです。


----
最後に余談ですが、久しぶりに真っ青になってしまいました。

懐かしいです。



仮想PC上のWindows 98でゲームをしたい (4)」に続く。

仮想PC上のWindows 98でゲームをしたい (2)

仮想PC上のWindows 98でゲームをしたい (1)」の続きです。

○ VirtualBoxをインストールしてみた
VMwareはすでに別のPCで使用しているので、ちょっと面白くありません。

そこでノートPCのVine Linux 4.1では「VirtualBox」を試してみることにしました。

VirtualBox_1.4.0_Linux_x86.runをダウンロードし、インストールしました。
ホストOSはVine Linux 4.1です。

とりあえずWindows98を動かせるところまでは行きましたが、インストールの各段階では次のような問題がありました。
また結局色数が16色にしかできなかったため、VirtualBoxの使用はあきらめました

よくわからずに試行錯誤した結果を以下に書いておきます。
信用しないでください。


(1) インストールCDで起動できない

ログを見ると次のようなエラーが発生しています。
00:00:05.214 Guest Log: BIOS: CDROM boot failure code : 0004
00:00:05.214 Guest Log: BIOS: Boot from CD-ROM failed

これはどうやらWindows 98のインストールディスクがブータブルディスクになっていないことが原因らしいです。

そういえば起動ディスクなんてのが必要でしたね・・・。
すっかり忘れていました。
私ってば迂闊です。

起動ディスクで起動するのは時間がかかって厳しいです。
(インストールに失敗して何度も起動ディスクから起動することになると思う)

そこで起動フロッピーディスクからイメージを抜き出し、それをVirtualBoxでフロッピーディスクとしてマウントして起動することにしました。

フロッピーディスクからイメージの抜き出しには、「SuperウルトラISO 体験版」を使用しました。
これが手っ取り早そうだったからです。

VirtualBox側では次のようにドライブを認識するようにしました。

・フロッピードライブ
Windows Me起動ディスクから抜き出したイメージ
・CDドライブ
Windows 98インストールディスク、またはWindows 98インストールディスクと同一内容のisoイメージ

ところが上手く行きませんでした。
起動ディスクからの起動中のCDドライブを認識する過程で止まってしまいます。

そこで、起動ディスクのイメージを含んだインストールディスクのisoイメージを作成し、これをCDドライブとしてマウントしたところ、インストールを開始することが出来ました

作成は次のようなコマンドで行いました。
mkisofs -v -r -T -J -V "Win98"
-b winme_boot.img(起動ディスクのイメージ)
-o win98_me.img(作成するISOイメージの名前)
win98_cd(Windows 98インストールディスクの中身)


起動ディスクのイメージを含むインストールディスクでは、インストールの過程で再起動するたびに起動ディスクの方が立ち上がってしまいます。

そこで、最初の再起動後はWindows 98インストールディスクと同一内容のisoイメージをCDドライブとして認識させるようにしました。
使用したISOイメージは2つということになります。


(2) Windows98インストール最中のリセット後に起動しなくなる(画面がブラックアウト、CPUはフル稼働しているみたい)ことがある

これはこの状態になっている時に、Safeモードで起動しconfig.sysからEMM386.EXEの行を削除したところ立ち上がるようになりました。


----
また、上記以外にも、VirtualBoxを使用するユーザをvboxusersグループに加えるという作業を行いました。

これは/dev/vobxdrvのパーミッションが660になっていたため、VirtualBoxを使用するユーザを/dev/voxdrvの所有グループであるvboxusersに追加させることが作法なのでは無いかと考えたからです。
(/dev/vobxdrvをパーミッション666にするというのは気が進まない)

そうしないと、どこかのタイミングでpermissionが何とかと言って怒られました。
(どこだか忘れてしまい、メモもちゃんと取っていませんでした・・・。)

# ls -l /dev/vboxdrv
crw-rw---- 1 root vboxusers 10, 62 7月23日 18:11 /dev/vboxdrv
# usermod -G vboxusers xxx(ユーザ名)
# id xxx(ユーザ名)
uid=500(xxx) gid=501(yyy) 所属グループ=501(yyy),502(vboxusers)



----
「Guest Additions」もインストールしましたが、VirtualBoxではWindows 98を16色にしか出来ず、最終的にVirtualBoxの使用はあきらめることにしました。


VirtualBoxサイトのトップページにもちゃんと書いてありますしね。
それは分かっていたのですけど、試してみたかったのです。
Presently, VirtualBox runs on Windows, Linux and Macintosh hosts and supports a large number of guest operating systems including but not limited to Windows (NT 4.0, 2000, XP, Server 2003, Vista), DOS/Windows 3.x, Linux (2.4 and 2.6), and OpenBSD.



仮想PC上のWindows 98でゲームをしたい (3)」に続く。

2007/07/24

仮想PC上のWindows 98でゲームをしたい (1)

仮想化環境が充実して来ているという情報をちらほら目にします。

ノートPCのVine Linux 4.1で何らかのPCエミュレータを動かし、その上で昔のPCゲームでも動かして遊べないかと私も考えました。

ゲストOSはWindows98にします。

気にしたいのは、
・画面の色数や解像度に満足できるか?
・サウンドは出るのか?
・ホストとゲスト間のファイル共有は?
・古いOSなので、インターネットには繋げたくない
といったくらいでしょうか。


結論としては、VirtualBoxも検討しましたがVMware Serverを使用することにしました。

VirtualBoxではWindows 98のgraphic card driverがWindowsデフォルトの物しか使えず16色にしか出来なかったことが原因です。
私が設定の仕方を知らないだけのような気もしますが、「VirtualBox」のトップページの対象ゲストOSには入っていませんし、ネットで調べてもVirtualBoxがWindows 98に対応していないからだという記述がみつかりました。

また、インストールに使ったインストールディスクなどの環境が異なるため単純には比較できませんが、ゲストOS(Windows 98)のインストールもVMware Serverの方が格段に速かったと思います。


仮想PC上のWindows 98でゲームをしたい (2)」に続く。

2007/07/23

Zaurusファイルマネージャ

Zaurusのファイルマネージャの「Tree!Explorer QT Plus+」というのがあります。
シェアウェアで1,250円です。
これを購入してしまいした。


私は以前書いたとおりZaurusをクライアントとしてSambaサーバのフォルダをマウントしています

Zaurus標準のファイルマネージャはシステム中のかなり限定された部分しか閲覧できませんので、Zaurus標準のファイルマネージャでSambaファイルシステムを参照するために/mnt以下にマウントポイントを作成し、/hdd3/Document以下にマウントポイントのリンクを作っていました。

しかし、そうすると何らかのタイミングでZaurusが勝手にSambaファイルシステム中のファイル(全体?)にアクセスしてしまう現象が発生していました。

動いているプロセスを見てみると、gzipとかが延々と動いており、killしてもまた別のgzipプロセスが動き出していました。

gzipを起動しているプロセスを特定すればなんとかなるのかも知れませんけど、そもそもPDAで"ps ax"して問題のプロセスを見つけ"kill"するなんて、普通の使いかたとはとても・・・。


もちろん上記の問題は私の操作や設定に問題があり、回避する方法もあるのかもしれませんが、別のファイルマネージャの導入も検討することにしました。


ネットで調べていたら「Tree!Explorer QT」というなかなかよさそうなのがありました。

これはシェアウェア版だけではなくフリー版もあったためちょっといじってみたところSambaファイルシステム中の日本語も問題なく表示出来ていました。

フリー版だと機能が限定されており、ファイルを選択して実行してもプラス版を買えみたいなメッセージが出てしまうため、シェアウェア版を購入しました。


下の画像はSambaファイルシステム領域を参照中のスクリーンショットです。

Zaurusの/hdd3/Document以下にあるファイルをSambaファイルシステム領域にコピーしてみましたが、普通にできました。
当り前ですけど。

2007/07/22

IMAPメールが受信できなかった

ここ数日間IMAPサーバ(JULIE)からIMAPのメールを取得することが出来ていなかったみたいです。

以前書いたとおりGMailからでもメールを読めるようにしており、IMAPのメールは読んでいなかったのであまり気にしていませんでしたが。


今日調べてみて思い出したのですが、NFSのセキュリティのことを調べたときに/etc/hosts.allowの設定を変更しており、それが原因だったみたいです。

以前は/etc/hosts.allowには、以下のように危ない設定をしていました。
ALL : xxx.xxx.xxx.xxx/yyy.yyy.yyy.yyy: ALLOW

どうせ私しか使わないネットワークだしこれでいいだろうと思っていたのですが、やはり気持ち悪いので、許可するサービスを列挙するように変更しました。

それが原因でクライアントからimapdにアクセスできなくなっていたみたいです。


/etc/hosts.allowに以下の記述を追加したところ、IMAPのメールを読めるようになりました。
imapd: xxx.xxx.xxx.xxx/yyy.yyy.yyy.yyy


迂闊でした。

2007/07/21

Zaurusのnkfを新しくした

私がZaurusにいれていたnkfは、どうやらguessオプションに対応していないようです。
バージョンは次のとおりでした。
$ nkf --version
Network Kanji Filter Version 2.0 (3/0301/Shinji Kono)
Copyright (C) 1987, FUJITSU LTD. (I.Ichikawa),
2000 S. Kono, COW, 2002-2003 Kono, Furukawa


そこでZaurusのnkfを新しくできないかと考え、前回書いたようにnkfを作成してみました

nkfはこちらから2.0.8aをもらってきました。

とりあえず出来たバイナリ"nkf"をZaurus上にコピーしてそこにパスを通せば使えるようになりました。
$ nkf --version
Network Kanji Filter Version 2.0.8 (2007-07-09)
Copyright (C) 1987, FUJITSU LTD. (I.Ichikawa),2000 S. Kono, COW
Copyright (C) 2002-2007 Kono, Furukawa, Naruse, mastodon

$ nkf --guess code_test
EUC-JP

バッチリみたいです。


ちなみにnkfのguessオプションですが、nkf 2.0.4のChange Logに次の記述がありました。
nkf 2.0.4 からの仕様変更
1.--guess とすると、文字コードの判定結果を出力します。


2.0.4で追加されたのでしょうか?

Zaurusクロス開発環境を作ってみた

ちょっと思うところあってVine Linux 4.1にZaurus用のクロス開発環境を整えることにしました。

Zaurus用のクロス開発環境は、随分前にPlamo LinuxやWindowsXPのCygwinで整えた記憶があります。
ほとんど使いませんでしたが。


(1) Zaurus開発用ツールの取得
ザウルスサポートシュテーションから一通りいただいてきてインストールしました。

うちのVine Linux 4.1では、問題なくインストールできました。


(2) 環境変数の設定
とりあえず以下の環境変数を設定。
export CROSSCOMPILE=/opt/Embedix/tools
export QPEDIR=/opt/Qtopia
export QTDIR=/opt/Qtopia
export PATH=$QTDIR/bin:$QPEDIR/bin:$PATH:/opt/Embedix/tools/bin
export TMAKEPATH=/opt/Qtopia/tmake/lib/qws/linux-x86-g++/
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH



(3) zlib-1.2.3.tar.gz をインストール
konqueror embeddedでも作ってみようかと思っていろいろやっている過程でzlibを作成しました。
こちらは開発環境(Vine Linux 4.1)の/opt/Embedix/tools/arm-linux/以下にいれました。

ちなみにkonqueror embeddedはあきらめました・・・。
ZaurusのQtopiaが古すぎて、多分ダメだろうと。

QtopiaとかQt/Embeddedが何なのかよくわかっていません。
あとでこのあたり読んで勉強してみようかな。


(4) nkf-2.0.8.tar.gz のZaurus用バイナリを作成してみる。
Makefile一番先頭の"CC = cc"を"CC = arm-linux-gcc"に変えました。
あとはmakeするだけでした。

$ file nkf
nkf: ELF 32-bit LSB executable, ARM, version 1,
for GNU/Linux 2.0.0, dynamically linked (uses shared libs),
not stripped



とりあえず出来たかなと。

2007/07/20

ZaurusをSambaクライアントに

ZaurusをNFSクライアントに」ではZaurus(SL-C3000)をNFSクライアントにしましたが問題がありました。

問題1
ファイル名の日本語が表示出来ていません。

以前Sambaサーバ上のファイル名はShift-JISにしました。
NFSサーバとして使用している場合にはEUC-JPになっているはずです。多分。

ZaurusではSambaとNFSの両方で日本語表示できないということは、ZaurusはShift-JISでもEUC-JPでもないということでしょうか?
もしかしてUTF-8?

問題2
1Gくらいあるフォルダを"cp -ar"でNFS領域にコピーしたのですが、途中でcpがデッドロックとやらになってしまい止まってしまいました。

ログ(syslog)とか見てみたのですが、参考になるようなログはみつかりませんでした。
この場合どのログをみればよかったのでしょうか?
デッドロックの問題は原因がつかめていません。
まだ設定が不足している箇所も多数あると思いますが・・・。



上記のような問題が発生しているのを避けるため、NFSではなくSambaを使用してJULIE(NFSサーバ兼Sambaサーバ)にアクセスしてみるのはどうかと考えました。
本来であればNFSの設定を見直すべきかもしれませんが。

NFSの文字コード指定ってあるのか分かりませんが、Sambaならあるのは以前確認済みですし、日本語表示もなんとかなるのではないかとほのかな期待を抱いてやってみることにします。

(1) Zaurus用smbmountを取得
こちらからsmbmount_0.1_arm.ipkを取得し、インストールしました。
(後ほど述べますが、ここでインストールしたsmbmount_0.1_arm.ipkはその後アンインストールしました)

(2) JULIE(Sambaサーバ)の領域をマウント
#sudo smbmount //julie/share /mnt/julie/
-o username=xxx,ip=xxx.xxx.xxx.xxx

としてマウントしました。


(1)~(2)までで、とりあえずZaurusをSambaクライアントとして使用できるようになりました。
NFSを使用したときよりSambaを使っている方が動作が軽快な気がします。
(もちろんNFS設定をチューニングすればいいのかもしれません)

ところが、Zaurusのファイルマネージャではやはりファイル名の日本語表示が出来ていませんでした。

smbmountのオプションとしてcodepageとiocharsetがありますが、(1)でインストールしたsmbmount_0.1_arm.ipkでは対応していませんでした。

探してみたところcodepageとiocharsetのオプションに対応したsmbmountを配布されているサイトがありました。
こちらからsmbmount_2.2.8a-ja-1.0_arm.ipkをいただいてきてインストールし、次のようなコマンド引数でマウントしました。
sudo smbmount //julie/share /mnt/julie/
-o fmask=666,username=xxx,ip=xxx.xxx.xxx.xxx,
codepage=cp932,iocharset=utf8


結果、Sambaサーバ上の日本語ファイル名のファイルを、Zaurusのファイルマネージャで日本語表示出来るようになりました。



ちなみに、smbmountのオプションとして渡したiocharsetとcodepageは、Sambaのマニュアルには次のようにあります。
iocharset=<arg>
Linux 側のコードページ-文字コード変換 (NLS) で使用される文字コードを設定する。引数は iso8859-1 のようなキャラクタセットの名前でなくてはいけない。 (注: カーネル 2.4.0 以降のみサポートされる)


codepage=<arg>
サーバ側で使用される文字コードを指定する。 iocharset オプションを参照。例えば cp850 などである。 (注: カーネル 2.4.0 以降のみサポートされる)

私が行った設定の場合、iocharsetの説明中のLinuxとはZaurusを指し、codepageのサーバとはSambaサーバであるJULIE(Plamo Linux)を指します。

また、CP932はマイクロソフトのShift-JIS拡張らしいです。

Zaurusで観ているDivXファイル

うちのZaurus(SL-C3000)で観ているDivXファイルのメモ。
一応全部まともに観ることができる。

・歌手のプロモーションビデオ
解像度: 480 x 250
フレームレート: 15fps

・テレビアニメ
解像度: 320 x 240
フレームレート: 23fps

・歌手のプロモーションビデオ
解像度: 320 x 240
フレームレート: 23fps

2007/07/19

ZaurusをNFSクライアントに

そういえばZaurusでNFSファイルシステムって使えるのかなと疑問に思い、確認してみた。

まずZaurus(SL-C3000)でNFSファイルシステムをサポートしているか確認する。
ちなみにスペシャルカーネルになっています。

[root@zaurus: zaurus]# cat /proc/filesystems
nodev rootfs
nodev bdev
nodev proc
nodev sockfs
nodev tmpfs
nodev shm
nodev pipefs
ext3
ext2
cramfs
nodev ramfs
minix
vfat
iso9660
nodev nfs
nodev smbfs
ntfs
jffs2
nodev devpts

サポートしているみたい。

ところでJFSもサポートしているんだ。
使ってみようかな。


Zaurusの/etc/fstabに次の2行を追加。
xxx.xxx.xxx.xxx:/mnt/share/xxx  /mnt/julie  nfs  \ 実際は一行
users,noauto,rw,hard,intr,nosuid 0 0
xxx.xxx.xxx.xxx:/mnt/share3/xxx /mnt/elie nfs \ 実際は一行
users,noauto,ro,hard,intr,nosuid 0 0

追加したのはVine Linux 4.1とまったく同じ内容。


マウントポイントとするディレクトリを作成。
[root@zaurus: zaurus]# mkdir /mnt/julie
[root@zaurus: zaurus]# mkdir /mnt/elie



そして、マウント。
[root@zaurus: zaurus]# mount /mnt/julie
unknown nfs mount option: users
mount: nfsmount failed: Success
mount: Mounting xxx.xxx.xxx.xxx:/mnt/share/xxx
on /mnt/julie failed: Invalid argument

ものの見事に失敗。

usersオプションが無いということなので、/etc/fstabの記述をusersを取り除いたものに変更。
xxx.xxx.xxx.xxx:/mnt/share/xxx  /mnt/julie  \ 実際は一行 
nfs noauto,rw,hard,intr,nosuid 0 0
xxx.xxx.xxx.xxx:/mnt/share3/xxx /mnt/elie \ 実際は一行
nfs noauto,ro,hard,intr,nosuid 0 0


で、マウント。
[root@zaurus: zaurus]# mount /mnt/julie
[root@zaurus: zaurus]#

今度は成功。


使ってみた感想ですが、SL-C3000標準のファイルマネージャーでNFS領域に入って移動していると、すぐにフリーズしてしまう気が・・・。
設定が悪いのかな。

NFS領域の日本語フォルダ名が含まれる箇所で落ちてしまうのです。
もちろん日本語フォルダはたまたまかも知れません。
まだ検証できていません。

PCからtelnetでZaurusにログインした場合は、問題なく日本語読めているのですけど。
[zaurus@zaurus: WallPaper2]$ ls
008-m.jpg kekkonn_dekinai_otoko nestle soranokiseki
Zaurus koushien satomihakkenndenn ファルコム


もともとNFS領域をファイルマネージャーで参照する気はなかったですし、telnet接続してコマンドラインでの作業は問題なく出来ているので、とりあえずはいいのですけど。

後でもうちょっと検証してみます。

NFSについて調べる(セキュリティ)

NFSについて調べる(クライアント側)」の続きです。

サーバ側
・NFSは賢くない
JFの文書には次のようにあります。
再び例を: bob はサーバでユーザ ID 9999 にマップされているとしましょう。 ボブはサーバでユーザのみがアクセスできるファイル を作ります (chmod 600 filename と入力するのと同じです)。 そのファイルが保存されたドライブへのアクセスを、 あるクライアントが許可されました。 そのクライアントでは、ユーザ ID 9999 には mary がマップされています。 この場合、bob が自分にしかアクセスできないようにしたファイルに対して、 そのクライアントでのユーザ mary がアクセスできてしまいます。 さらに悪いことに、そのクライアントで誰かがスーパーユーザになってしまうと、 その誰かは su - username によって どんな ユーザにもなれてしまうのです。 NFS は賢いとは言えません。


・クライアントのrootは信用するな

root_squashオプションを使う。

これはデフォルトで有効であり、うちのNFSサーバ(JULIE)でも有効になっている。
julie:~# exportfs -v
/mnt/share3/xxx
xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx(ro,wdelay,root_squash)
/mnt/share/xxx
xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx(rw,wdelay,root_squash)


JFの記述から。
root_squash の状態では、クライアントで UID 0 (root のユーザ番号) のユーザがファイルにアクセス (read, write, delete) しようとすると、 サーバは UID をサーバにおける 'nobody' アカウントのものと置き換えます。 つまりサーバの root だけにアクセスや変更が許されているファイルに対して、 クライアントの root がアクセスや変更を行うことができなくなるのです。

実験。
クライアントの操作。
カレントディレクトリはNFSファイルシステム上。
$ su
パスワード(P):
# touch aaa
# ls -l aaa
-rw-r--r-- 1 65534 65534 0 7月19日 01:27 aaa


サーバで確認。
# ls -l aaa
-rw-r--r-- 1 nobody nogroup 0 Jul 19 01:27 aaa
# id nobody
uid=65534(nobody) gid=100(users) groups=100(users)
# cat /etc/group|grep nogroup
nogroup::65534:


重要なバイナリやファイルの所有者はbinなどではなくrootにすることが重要らしい。
root以外にすると、クライアント側のrootがサーバ側のバイナリやファイルの所有者idのユーザになって書き換えることが出来るから。


クライアント側
・suidプログラムを動作させない
nosuidオプションを使う。

JFの文書には次のようにある。
こうするとサーバの root ユーザが件のファイルシステムに suid-root プログラムを作り、クライアントに一般ユーザとしてログインし、 その suid-root プログラムを使ってクライアントでも root になる、 ということができなくなります。 さらに noexec オプションをつければ、 マウントしたファイルシステムでのファイルの実行を禁止することもできます。

noexecオプションを使えば、マウントしたファイルシステムのファイルを実行することができなくなるらしい。

NFSについて調べる(クライアント側)

NFSについて調べる(サーバ側)」の続きです。

クライアント側のことを調べます。

・サポートしているファイルシステムを調べる
/proc/filesystemを見ればいいみたいです。
$ cat /proc/filesystems
nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev binfmt_misc
nodev sockfs
nodev usbfs
nodev pipefs
nodev futexfs
nodev tmpfs
nodev inotifyfs
nodev eventpollfs
nodev devpts
reiserfs
ext3
ext2
cramfs
squashfs
nodev ramfs
nodev hugetlbfs
iso9660
nodev mqueue
vfat
nodev autofs
nodev rpc_pipefs
nodev nfs
nodev nfs4

NFSクライアント(SALIE)ではNFSをサポートしてようです。

ちょっと気になっていたのですが、Vine Linux 4.1のデフォルトカーネルは、/proc/filesystemを見る限りではJFSやXFSをサポートしていないように思えます。
多分。


NFSクライアント側の/etc/fstabにはNFSマウントように次の行を追加しています。
xxx.xxx.xxx.xxx:/mnt/share/xxx /mnt/julie
nfs users,noauto,rw,hard,intr 0 0 (実際は一行)


使用しているマウントオプション(hard)は、JFには次のようにありました。
hard

NFS マウントされたファイルシステム上のファイルにアクセスしている プログラムは、サーバがクラッシュすると宙ぶらりんになります。 これらのプロセスは intr を一緒に指定していない場合は、中断することも kill することもできなくなります ("sure kill" を使えば別)。 NFS サーバが復活すると、プログラムはそれぞれ何もなかったかのように再開します。 おそらくこちらが望ましい場合が多いでしょう。全ての NFS マウントには、hard,intr を用いることをお勧めします。


intrはNFSのマニュアルに次のようにありました。
intr

NFS へのファイル操作がメジャータイムアウトとなり、かつその NFS 接続が hard マウントされている場合、シグナルによるファイル操作の中断を許可 し、中断された場合には呼び出したプログラムに対して EINTR を返す。
デフォルトではファイル操作の中断を許さない。


NFSについて調べる(セキュリティ)」に続く。

2007/07/18

NFSについて調べる(サーバ側)

JFの「Linux NFS-HOWTO」を読んで、NFSについて調べてみたことのメモ。

まずはサーバ側のこと。

・NFS が動作しているか確認する
julie:~# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 729 mountd
100005 1 tcp 732 mountd
100005 2 udp 729 mountd
100005 2 tcp 732 mountd
100005 3 udp 729 mountd
100005 3 tcp 732 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 udp 1026 nlockmgr
100021 3 udp 1026 nlockmgr
100021 4 udp 1026 nlockmgr
100021 1 tcp 1079 nlockmgr
100021 3 tcp 1079 nlockmgr
100021 4 tcp 1079 nlockmgr
900101 1 udp 834
900101 2 udp 834
900101 1 tcp 837
900101 2 tcp 837

また、rpcinfoコマンドと引数"-p"はマニュアルには次のようにあります。
rpcinfo は、 RPC サーバに対して RPC 呼び出しを行い、得られた情報を表示する。

-p
host の portmapper を検出し、そこに登録されている全ての RPC プログラムの一覧を表示する。 host が指定されていない場合、 hostname(1) で返される値がデフォルトになる。

うちのNFSサーバ(JULIE)ではversion 2〜4のNFSが動いているみたいです。

・/etc/exports をあとから変更する
nfsd に /etc/exports ファイルを読み直させるために"exportfs -ra"コマンドを実行する。

exportfsコマンドのマニュアルには次のようにあります。
exportfs コマンドは、現在 NFS でエクスポートしているファイルシステムのテーブルを管理するために使うコマンドである。このリストは /var/lib/nfs/xtab という名前のファイルに保存される。

また、オプション"r"と"a"は次のようにあります。
-a
全てのディレクトリをエクスポート・アンエクスポートする。

-r
全 てのディレクトリを再エクスポートする。 /var/lib/nfs/xtab を /etc/exportsと同期させる。 /etc/exports から削除されたエントリを /var/lib/nfs/xtab からも削除し、既に無効になったエントリをカーネルのエクスポートテーブルから削除する。


NFSについて調べる(クライアント側)」に続く。

2007/07/17

KDEプログラミング その5

KDEプログラミング その4」の続きです。

あいかわらずよくわからずにやっています。
どんな方法が正しいのか分かりません。


それではチュートリアルを再開します。
今回は「P3」を行いました。

とりあえずチュートリアルにあるmain.cpp, p3.h, p3.cppを作成します。
$ ls
main.cpp p3.cpp p3.h



KDEプログラミング その2」と同様の手順でmakeを行ってみます。
$ qmake -project
$ echo INCLUDEPATH += /usr/include/kde >> p3.pro
$ echo LIBS += -lkdeui -L/usr/lib/kde3 >> p3.pro
$ qmake
$ make
g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2
-m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG
-I/usr/lib/qt3/mkspecs/default -I. -I. -I/usr/include/kde
-I/usr/lib/qt3/include -o main.o main.cpp

 〜略〜

g++ -o p3 main.o p3.o moc_p3.o -L/usr/lib/qt3/lib
-L/usr/X11R6/lib -lkdeui -L/usr/lib/kde3 -lqt-mt
-lXext -lX11 -lm
p3.o(.text+0xad4): In function `MainWindow::fileOpen()':
: undefined reference to
`KFileDialog::getOpenURL(QString const&,
QString const&, QWidget*, QString const&)'
p3.o(.text+0xd64): In function `MainWindow::fileSave()':
: undefined reference to
`KFileDialog::getSaveURL(QString const&,
QString const&, QWidget*, QString const&)'
collect2: ld はステータス 1 で終了しました
make: *** [p3] エラー 1


エラーになってしまいました・・・。
今まで一度もすんなりといったことがありません。


エラーの内容を見てみると、リンク中にgetOpenURL()とgetSaveURL()が見つからないと言っている気がします。

チュートリアル
では次のような記述があります。
Note that you're encouraged to allow the user to open any URL not just local files. For this, we have used a getOpenURL dialog, which lets the user select any url. Check below for an example on how to use the KIO library.


またKFileDialog::getOpenURLの関数リファレンスはこちらにあります。

KIO Libraryに含まれるのは確かのようなので、多分リンク時に"-lkio"とか入れるのでは無いかと想像しました。
探してみると/usr/lib/libkio.soというのがありましたので、当たりかなと。


そこで最初からmakeの手順をやり直してみます。
$ make clean
rm -f moc_p3.o
rm -f moc_p3.cpp
rm -f main.o p3.o
rm -f *~ core *.core
$ ls
Makefile main.cpp p3.cpp p3.h p3.pro
$ rm Makefile p3.pro
$ ls
main.cpp p3.cpp p3.h


プロジェクトファイルから作りなおします。
$ qmake -project
$ echo INCLUDEPATH += /usr/include/kde >> p3.pro


リンクするライブラリに"-lkio"を追加します。
"-lkui"ももちろん入れておきます。
$ echo LIBS += -lkdeui -lkio -L/usr/lib/kde3 >> p3.pro


一応p3.proの確認です。
$ tail -n3 p3.pro
SOURCES += main.cpp p3.cpp
INCLUDEPATH += /usr/include/kde
LIBS += -lkdeui -lkio -L/usr/lib/kde3


一気にmakeまで行います。
$ qmake
$ make
g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2
-m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG
-I/usr/lib/qt3/mkspecs/default -I. -I.
-I/usr/include/kde -I/usr/lib/qt3/include
-o main.o main.cpp
main.cpp: function 内の `int main(int, char**)':
main.cpp:6: 警告: `__comp_ctor' is deprecated
(declared at /usr/include/kde/kapplication.h:205)
g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2
-m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG
-I/usr/lib/qt3/mkspecs/default -I. -I.
-I/usr/include/kde -I/usr/lib/qt3/include
-o p3.o p3.cpp
/usr/lib/qt3/bin/moc p3.h -o moc_p3.cpp
g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2
-m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG
-I/usr/lib/qt3/mkspecs/default -I. -I.
-I/usr/include/kde -I/usr/lib/qt3/include
-o moc_p3.o moc_p3.cpp
g++ -o p3 main.o p3.o moc_p3.o -L/usr/lib/qt3/lib
-L/usr/X11R6/lib -lkdeui -lkio -L/usr/lib/kde3
-lqt-mt -lXext -lX11 -lm
$ ls
Makefile main.cpp main.o moc_p3.cpp moc_p3.o p3*
p3.cpp p3.h p3.o p3.pro


make成功し、実行ファイルp3が作成されました。
早速実行してみます。
$ ./p3

動きました。


ソースの中身をまだ詳細を理解していないため、次はp3のソースをもっと調べることにします。
KIO Libraryを含めて。

英語だけど。

"/"の使用量が92%になった

最近多用しているVine Linux 4.1は/usrと/homeはそれぞれ個別にパーティションを準備し、その他はNFSやVFATのように付帯的な領域を除いてすべて同一パーティション"/"(ルート)に属しています。
/dev/hda7  /
/dev/hda6  /home
/dev/hda9  /usr


"/"(ルート)は1.6GB確保してあるのですが、使用量が92%になってしまいました。

調べてみたところ、/var/cache/aptが887Mも使っています。
[root@localhost root]# du -sh /var/cache/apt/
887M /var/cache/apt/


そこで、aptの不要なファイルは削除することにしました。
[root@localhost root]# apt-get clean


887M→4.4Mと劇的に減少しました。
[root@localhost root]# du -sh /var/cache/apt/
4.4M /var/cache/apt/


"/"(ルート)の使用量は29%になりました。


ところで、増大しているファイルやディレクトリを調べている過程で、/proc/kcoreという巨大なものを見付けました。
[root@localhost root]# ls -l /proc/kcore
-r-------- 1 root root 939528192 7月17日 03:28 /proc/kcore


ネットで検索してみたところ、これは気にしなくてもよいようです。
マニュアルには次のようにあります。
/proc/kcore

このファイルはシステムの物理メモリを表現しており、 ELF コアファイル形 式(core file format) で保持されている。この擬似ファイルと strip されていないカーネルのバイナリ (/usr/src/linux/vmlinux [訳注: パッケージに依存する])があれば、GDB はカーネル内の任意のデータ構造の現在の状態を調べられる。

このファイルの大きさは物理メモリ (RAM) のサイズに 4KB を加えた値である。
Vine Linux 4.1をインストールしているノートPCにはメモリを1GB積んでいるので、これくらいの値になっているようです。

2007/07/16

日本語文字化けをどうにかする その4

日本語文字化けをどうにかする その3」の続きです。

前回まででNFSクライアントであるVine Linux 4.1では文字化けを解消できましたが、Windows PCからのアクセスを確認していません。

SambaサーバのPlamo Linux(ホスト名 JULIE)がマウントしているReiserFS領域をWindowsで参照する際に文字化けするか確認し、問題があれば対応したいと思います。


日本語文字化けをどうにかする その1」で行ったのはNTFSファイルシステムをLinuxでマウントする際のオプションを変更しただけでファイルやフォルダをいじった訳ではないので問題ありません。

気になるのは、「日本語文字化けをどうにかする その2」で行ったファイル名やフォルダ名をShift-JISからEUC-JPに変更してしまっている点です。

これをSambaでWindowsから参照できるようにした場合に、正常に読むことができるのでしょうか?


確認のため、「日本語文字化けをどうにかする その2」で行った手順を再度行います。

(1) SALIE(NFSクライアント)からNFSマウントしたReiserFSファイルシステム上のファイル名・フォルダ名が文字化けしているのを確認。
Konquerorで確認します。

(2) convmvコマンドを使用してファイル名・フォルダ名をShift-JISからEUC-JPに変換。
$ convmv -r -f sjis -t euc-jp * --notest
mv "xxx/PDF/gZ" "xxx/PDF/トラ技"
mv "xxx/Docs/Zaurus/J�txt" "xxx/Docs/Zaurus/開発環境.txt"
mv "xxx/Pictures/WallPaper/t@R" "xxx/Pictures/WallPaper/ファルコム"
mv "xxx/Movie/O/コピー ~ multimodal_arm.tar"
mv "ubN}[N/C莅lzh" "ubN}[N/お気に入り.lzh"
mv "./ubN}[N" "./ブックマーク"
Ready!


(3) SALIE(NFSクライアント)で文字化けしていないことを確認。
Konquerorで確認します。
化けていたのは「ブックマーク」というフォルダでした。

(4) Windows(Sambaクライアント)で文字化けしているかを確認。
やっぱり化けてました。


文字化けが発生していたため、JULIE(Sambaサーバ)の設定を変更することにより解決できないか検討します。

(5) Sambaの設定を変更。
smb.confの[global]に以下の記述を追加。
coding system = euc
client code page = 932


各設定値の説明はマニュアルにありました
マニュアルのcoding systemの項からの引用です。
coding system (G)

このパラメータは、 Samba が受けとった Shift-JIS の日本語文字を、 クライアントが使っているclient code pageから UNIX ファイルシステムのファイル名にどのように対応づけるかを指定する。 このパラメータは、client code page が932(日本語 Shift-JIS)の時のみ有効である。オプションは以下のとおり:



次にclient code pageの項からの引用です。
client code page (G)

このパラメータは、Samba にアクセスするクライアントが利用している DOS コードページを指定する。 Windows や DOS クライアントで利用されているコードページを確認するには、 DOS コマンドプロンプトを開いて、chcpコマンドを入力する。 これによりコードページが表示される。 USA 版の MS-DOS、Windows 95、Windows NT のデフォルトは 437 である。 西ヨーロッパ版のこれら OS のデフォルト値は 850 である。


(6) Sambaを再起動。
JULIE(Sambaサーバ)のsmbdとnmbdの両方を再起動しました。
両方再起動したのは念のためです。

(7) Windows(Sambaクライアント)で文字化けしているかを確認。

文字化けは解消されています。

(8) Windows(Sambaクライアント)が作成した日本語ファイル名・フォルダ名の確認。
Windows(Sambaクライアント)で作った日本語名のフォルダをJULIE(Sambaサーバ)へコピー。

(9) SALIE(NFSクライアント)でWindowsで作成した日本語名のフォルダを確認。
Konquerorで確認します。

OK!

文字化け対策はとりあえず一通り出来たかなと思います。
何か忘れていることはないかな?

日本語文字化けをどうにかする その3

日本語文字化けをどうにかする その2」の続きです。
ReiserFSファイルシステムでの文字化けについてです。

なお、多分重要な点として「Vine Linux 4.1はEUC-JPがデフォルトになっているらしい」ということがあります。
$ echo $LANG ja_JP.eucJP


NFSサーバのPlamo Linux(ホスト名 JULIE)がマウントしているReiserFS領域をVine Linux(ホスト名 SALIE)でNFSマウントした際の文字化けをなんとかしたいと思います。

私が使用しているのはReiserFSですが、ext2やext3でも同じではないでしょうか。
多分。
JFSやXFSはどうかな?


SALIE(NFSクライアント)のKonquerorでは次のように文字化けしていました。
ひどいありさまです。

行った対策は次の通りです。
・保存されているファイル名・フォルダ名の文字コードがShift-JISであるので、EUC-JPに変更する。
・ファイル名・フォルダ名の変更にはconvmvというツールを使用する。

convmvはSALIE(NFSクライアント)にインストールしました。
Vine Linuxにはconvmvが見つからなかったため、Fedora-JPのサイトからconvmv-1.10-2.fc6.src.rpmをいただいて、それをrpm --rebuildしました。

convmvはNFSサーバとクライアントのどちらにインストールして大丈夫ですが、書き込み権限は必要かと思います。


変換する際のコマンドは次の通りです。
$ convmv -r -f sjis -t euc-jp * --notest
mv "ル@ル@ル~@/ル~@.mdi" "ル~@/資産設計(2) 戦術編 10 万円ではじめる方法.mdi"
mv "ル~@/ル~@.pdf" "ル~@/資産設計(2) 戦術編 10 万円ではじめる方法.pdf"

~以下略~



この結果、SALIE(NFSクライアント)のKonquerorで正常に表示できるようになりました。



日本語文字化けをどうにかする その4」に続く。

日本語文字化けをどうにかする その2

日本語文字化けをどうにかする その1」の続きです。
まずはNTFSの方です。

なお、多分重要な点として「Vine Linux 4.1はEUC-JPがデフォルトになっているらしい」ということがあります。
$ echo $LANG
ja_JP.eucJP


NFSサーバのPlamo Linux(ホスト名 JULIE)がマウントしているNTFS領域をVine Linux(ホスト名 SALIE)でNFSマウントした際の文字化けをなんとかしたいと思います。

SALIE(NFSクライアント)のKonquerorでは次のように文字化けしていました。

行った対策は次の通りです。
・JULIE(NFSサーバ)でNTFSファイルシステムをマウントする際に文字コードを考慮する


文字化けしている際のJULIE(NFSサーバ)側のfstabの記述は次のようになっていました。

・変更前の/etc/fstabの記述

/dev/hda1  /mnt/share3  ntfs  defaults,umask=000  0  0


文字化け対策として、次のように記述しました。
オプションのroは、書き込み禁止を明示的に指定したくてついでに書いておきました。
・変更後の/etc/fstabの記述
/dev/hda1  /mnt/share3  ntfs  umask=000,nls=euc-jp,ro  0  0

mountのマニュアルのntfsの項には次のように書いてあります。
iocharset=name
ファイル名を返すときに用いる文字セット。 VFAT とは異なり、NTFS は変換できない文字を含む名前を抑制する。このオプションは推奨されない。

nls=name
以前は iocharset という名前であったオプションの新しい名前。

mountのマニュアルのvfatのオプションはfatと同様のものが多く、fatの項には次のように書いてありました。
iocharset=value
8ビットの文字を 16 ビットの Unicode 文字に変換する (あるいはその逆)ときに用いる文字セット (character set)。デフォルトはiso8859-1である。長いファイル名は、ディスクには Unicode フォーマットで保存されている。

JULIE(NFSサーバ)のfstabを変更後にSALIEでマウントすると、文字化けはとりあえず解消されたようです。
文字化けしていたのは「ファルコム」というディレクトリでした。


日本語文字化けをどうにかする その3」に続く

日本語文字化けをどうにかする その1

最近はノートPCにインストールしたVine Linux 4.1でKDEを使っていることが多いです。

その際はWindowsXPマシンも同時に立ち上げ、WindowsXPのVMWareにインストールしてあるPlamo LinuxもWindowsXP起動と同時に立ち上げ、ファイルサーバなどとして使用することもあります。
(うちのネットワーク環境についてはこちら)

起動しているVineとPlamoのホスト名は次のようになっています。
Plamo Linux: JULIE
Vine Linux: SALIE


JULIEではファイル共有用のハードディスクを2台マウントして、NFSやSambaでローカルネットワーク上に開放しています。

ファイルシステムは1台はNTFS, もう1台はReiserFSです。

この2台のハードディスクに入っている日本語の名前がついたファイルやフォルダがSALIEのKDE Konquerorで見ると文字化けしてしまいます。
(ちなみにGNOMEのNautilusでは、Konquerorでは文字化けしているのに文字化けしないものもありました。)

この文字化けを、今さらながらなんとかしたいと思います。


結論から言うと、問題の対策は次の通りに行いました。

・NTFSファイルシステムの文字化け
 → マウント時にオプション"nls=euc-jp"を指定する
 (「日本語文字化けをどうにかする その2」で検証)

・ReiserFSファイルシステムの文字化け
 → ファイル名やフォルダ名をShift-JISからEUCに変更する
 (「日本語文字化けをどうにかする その3」、「日本語文字化けをどうにかする その4」で検証)



なお、数年前はPCを使用する際はLinuxを使用することが多かったのに、その際はほとんど問題になりませんでした。

その理由はこんな感じでしょうか。
・Linux上で自分が作ったファイルの名前に日本語でつけることは絶対にない。

・Windowsを使っている際も自分なりのファイル命名規則があった。
 それは、日本語ファイル名は使わないということ。
 しかし、しばらくLinuxを使用していない間に日本語ファイル名を使ってしまっていた。

・iTunesで作成した音楽ファイルに日本語名がついていることが多い。
 Linuxを常用している頃はcdparanoia + LAMEでMP3ファイルを作成していた。


NTFSとReiserFSでは行った対策が異なりました。
分けて記述しておきます。


日本語文字化けをどうにかする その2」に続く。

GMailを使って

今まではLinuxサーバ(JULIE)でプロバイダ(BIGLOBE)からfetchmail(POP3)でメールを取得し、JULIEをIMAPサーバとしてローカルネットワーク上でメールを閲覧していました。
(我が家のネットワーク環境はこちら)


最近GMailの使用方法を試行錯誤しており、GMailを我が家のネットワーク環境構築に組み入れられないかなと考えました。

GMailはPOP3で他のメールサーバからメールをGMailのサーバ上に取得するしくみがあります。
また、GMailサーバからPOP3でメールを取得することも出来ます。

そこで、プロバイダ(BIGLOBE)のメール取得はGMailのサーバで行い、ローカルネットワークのIMAPサーバ(JULIE)はGMailからPOP3でメールを取得することにします。
これによる私のメリットは次の点でしょうか。
・GMailの2GBという膨大な大きさの領域を使用できる。
 BIGLOBEは20MB。
 →余程のゴミメールでない限りGMail上に残しておいても大丈夫。
 →GMail上にあるメールはGMailを使える環境であればいつでも閲覧できる。(職場とか)

・何らかの理由で自宅がインターネットに接続できないときでも、ローカルネットワーク上の端末ではどこでもIMAPで過去のメールを閲覧することが出来る。

・GMailは色々面白いみたい。
 (LinuxでFUSEとやらを使用してGMail領域をmount出来るらしい)


BIGLOBEに一度集めることはせず、アドレス1〜3及びBIGLOBEの4つのアドレスからGMailに転送設定するという手段もありますが、変更しなければいけない箇所が増えてめんどくさいので止めておきます。

また、アドレス1〜3のうちの2つは転送のみ行うアドレスで、POP3などで取得することは出来ません。
ですので、アドレス1〜3及びBIGLOBEの4つのメールアドレスすべてをJULIEで直接取得することはできません。
2つは必ずどこかのアドレスに転送してから取得する必要があります。


GMailからメールを取得するため、.fetchmailrcには次のように記入しました。
--ここから--
set nobouncemail

defaults
mda "/usr/bin/procmail -d mailuser"
no mimedecode
--ここまでは、以前から記入されていたものをそのまま使う--

--ここからGMail用に追加--
poll pop.gmail.com
protocol pop3
port 995
user GMailのユーザ名@gmail.com
password GMailのパスワード
ssl
keep
--ここまで--

一応これで取得できています。

keepオプションが必要なのか分かりませんが、入れておいて悪くなることもないかなと。
多分。

2007/07/15

NFSの設定

VMwareで動かしているPlamo LinuxをNFSサーバにした時の設定手順です。
設定はJFのドキュメントを参考にしました。

本当はもっと詳細にドキュメントを読んでから設定を行わなければならないとは思いますが、とりあえずは使えるようにすることを目標にします。
マネしないでください。

(1) サーバ側(Plamo Linux on VMware)の設定
・/mnt/share/hoge をNFS共有ディレクトリとする
サーバのIPアドレスはxxx.xxx.xxx.xxxと仮定する。

(a) /etc/exportsに以下を追加
mnt/share/hoge xxx.xxx.xxx.0/255.255.255.0(rw,sync)

(b) /etc/hosts.deny に以下を追加
portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

(c) /etc/hosts.allow に以下を追加
portmap: xxx.xxx.xxx.0/255.255.255.0
lockd: xxx.xxx.xxx.0/255.255.255.0
mountd: xxx.xxx.xxx.0/255.255.255.0
rquotad: xxx.xxx.xxx.0/255.255.255.0
statd: xxx.xxx.xxx.0/255.255.255.0

古いnfs-utilsを使っていた場合でも、lockd, mountd, rquotad, statdを追加しても問題にならないらしいのでとりあえず追加しておきました。
いいかげんです。

(d) nfsd に /etc/exports ファイルを読み直させる
# exportfs -ra


(2) クライアント側の設定
・/mnt/fugaにマウントする

(a)とりあえずmountコマンドで試してみる
# mount xxx.xxx.xxx.xxx:/mnt/share/hoge /mnt/fuga
# df
中略
xxx.xxx.xxx.xxx:/mnt/share/hoge 244188576 97894944 146293632 41% /mnt/fuga

成功しているらしい。

(b) (a)でマウントしたディレクトリをアンマウント
# umount /mnt/fuga

(c) /etc/fstab に以下を追加
xxx.xxx.xxx.xxx:/mnt/share/hoge /mnt/fuga nfs noauto,rw,hard,intr 0 0

(d) mountコマンドを実行
# mount /mnt/fuga
# df
中略
xxx.xxx.xxx.xxx:/mnt/share/hoge 244188576 97894944 146293632 41% /mnt/fuga

成功。

2007/07/14

KMail + IMAP + Googleデスクトップ

現在使用しているVine Linux 4.1では、最近は主にKDEを使用しています。


Kontact 1.2.5(KMail 1.9.7)でIMAPのメールを主に読んでいますが、プロバイダからPOP3でサーバにメールを残す設定でメールを取り込むこともあります。

IMAPのメールはKMailの「cachedimap」という設定にしており、IMAPサーバからローカルにメールをコピーしています。



また、先日リリースされたGoogleデスクトップのLinux版もインストールしてあります。


Googleデスクトップで次の現象が発生していました。
KMailの設定が上手くできている自信はないので、問題がどこにあるのか分かっていません。

・KMailでPOP3で取り込んだメール
 →インデックスを作成してくれる

・KMailのcachedimapでローカルにコピーしているメール
 →インデックスを作成してくれない


KMailのcachedimapのメールは、ホームディレクトリの次の場所に保存されているようです。
  HOME/.kde/share/apps/kmail/dimap/.xxxxxxxxxx.directory (xは数字)


Googleデスクトップの設定には「次の場所を検索」という設定があり検索場所を指定できますが、上記の場所を指定してもインデックスを作成してくれませんでした。


そこで、`.' で始まる名前のディレクトリ(.kde)から出してやればインデックスを作成してくれるのではないかと考え、次の操作を行いました。

(1) ホームディレクトリにKMailというディレクトリを作成
$ mkdir ~/KMail


(2) KMailディレクトリの下にcachedimap保存ディレクトリをfoldersという名前に変えて移動
$ mv ~/.kde/share/apps/kmail/dimap/.xxxxxxxxxx.directory ~/KMail/folders


(3) ~/Kmail/foldersのシンボリックリンクを~/.kde/share/apps/kmail/dimap/.xxxxxxxxxx.directoryとする
$ ln -s ~/KMail/folders ~/.kde/share/apps/kmail/dimap/.xxxxxxxxxx.directory


これで、Googleデスクトップがインデックスを作成してくれるようになりました


スマートでないのは分かっていますが、いい情報がみつかるまでこれで我慢します。

POP3で取り込んだメールも.kdeの下にありますので、単純に`.' で始まる名前のディレクトリ以下にあると全部ダメという訳ではないと思います。


ヘルプセンターを良く読めば分かるのでしょうか?

我が家のネットワーク

2007年7月14日現在の、我が家のネットワーク環境です。

うちでは2台のPCで3つのOSを同時に使用しています。

以下の括弧中はホスト名です。
PC
(a) タワー型PC
 OS: WindowsXP Professional (ELIE)

(b) ノートPC (WindowsとLinuxのデュアルブート)
 OS: WindowsXP Home Edition (SHIRO)
 OS: Vine Linux 4.1 (SALIE)

(a)のELIEではVMWare Serverを使用しております。

VMWareゲストOS
 OS: Plamo Linux (JULIE) Samba/NFS/IMAP

(a)のタワー型PCにはハードディスク3台を接続してます。
その内2台はWindowsXP(ELIE)で使用しておりますが、もう1台は全ての領域をReiserFSでフォーマットしており、JULIEでマウントしています。

このReiserFSの領域の多くはSamba/NFSを使用して開放され、JULIEはファイルサーバとなっています。


また、JULIEはプロバイダからfetchmailを利用してPOP3でメールを定期的に受信し、それを今度はIMAPサーバとしてローカルネットワーク上で公開しています。

おかげで(b)にインストールしてあるWindows(SHIRO)やLinux(SALIE)だけではなく、ZaurusやWindows Mobileマシンからでもメールを参照することが出来ます。

2007/07/13

Kontact(KMail)がutf-8になる

最近KDEを常用するようになり、Kontactも使用するようになりました。
Kontact 1.2.5です。



フィード(Akregator)はとてもいい感じです。
RSSは便利だなぁと、今さらながら思います。

登録しているサイトが更新されると、ちゃんとKDEパネルに表示されます。

拡大。
時計のとなりの"1"と出ているのがそうです。
新着一件ということです。



カレンダーはiCalフォーマットを使用してGoogleカレンダーを表示させています。
Googleカレンダーの更新は出来ませんので、表示させているだけですが。

Googleカレンダー側が他のアプリケーションでGoogleカレンダーを表示させた場合に読み取り専用にしかならないようです。
  Googleヘルプセンター


メールの送受信はKontactからKMail 1.9.7を使用しています。
IMAPとPOP3のメールを取り込んでいます。

受信は特に問題は起きていないのですが、送信する際にメールがutf-8になってしまうという現象が発生しました。

ネットで検索してみたところ、KMailの設定で文字コードをiso-2022-jpを先頭に持ってくるとiso-2022-jpで送信できるようになるという情報がありましたので、そのようにしてみました。


が、やはりutf-8になってしまいます。


色々試してみたところ、うちでは現状次のような状況になってしまうようです。
以下の実験はすべて、「件名」を「テスト」、本文を「テストです」にしたメールを送信してみました。

・KontactからKMailを使用して文字コードを変えずに送信する
 →utf-8になる
  Subject: =?utf-8?b?44OG44K544OI?=
  Content-Type: text/plain;
   charset="utf-8"
  Content-Transfer-Encoding: base64


・KDEメニューからKMailを立ち上げ(つまりKontactは起動しない)、文字コードを変えずに送信する
 →iso-2022-jpになる
  Subject: =?iso-2022-jp?b?GyRCJUYlOSVIGyhC?=
  Content-Type: text/plain;
   charset="iso-2022-jp"
  Content-Transfer-Encoding: 7bit


・KontactからKMailを使用して送信する際に、「メール作成」画面で「オプション」メニューから「エンコーディングの設定」を選択し、iso-2022-jpを指定する。

→iso-2022-jpになる
  Subject: =?iso-2022-jp?b?GyRCJUYlOSVIGyhC?=
  Content-Type: text/plain;
   charset="iso-2022-jp"
  Content-Transfer-Encoding: 7bit


送信する際に文字コードを指定すれば、今のところ問題は発生していないようです。


結果として、Kontact経由でKMailからメールを送信する場合、文字コードをiso-2022-jpに明示的に指定しないとutf-8になってしまうみたいです。

KMailやKontactの設定が悪いのでしょうか?

nkfでも文字コードって調べられるのですね

何か出来るオプションがあるはずだと思いつつ、調べもせずに放置していたのですが・・・。

nkfでもテキストファイルの文字コードを調べられるのですね。
今まではkcc -cでしかしたことありませんでした。

$ nkf --guess linux_print01.txt
EUC-JP



いや、お恥ずかしい。

KDEプログラミング その4

KDEプログラミング その3」の続きです。

引きつづき前々回のmake中に実行されたgcc(g++)コマンドのオプションを調べます。

(2) g++ -o p2 main.o -L/usr/lib/qt3/lib -L/usr/X11R6/lib -lkdeui -L/usr/lib/kde3 -lqt-mt -lXext -lX11 -lm

-o:
(1)でも出てきましたが、出力先を指定します。
今回の出力先はp2ということになります。

実行ファイルを作る場合、-oオプションを省略するとa.outというファイルが作成されるようです。


-L:
-Ldirという形式でdirを-lオプションにより検索されるディレクトリのリストに追加します。


-l:
フォントによっては分かりづらいですがL(エル)の小文字です。

マニュアルから抜粋します。
名前が library であるライブラリをリンク時に使用します。

リ ン カは、標準のライブラリ用ディレクトリのリスト中から、実際のファイル名が`liblibrary.a' であるファイルを検索します。リンカはこのファイルを、ファイル名で直接指定した場合と同様に使用します。

検 索するディレクトリには、いくつかの標準システムディレクトリと、`-L' によって指定したディレクトリが含まれます。


このあたりは以下のサイトでも読んで、もう少し勉強したいと思います。
  オブジェクト不指向の共用オブジェクト(developerWorks)


とりあえず、以上です。


KDEプログラミング その5」に続く。

KDEプログラミング その3

KDEプログラミング その2」の続きです。

チュートリアルはちょっと休憩して、gcc(g++)で使用していたコンパイルオプション位は調べてみます。

数年前に一通り調べたような記憶はあるのですが、すっかり忘れました。


前回make中に実行されたgcc(g++)コマンドは2つでした。

まず一つめです。
(1) g++ -c -pipe -Wall -W -I/usr/include/freetype2 -O2 -m32 -march=i386 -mcpu=i686 -DQT_NO_DEBUG -I/usr/lib/qt3/mkspecs/default -I. -I. -I/usr/include/kde -I/usr/lib/qt3/include -o main.o main.cpp

-c:
これはmanページを参照すると次にようにありました。
ソースファイルを、コンパイルまたはアセンブルまではしますが、リンクはしません。コンパイラの出力は、それぞれのソースファイルに対応したオブジェクトファイルとなります。

要するにmain.cppからmain.oを作っているようです。


-pipe:
manページからです。
コンパイル時のステージの間のデータの受け渡しに、テンポラリファイルではなくパイプを使用します。いくつかのシステムではアセンブラがパイプからの入力を受け付けることができないために、このオプションを指定すると失敗します。GNU アセンブラでは問題なく使用できます。

このオプションを使うメリットってなんなのでしょうか?
テンポラリファイルを使わないということなので、無駄な記憶領域を使わないとかかな?
そんなこともないか。

と疑問に思ったのでGoogleで調べてみると、記述のあるサイトがありました。
コンパイルにかかる時間が短縮されるが、より多量のメモリが必要。

アセンブラがパイプからの入力をサポートしていないシステムもあるということですが、前回も書いたとおりMakefileはqmakeを使用して作成していますので、もしかしたらqmakeがそのあたりを調べて-pipeオプションを付けるかどうか判断しているのかもしれません。


-Wall:
-W:
-Wallは覚えているのですが、-Wは何でしょう?
マニュアルの-Wallの項目には次のようにあります。
全ての上に挙げた `-W' オプションを結合したものです。これらのオプションは全て、たとえマクロとの組み合わせであっても、避けたほうがいいと我々が推奨する用法や、簡単に避けることができると我々が信じている用法に関するものです。

ちなみに、-Wは-Wallより先に記述されています。
ということは「-Wオプションはいらないんじゃないの?」と思い、調べたところ次のサイトで詳しく説明されていました。
  gcc の警告オプション -Wall と -W

上記サイトによると、-Wは-Wallには含まれないようです。
-W オプションは、-Wall では無視されたけどチェックした方がよい場合がある項目に対して警告を出すらしいです。


-I:
フォントによっては分かりづらいですが、i(アイ)の大文字です。
これは覚えています。
マニュアルには次のようにあります。
インクルードファイルの検索するディレクトリのリスト中に追加します。

これは必ず覚えておかなければいけないですよね。


-O2:
最適化オプションです。
-O・-O1→-O2→-O3と最適化の度合が増すようです。
マニュアルの-O2の項目には、次のようにあります。
さらに最適化を行います。サポートされている最適化手段のうち、空間と速度 のトレードオフを含まないものはほとんどの全て使用されます。例えばループのアンローリングや関数のインライン化は行われません。 -O と比較して、このオプションはコンパイル時間と生成コードの性能の双方を増加させます。


私の記憶では最適化に-O2を使用していることが多いようです。
ネットで調べたところ明確な記述は見つからなかったのですが、最適化を強くすると値が不正確になる場合があると書いてあるサイトがありました。


-m32:
-mはターゲットマシン固有のオプションのようです。
次のサイトに記述がありました。
  最新x86CPUで堪能する極上32&64ビット・ライフ Part1(1)

32ビットアプリケーションとしてビルドする場合は-m32、64ビットアプリケーションとしてビルドする場合は-m64を指定するようです。


-march=i386:
-mcpu=i686:
次のサイトに記述がありました。
  GCC: CPU に関する最適化オプション

-marchは指定した CPU だけで動作するようなコードをし、-mcpu より速いコードを生成することが出来き、-mcpuは-marchと違って同系列の CPU でも動作するようなコードを生成するらしいです。

"-march=i386 -mcpu=i686"と指定すると、
・i686向けのコードを吐き出すけど、i386でも動く。
・i386系で速く動くコードを吐き出す。
ということでしょうか?
分かるような分からないような。


-DQT_NO_DEBUG:
-Dオプションは-Dmacroという形式でmacroに文字列"1"を与えているようです。

QT_NO_DEBUGはどう見てもQtのマクロなので、ソース中で使用しているのでしょう。
QT_NO_DEBUGはデバッグコードを無効にしているようです。


-o:
出力先を指定します。
今回の出力先はmain.oということになります。



あー疲れた。
続きはまた今度。

KDEプログラミング その3」へ続く。