カテゴリー: Unix

投稿日:

Mac OS X上のVirtualBoxにUbuntuをインストールしてみた

Sunが、個人使用に限ってではあるが、無料でPCの仮想環境である VirtualBox を公開している。バージョンも上がってきて、完成度も高くなっているようだ。Mac OS X がそもそもUNIXなので、その上に同じUNIXである Ubuntu を入れる必然性がやや疑問だが(笑)、MacはUNIXとしては少々異端で、UNIXのソフトをコンパイルするのに苦労することも多いから、ごく普通のUNIXとして、Ubuntuを入れておいても良いだろうと思った。以下、再びインストールするときの為の、最小限のメモ。

まずは、Sunのサイトから最新版のVirtualBoxを落としてインストールする。VirtualBoxとは良く言ったもので、マシンの電源を入れるところから仮想化されている。新たな仮想マシンを作り、これにUbuntuをインストールする。作業は、一般のIBM PC (=Windowsマシン)にUbuntuをインストールする手順と同じ。それがVirtualBox内でシミュレーションされることだけが異なる。

新しく作った仮想マシンの設定としては、とりあえず実メモリーを1Gバイト、ハードディスクを最大で20Gバイトとした。ハードディスクの容量は必要に応じて増やしていくので、最初から20Gが消費されるわけではない。設定するのは最大のサイズということ。音楽とかそういうことはMac側でやるから20Gもあれば十分だと思う。

次にUbuntuをインストールするために、Ubuntu日本語版のCDイメージ (拡張子 iso のファイル)をダウンロードして適当な場所に置く。仮想マシンの電源を入れて、CDイメージをマウントする。実機で言えば、CDを差し込むことに対応する。そうすると、実機と同様に Ubuntu が Live モードで起動する。あとは、ハードディスク(仮想マシン上に設定したもの)にインストールすることを選ぶだけ。これで、Ubuntuのインストールは終了。

このあと、Guest Additions をインストールする。これをやっとかないと、ファイル共有とか様々なことで不便。ここまで自動でやってくれれば言うことないのだが。

以上で基本設定は終わりだが、実は日本語入力ではまった。かな、英数のキーが全然反応しないのである。調べた結果、日本語IMであるSCIM/Anthyの起動・終了は、コントロール・スペースで行うことが分かった。日本語・英語の切り替えはコントロール J で行う。これを、かな・英数のキーに変更することを試みたが、キー自体を認識してないようで、あきらめた。まあ、しかし、この程度なら許容範囲だ。

Macとファイル共有する方法。Macの側で、適当なフォルダーを作り、共有フォルダーにしておく。次に、VirtualBox上のUbuntuに移り、VirtualBoxフレームの右下にあるアイコンから、ファイル共有のアイコンをクリックする。共有したいフォルダーを選ぶ。マックのファイルシステムが見えるので、そこから、先ほど作った共有フォルダーを選ぶ。その際、フォルダーの名前を覚えておく。ここでは、それを sharedfolder とする。

Ubuntuからそのsharedfolderをマウントするには、次のようにする。まず、Ubuntuのファイルシステム内に、対応するフォルダーを作る。名前は同じでなくても良いが、今回は /home/hoge(ここは自分のアカウント)/sharedfolder と同じ名前のフォルダーを自分のホーム直下に作った。これをUbuntuからマウントするには、mount.vboxsf なるコマンドを使う。ターミナルを起動して、

sudo mount.vboxsf sharedfolder /home/hoge/sharedfolder

と打ち込む。これで、sharedfolderを通してファイルの交換が出来る。ログアウトすると、この設定は失われてしまうので、/etc/rc.local に書き込んでおく。このファイルはroot権限がないと編集できないので、

sudo gedit /etc/rc.local

として編集し、exit 0 の直前に、

mount.vboxsf sharedfolder /home/hoge/sharedfolder

という行を書き込む。これで、ログイン時にこのコマンドが実行されて、共有フォルダーがマウントされるはず。

とりあえずは、こんなところかな。

投稿日:

TeX文書の文字コードを一括してUTF8に変換する

[ 備忘録 ] 以前のMac OS 9とかの頃には、フォルダーをドラッグ＆ドロップすれば、それに含まれる文書の文字コードやら行末コードを一括して変換してくれるツールがあった。Mac OS Xでも似たようなツールがありそうなはず・・・と検索したが、一つだけ見つかったそのツールはTeX文書の変換には使えないことが分かった。だって、バックスラッシュをすべてユニコードの円マークに変換してしまうのだから 👿 。

やれやれ、どうしたものかとあれこれ検索。すると、ターミナルからUNIXのツールを組み合わせれば、簡単に実現できることを知る。nkf を用いて、カレント・ディレクトリー内のすべてのテック文書をUTF8に変換したことはあったのだが、find と組み合わせてパイプラインで送れば良いのだった。ポイントは xargs を利用すること。具体的には、次のようにする。

find . -name '*.tex' -type f -print | xargs nkf --overwrite -w -Lu

こうすれば、find がカレント以下のサブフォルダーを探索して、拡張子 tex のすべてのファイルを列挙してくれる。それが xargs を通して nkf に渡されるという仕組み。nkf のオプションは、-w でUTF8に、-Lu で行末コードをLF (UNIXの標準、今のマックもこれ)、それから –overwrite で上書きしてタイムスタンプは変えない。

それにしても・・・知識さえあれば、UNIXはかくも便利であるということですな。

投稿日:

環境変数の設定と .bashrc と .bash_profile と .profile

最近のUbuntu GNU/Linuxでは、ログイン時に .bash_profile ではなく .profile が読み込まれるらしい。実際、Ubuntu 8.04 (Hardy Heron) をインストールした直後に自分のHOMEを見たところ、.bash_profile はなかった。お勧めの使い方は .profile で .bashrc を読み込み、個人的な設定は .bashrc で行うというもの。それに従って、
export PATH = /usr/local/teTeX/bin:$PATH;
と /usr/local/teTeX/bin にパスを通している。ターミナルから which platex とかやると /usr/local/teTeX/bin/platex と表示されるので、パスが通っていることは間違いなく、実際、ターミナルからは platex hoge.tex とかでちゃんとプログラムが起動する。

ところが、エディターから platex を起動させようとすると、これが動作しない。しかたないので、フルパスを書いていた。これだと動作するのだ。今回、文字コードを判別しながら組版、PDF作成など一連の作業を行う自前の Perl スクリプトを作ったのだが、やはり system(“platex $texfile”) では platex を見つけられないようだった。仕方ないので、やはりフルパスを記述していた。

ふと思いついて、Perlが認識している環境変数を表示させてみた。スクリプトの最後に print(“PATH = $ENV{PATH}”) と書いて、環境変数PATHを表示させる。案の定、/usr/local/teTeX/bin は含まれていなかった。ううむ、何故なんだろう。

そこで、実験。試しに、直接 .profile の方に export PATH=/usr/local/teTeX/bin:$PATH; と書いてみた。おお、ちゃんとPerlも認識している。

結論。要は、見よう見まねに書いていた .profile と .bashrc あたりの設定が適切でなかったということですかね。きちんと勉強したい気もするが、そこまでの時間と余裕がない。とりあえず目的は果たしたということで、現状をメモするだけにしておこうか。

投稿日:

文字コードを判別してTeXにかけるPerlスクリプト

とある事情で、Ubuntu上ではUTF-8およびShift_JISの2種類のTeX文書を処理している。一々 platex -kanji=utf8 とか platex -kanji=sjis とか、したくないので、文字コードを判別してから組版し、ついでにPDFに変換して文書ビューアで表示させる Perl スクリプトを作ってみた。

ユーザーは自分だけなので、思いっきり手抜きだが、まずまず役立っている。

#! /usr/bin/perl -w
#
# [usage] myplatex hoge
#  hoge.tex の文字コードを判別して、platex -kanji=KANJICODE とコンパイル
#  引き続いて dvipdfmx で PDF を作り、文書ビューアー evince を起動する
#  とりあえず，普段使っている UTF-8 と Shift_JIS のみサポート

use strict;

my $basename;   # hoge
my $texfile;    # hoge.tex
my $dvifile;    # hoge.dvi
my $pdffile;    # hoge.pdf
my $kanjicode;  # UTF-8, Shift_JIS

$basename = $ARGV[0];
$texfile = $basename."\.tex";
$dvifile = $basename."\.dvi";
$pdffile = $basename."\.pdf";

open (INFILE, "<$texfile") || die "File Not Found\n";
close INFILE;

$kanjicode = `nkf -g $texfile`;
chomp($kanjicode);

if ($kanjicode eq "UTF-8") {
 system("platex -kanji=utf8 -interaction=nonstopmode $texfile");
} elsif ($kanjicode eq "Shift_JIS") {
 system("platex -kanji=sjis -interaction=nonstopmode $texfile");
} else {
 die "Not supported\n";
}

system("dvipdfmx $dvifile");
system("evince $pdffile");
投稿日:

MePoTeXで悪戦苦闘

図版を作るために、ひさしぶりにMePoTeX (LaTeXからMetapostを呼び出して使うためのマクロ集) を使ったのだが、どうも思う通りに行かず、イライラする。腹立ちまぎれ(？)に状況をメモ。

まず、Mac OS X 上では、何故か pensize が思うように変えられない。\sendMP{…} の中で pickup pencircle scaled 1.2pt などとしても線は細いまま。ええいと、3ptにしたら突然太くなる。いや、3ptは太すぎなんだってば。あれこれやっていると、ペンサイズは変えてないのに、ある場所に \mptDraw{…} と、MePoTeX の描画マクロを加えた瞬間に全体のペンサイズが変更になったり、もう訳が分からんというか、なんじゃ〜これ〜。

原因がマクロ集にあるのか、それともMacのMetapostにあるのか判断できないので、Ubuntu (Linux) 上でやってみようとするのだが、これが上手く動作せずに、これまたイライラ。ちゃんと shell escape のオプションも指定しているのに、何故か sh: mpost not found のエラーメッセージ。おいおい、パスが通ってないのかよ、と思いつつ、シェルから実行してみると、パスは通っている模様。というか、platexと同じ /usr/local/teTeX/bin/ にmpost もあるんですけどね。そういえば、エディターからlatex呼び出すときも、何故か実行ファイルを見つけられなかったことあったよなあ、と思いつつ、mepotex.sty を読んで、mpostを呼び出している部分を /usr/local/teTeX/bin/mpost と、絶対パス指定に変更してみた。いやあ、こんな乱暴、普通あり得んだろう。結果・・・ちゃんと mpost 呼び出されるじゃないすか。うーん、やっぱり、ここかあ。

しかし・・・こんな現象、いくら検索しても出てこない。ってことは、ワタシの設定が間違っている可能性が高い、と思われる。うーむ、パスが通ってるのに何故に絶対パスを記述しないとダメなんでしょうか。理由が分からない。あーイライラするなあ。

投稿日:

UNIX日本語環境でのロケール設定が分からない

差し当たって、nkf を用いてエンコーディングをシフトJISからユニコード(UTF8)に変更すればバックスラッシュ(＼)がきちんと表示される。しかし、何故にShift JISでは、たとえフォントがバックスラッシュのグリフを持っていても円記号(￥)の方が表示されるのか、その理由を知りたい。少し検索したが、断片的な情報しか得られない。とりあえず、現時点で分かったことをメモ。

まず、バックスラッシュに関係するらしきロケール(locale)の話が次のページにある。

ja_JP.UTF-8 ロケールとフォントに関する注意事項 (日本語環境ユーザーズガイド) – Sun Microsystems

ページの一番下に、具体的な設定方法が少しだけある。どうやら、それぞれのロケール設定ファイルにおいて個別のコードブロックに対応するフォントファイルを指定できるようになっているようだ。バックスラッシュは、U+005C であり、アスキー7ビット領域にあるから、この領域に対するフォントグリフの設定を修正すれば良いのかもしれない。これはSun OSのケースなので、UbuntuというかGNU/Linuxの場合はファイルの位置から違うが、これはすぐに分かった。Ubuntu 8.04 (Hardy) の場合は、当該のファイル群は
/usr/share/X11/locale/
以下にある。しかし、具体的にどう修正すれば良いのか、全く分からない。

UTF8に関するロケールは、ja_JP.UTF-8 であり、XLC_LOCALE というファイルに記述がある。ASCII部分は次のようになっている。

# We leave the legacy encodings in for the moment, 
# because we don't
# have that many ISO10646 fonts yet.
#   fs0 class (7 bit ASCII)
fs0 {
  charset {
    name  ISO8859-1:GL
  }
  font  {
    primary   ISO8859-1:GL
    vertical_rotate all
  }
}

一方、Shift JIS のロケール ja.SJIS では次のようになっている。

# 	fs0 class (7 bit ASCII)
fs0	{
	charset	{
		name		ISO8859-1:GL
	}
	font	{
		primary		ISO8859-1:GL
		substitute	JISX0201.1976-0:GL
		vertical_rotate	all
	}
}

違いは、substitute JISX0201.1976-0:GL という一行だけのようだが、これは ISO8859-1のフォントグリフの代わりに JISX0201.1976-0 のフォントグリフを使うという意味だろうか。この行をコメントアウトして無効化すれば、UTFと同じ状態になるだろうか。勝手にファイルをいじって、不都合はないだろうか。うーん、やってみる勇気がいまひとつ出ないなあ。どうしたものか・・・。