2007-08-04
_ [COMP] Mac でリモートログインメニュー
リモートログインメニューが Mac に欲しい。
Mac mini を買って 2年 4ヶ月、主たる環境を FreeBSD 上の X11 から Mac OS X に乗り換えて1年強、FreeBSD で X server を動かさなくなって半年。もう、FreeBSD のコンソール画面なんて、月に一度見るか見ないかってな状況にある。Mac OS X べったりになってずいぶん経つのに、未だに X のウィンドウマネージャーのカスタマイズ命な環境を懐かしく思うことがある。特に自前メニューが懐かしい。10年以上使い続けてる fvwm ではマウスの button-1 に自前メニューを割り当てたものだ。いや、今でも会社じゃそーゆー環境にいるんだけどね。で、リモートログインと題したサブメニューにマシンの一覧を並べ、少ないステップでリモートの xterm を立ち上げることができた。そーゆー環境が Mac にも欲しいのだ。
このリモートログイン、Mac OS X でやろうとすると手間がかかりすぎる。まず Terminal.app を起動し、ファイルメニューから「サーバへ接続…」を選択。
なにが面倒って、この「サーバへ接続…」を出すには、一旦 Terminal.app を起動しておかないといけないことだ。Terminal.app を Doc に入れただけだと、このメニューは出てこない。起動すると現れる。また、一度 Terminal.app を起動するという事は、画面の端に使いもしないローカルな Terminal.app のウィンドウが出てきてるってことでもある。Ctrl-d を叩き込んで毎回そいつを消すってのも面倒な事のひとつである。
さらに面倒なのが、ここから実際に接続できるまでが長いこと。まずサービスから ssh を選び、サーバを選び、プロトコルを選んで、ようやく接続できる。
いらつくことに、オプションリストが最初「SSH プロトコル 1」になってるところだ。毎回最初に、「SSH (自動)」か「SSH プロトコル 2」にわざわざ選び直さないといけない。手間がかかって仕方ない。
ということで、用がある場合にゃ毎度「サーバへ接続…」がこの状態になるようにセットアップする。あとは、こいつがリモートログインメニュー替りとなるわけだ。Mac にログオン後、自動でこの状態にできないものかとあれこれ検索したり試したのだが、いかんせん知識が足りな過ぎ。
Automator のワークフローに一連の作業がまとめられれば、デスクトップのコンテキストメニューから起動できて便利に使えそうなのだが、そもそも Automator のアプリには Terminal.app がリストされてない。AppleScript で、
tell application "Terminal"
などするスクリプトをあれこれ試してみるも、なにをどうやっても最初にローカルな端末が上がってきてしまうし、
do script "ssh ...
などしても、ローカルな端末のシェルから ssh してしまい、「サーバへ接続…」からやった時のように、直接リモート環境に接続するようにはならない。
もう、このあたりの事はあきらめていたのだが、ふと、Terminal.app のファイルメニューに「別名で保存…」なんてのを見つけてしまった。
いったい、これは何が保存されるのか。まぁ、結論から書くと、その Terminal.app 画面を出すのに必要な情報が xml で保存されるのだ。「サーバへ接続…」からリモートに接続した Terminal.app ウィンドウなら、リモート接続の情報も保存される。
てな状態で保存すると、
~/Library/Application Support/Terminal/
下に xml ファイル(text/plain)が保存される。保存されたものは、ファイル>ライブラリで参照できるようになる。そこから起動すると、保存した時の位置に Terminal.app のウィンドウが現れる。もちろん「サーバへ接続…」から起動したのと同じように。おお!
このままだと、一度 Terminal.app を起動しておかないといけない。「ライブラリ」メニューは「サーバへ接続…」と同様、起動してないと現れないので。
んがしかし、実フォルダがわかってるのだから、そいつを Doc に入れてしまえばいいのだ。
おお、これだよこれ。これがやりたかったのだよ。ついでに、alezo への RemoteDesktop の定義ファイルも入れてみたり。こんなことしても、Terminal.app のファイル>ライブラリには RemoteDesktop 定義が現れないのもいい感じ。
なんかこう、2年越しでやりたかったことがようやくできるようになった。ここ最近じゃ一番嬉しかったことに挙げられる。意味もなく接続して遊んでみたり。我ながらホント安いよなぁ。
P.S.
キャプチャしてて初めて気付いた。「サーバへ接続…」ダイアログを出した直後、フォーカスは一番下のコマンド欄にあたってる。下矢印があるので予想がつくと思うけど、ここに過去の履歴が残ってます。あれこれ選ばんでも、ここから一発なのでした。気づくの遅すぎ。
_ [COMP] ひとこと
sudo、1.6.9 になってから、パッチリリース出し過ぎだろう。
$ ls -l sudo-1.6.9* -rw-r--r-- 1 root wheel 557692 Jul 18 20:13 sudo-1.6.9.tar.gz -rw-r--r-- 1 root wheel 557995 Jul 26 23:06 sudo-1.6.9p1.tar.gz -rw-r--r-- 1 root wheel 558439 Jul 30 22:46 sudo-1.6.9p2.tar.gz -rw-r--r-- 1 root wheel 558517 Aug 3 00:53 sudo-1.6.9p3.tar.gz
2007-08-05
_ [Diary] こんな記念日はいらん
G を見てしまった。こたつテーブルの下から現れ、悠然と左手の壁へ向かうという、警戒心のかけらも無い行動を取ってくれたので、丸めた WOWOWマガジンで瞬殺。
このマンションに越してきて六年。二度目の遭遇である。一度目は越してきた年の夏。以後、アース製薬のホウ酸団子タイプのやつを設置するようになって、まったく見なくなった。今年も先月設置したばかり。一応、三ヶ月は効果が維持するはずなので、たぶん外から迷い込んできたんだろう。しかし、この週末は窓を締め切り、エアコン全開で閉じこもってたのに、いったいどこから…
まぁ、今までも出没はしており、単に目にする機会がなかったってだけなんだろうけどね。
_ [COMP] robots.txt でコミックリストを除外
アクセスログを眺めていて、サイドバーに出してるコミックリストが検索に引っかかってしまってることに気付いた。こりゃあいかん。他からリンクされてないからページランクはめちゃ低いはずだが、マイナーな本を検索されたらやはり目に付いてしまうようだ。
てなわけで、格納場所を変更し robots.txt を置いてみた。これでどうだ。
2007-08-08 普通それは意志薄弱と呼ばれる
_ [COMP] ようやく Core 2 duo な Mac mini が出た
ええ、ええ、ぽちっと押してしまいましたよ。メモリを 2GB にして。
いやいやいや、だって、Leopard だって控えてるんだし、PPC Mac mini じゃもう限界だもの。遅くて耐えられない。
Vista はメモリ喰いだなどと良く言われますが、なんの、絶対 Mac OS X の方がメモリを喰う。たぶん 2GB じゃスグに足りなくなるだろう。MacBook Pro にして、4GB メモリを積んだ方が快適だったに違いない。でもね、あれはやっぱり高すぎるのだ。
今回のカンファレンスの目玉は、メタルな iMac なんだろうけど、あれはいらん。どうしたって本体だけでいい。しかし、Mac mini を出してきたってことは、Mac mini と Mac Pro の間のラインナップの空白はこの先も埋まらないってことなんだろう。手乗りベースは Apple TV に任せて、Mac mini と Mac Pro の中間、能力的に MacBook Pro に相当するデスクトップマシンを出してくれんもんかのう。
しかし、本当に危ないところだった。あともう少しで MacBook Pro に手を伸ばしそうになってたところだったのだ。
ブツはお盆が開けた頃に到着する予定。今度こそ本当に予定通り届くことを願う。あぁ、しかしきっと、メモリが足りなくて後悔しそうな気がしてならない。
2007-08-15
_ [COMP] Mac mini アップデート
ブツは、盆休み明けを待つ事なく火曜に届いた。が、火曜はあれこれ別のことをやっていて開封もせず玄関に放置。今日の昼前になってようやく重い腰をどっこいせっと動かした。きっと、頭のどこかが今日のこの苦労を予想してたに違いない。
比較
結構、大切に使ってきたつもりだったんだが、新旧並べると、旧 PPC機の天板が黄ばんでるのが一目瞭然。陽に焼けそうな場所に置いちゃいなかったのに。蛍光灯焼けかなぁ。
それはともかく、TOS によるデジタル出力が嬉しい。これで、音回りで悩みが減る。Intel Mac mini が出たとき、このデジタル出力が付いたってことだけで、買い替えを真剣に考えたくらいなのだ。USB入力のある DAC なんて限られるからねぇ。
配線してて、USB 端子が増えてることが予想外に嬉しかった。今使ってる USB HUB は 7口ものという、ちょっと多めのヤツなんだけど、既に一杯になってたのだ。ACアダプタは、外見はそのままで、85W から 110W になってたりする。へ〜。これはファンが回り易いかもね。
「情報を転送する」にハマる
Mac OS X には、既存の Mac から各種情報を引き継ぐ機能がある。新しい Mac を起動すると、初期設定時に「すでに Mac をお持ちですか?」などと訊いてくるので、「別の Mac から情報を転送する」にチェックを入れて画面の指示に従えば、データを引き継げるわけだ。わけなんだが、これが何をどうやってもうまくいかない。旧 Mac mini をターゲットモードにして IEEE 1394(FireWire 400) で接続すると、きちんとそれを認識するし、ユーザー情報やらデータサイズなんかも計算する。それなのに、引き継ぎたい情報を選択して、実際の転送ステップに進むと、そこで止まってしまう。長めのプログレスバーが画面下に出てるんだが、一向に色つきバーが伸びる気配がない。気長に待ってると、新 Mac がスリープを始める始末。なんじゃこりゃ。何が腹立つって、データ転送状況を表示してるこの画面、操作をキャンセルする機能が無いのだ。仕方なく電源スイッチ長押しで強制終了してやり直す。
が、何度やっても同じである。しかも、二度目に試したときには、旧Macが起動しなくなる。うげ。久々にこの状態になった。かつてのように、エラーフォルダが点滅するんじゃなく、単に起動後のグレー画面で林檎マークが出てこない。ディスクがスピンアップしてこないってことだから、直し方は「かつて」と同じく、起動時に水平方向に揺すってやる。二三度試すとなんとか起動。やれやれ。
バックアップは大事だよ
「別の Mac から情報を転送する」でだめなら、外付けディスクをつないで「この Mac 上の別のパーティションから情報を転送する」ならどうよ? てなわけで、一旦、外付けディスクに旧機からデータを丸ごと退避し、新機につなぎ直してそこから読み込ませてみることにする。ただ、ターゲットモードになっているということは、Mac 自体が IEEE 1394 接続の外付けディスクと同じになってるってことだから、「別の Mac から」がダメなら「この Mac 上の」でもダメなわけだが、この時点ではまだその事を知らなかったのだ。
まぁ、それはそれとして、どのみち、一旦バックアップとして、外付けディスクにデータを吸い出しておきたかったのだ。それも rsync -E ではなく、ディスクユーティリティの復元機能を使う正式なやり方で。
このバックアップには dTwin MIFC-D800 という外付けディスクを使う。こいつのファンは温度センサー無しの回りっぱなしタイプ。しかもディスクがスリープで止まっていても回り続けるウルサいやつなので、miniStack V2 購入後は、バックアップ以外の用途で使われる事が無く、しかも、うるさいファンのケーブル抜いて、スリープ状態のまま最近まで放置してた。ここんとこの猛暑でさすがに電源も落としたけど、忙しさにかまけてバックアップはしておらず、たぶん半年以上稼働実績が無いという代物。予想通り、なんか調子がおかしい。ディスクユーティリティで検証するとエラーになる。修復にも失敗する。おいおい、このクソ暑いときに秋葉なんぞにゃ、絶対行きたかねえぞ。ダメ元で 0-fill でデータ消去を試してみる。
0-fill にかかる時間が1時間半と出たので、「かんなぎ」を一巻から読み返す。いやぁ、二巻って買ってたけど読んでなかったや。実のところ、ジオブリーダーズの展開にも付いてけてなくなってるんだけど、あれは 11巻以降は本棚になく、どこに積まれてるのか探すのが大変なので、放置状態。
おかしいのはディスクなのか、PPC Mac mini なのか
予想に反してエラーもなく 0-fill 消去は完了した。かんなぎも読み終わった。
ではでは、と、あれこれ弄り回すと、OS 自体の反応が遅くなり始めた。最初はディスクユーティリティだけが遅い、つうか不具合によってディスクの反応が遅いので、それにつられてディスクユーティリティも遅くなってるんだと思ってたんだが、他のアプリ操作も遅い。この外付けディスクは、250GB のディスク二発を MIFC-D800 のストラインピング機能で 500GB にしてある。この 500GB をパーティション分割で 80GB + 残りにし、80GB の方に Machintosh HD ヴォリュームを、残りに miniStack に置いてある iTunes のデータを退避するつもりだったのだ。が、あまりの遅さに根負け。とりあえず、再起動を仕掛けてみる。レスポンス悪化についてもかつて経験済みで慣れたものである。Finder のメニューがでてくるまで 5分もかかる。CPU や メモリの使用量は超低空なのに。かたつむりのような歩みでじわじわと再起動が進行してく。
やはり、更新の気配を感じ取って抵抗してるんだろうか?
再起動が終わったところで外付けディスクを切り離し、ジャンパを操作してストライピングを止め再接続。250GB 二発のヴォリュームのまま使う事に。きっとおかしいのはディスクの片方だけ。根拠無くそう信じる。
さて、いつの間にやら、250GB(実容量 233GB)ぽっちでは、iTunes のデータ は格納できなくなっておりまして、iTunes データのバックアップは今回は断念。涼しくなったら、ディスクを買って来よう。あいや、miniStack V2 をもう一台の方がいいか。
艱難辛苦は続く
どちらかのディスクに爆弾があるはずだけど、とりあえず格納エリアは確保したので、OS のインストールメディアからブートする。ディスクユーティリティによる「復元」を使ったデータコピーでは、起動ディスクは復元できないので、別の場所からブートする必要があるのだ。が、なんと旧Mac が DVD を認識しない。認識っつーか、スロットインなドライブがメディアを吸い込まない。センサーが壊れたか? さっき揺すったのがマズかったのか? ううむ。
仕方が無いので、かつて miniStackV2 を起動ディスクにしてた頃のパーティションからブートする。起動ディスクを選択する時点で、OS のマイナーバージョンが 2つほど古いことに気づく。予想通り、上がってきたとたんにソフトウェアアップデートせいと叱られる。あれこれと足踏みもしたけど、ようやくディスクユーティリティによる「復元」に辿り着く。えいやで選んだ MIFC-D800 の Disk2、たぶんスレーブ側のディスクへの復元は 一時間ほどで正常に終了。その後の検証でも問題なしと出た。 悲しいかな、今日の作業で最初に成功したステップがこれだったりするんだけど、こんな程度で気を良くして、「情報を転送する」に再挑戦。いや、敗北しましたけどね。理由はもう上に書きましたな。あれこれ調べて、ターゲットモードが何者かを知り、脱力。
普通にインストール
情報の転送はあきらめました。「情報を転送しない」にチェックを付けて初期設定作業を進める。Apple ID を入力すると、住所やらといった個人情報が表示されたのにはビックリ。これはどこから?
ローカルアカウントは管理者用だけを作成。ほんとなら、ここでマシンのレスポンスの良さを楽しめたんだろうけど、ここに辿り着くまでに疲れ果てていて、そんな余裕は有りまへん。機械的にネットワーク回りの設定などをしていく。ふと魔が差して、ユーティリティフォルダにある移行ユーティリティを試す。これは「情報の転送」をおこなうユーティリティだ。いや、これがまたあっさりとうまくいったのだ。なんにも期待してなかったのに。ちょっとブチ切れかける。
ここまでの苦労はなんだったんだあああああ。
移行ユーティリティによるデータ移行と Doc 情報
なんか簡単やねと、移行したばかりの自分のアカウントでログオンしてみる。なんと、SSHKeyChain が起動してくる。なぜ? Doc にいれてある iPhoto を起動する。あれ? バージョンが古い。iPhoto '08 のウリである「イベント」が出てこない。Safari や Mail を Doc から起動すると、なんと右端にもひとつ Safari やらのアイコンが現れてそっちがアクティブになる。これはいったい…
ここで気づいた。Doc に格納してあるアプリは、すべて古いアプリを指している。具体的には、情報の転送元にした外部ディスク内のアプリを指しているのだ。だから、まだインストールしてない SSHKeyChain だとかが起動してくるし、外付けディスクを unmount しようとしても Device Busy となってしまう。つうことで、Finder と DashBoard 以外を Doc から一旦すべて削除して、ローカルディスクのアプリケーションフォルダから入れ直した。しかし、移行ツールがこんなんじゃ、素人さんには使えないんじゃなかろうか?
うん、やっぱり速い
PPC Mac mini では遅くて仕方なかった iPhoto が速い。DashBoard もサクっと上がって来る。メモリも 2GBでなんとかなってくれている。ほっと一息。
iPhoto のスライドショーがきちんと 1920x1200 を使ってくれる。細かいことだが、これが結構嬉しい。ただしこれは iPhoto が '08 になったからじゃない。Doc の整理をする前に間違えて起動した古い iPhoto でもそうだった。Intel Mac mini になったから直ったのだ。なんでそんなことにこだわるかっつーと、PPC Mac mini でスライドショーを実行すると、画面解像度が 1024x768 くらいに小さくなっていた。画面が小さくなると、画面内のウィンドウが自動的に再配置される。こうなると、基準点から離れた位置に配置されていたアプリが、左上に寄ってしまったり、ウィンドウサイズが小さくなってしまったりする。左下隅とか右下隅に小さめのアプリを並べる使い方をしたい者としては、勝手にウィンドウの位置が狂うのは嫌なのである。それが、新しい環境では画面サイズが変化しないので、再配置もされなくなったのだ。 そうか、悪いのは、PPC Mac mini のグラフィックカードだったのか。iPhoto がお莫迦なんだと思ってたよ。嬉しくなって InterfaceLIFT とかから集めた 1920x1200 以上あるデスクトップ画像用のスマートアルバムなんぞを、適当な曲付けてスライドショーさせてみる。なかなかの弩迫力。読書の BGV には向かなさそうだけど。
あと、2ch で見かけた、YouTube で全画面再生するとファンがガンガン回ってウルサくて話にならん、ってな情報。気になってて自分でも試してみる。デマでしたね。全然回りません。静かです。ホッ。
まぁ、そんなこんなで、移行が終わって数時間、あれこれ試しておりました。意味もなく DashBoard のウィジェットを追加して、波々エフェクトを楽しんだり。PPC Mac mini からすると、二倍といっていいくらいの速度も感じられるんですが、きっとスグに慣れてしまうんだろうなぁ。
さて。これで Leopard がいつ来ても大丈夫。秋が楽しみじゃ。
追記
Carbon Emacs をようやくインストールしたので、ちょこっと書き直し。
2007-08-17
_ [COMP] Mac OS X のバックアップ
以前にもあれこれ調べ、
- USB 接続の hp DAT72 装置を Mac mini は認識してくれないこと
- dump が HFS+J のリソースフォークをサポートしないこと
に落胆してる。
それでもテープにコピりたいので考える。が、こう暑くては何も浮かばないので、楽な方法に落ち着こう。手間がかかるので、定期的にできそうにないのが困りもんだが。
- 起動ディスクのディスクイメージ(dmgファイル)を外部ディスクに作成
- できたディスクイメージを、リモートに接続した DAT に tar で吸い上げ
いいじゃん、もうこれで。
ディスクイメージの作成
まず、先日外部ディスクに「復元」機能で作成した、PPC Mac mini のバックアップをディスクイメージに変換してみる。
sudo hdiutil convert /dev/diskXsNN -format UDBZ -o どこか/PPC-Mac-mini.dmg
てな感じかな。man を見てて、コマンドラインからなら bzip2 圧縮(UDBZ)が選択できることを発見。たぶん、ディスクユーティリティからの圧縮指定だと zip圧縮(UDZO)相当になると思われる。さて、UDBZ フォーマットで作った dmg ファイルからを、ディスクユーティリティは扱えるんかな? まぁ、扱えなくても、hdiutil 使えば戻せるわけで、心配はいらないけども。あと、/dev/diskXX といったデバイス名は、mount の出力から引いて来る。
$ mount /dev/disk0s2 on / (local, journaled) devfs on /dev (local) fdesc on /dev (union) <volfs> on /.vol automount -nsl [120] on /Network (automounted) automount -fstab [168] on /automount/Servers (automounted) automount -static [168] on /automount/static (automounted) /dev/disk1s10 on /Volumes/miniStack (local, nodev, nosuid, journaled) /dev/disk5s10 on /Volumes/disk2s10 (local, nodev, nosuid, journaled) /dev/disk6s10 on /Volumes/PPC Macintosh HD (local, nodev, nosuid, journaled)
たぶんデバイス名でなく mount ポイントでもよさげだけど、Machintosh HD みたく SPC が入ったりするから、だいたいにおいて、デバイス名の方が楽。
実行すると、アクティビティモニタのフローティング CPU メーターが 2列とも 100%に貼り付きます。top で見るとこんなだ。
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 5217 hdiutil 168.4% 37:02.29 9 58 93 17.8M- 1.20M 23.1M- 69.3M
わはははは。そうか、100% を超えるのか。
$ date; sudo hdiutil convert /dev/disk6s10 -format UDBZ -o /Volumes/disk2s10/PPC-Mac-mini.dmg; echo return code: $?; date Fri Aug 17 15:46:51 JST 2007 イメージ作成エンジンを準備中... “ディスク全体 (Apple_HFS : 0)”を読み込み中... ............................................................................... (CRC32 $D63C4EC1:ディスク全体 (Apple_HFS : 0)) リソースを追加中... ............................................................................... 経過時間: 1h 42m 29.103s ファイルサイズ:27655390208 バイト、チェックサム:CRC32 $8D93B500 処理されたセクタ数:489970768、77131209 圧縮されました 速度:6.1M バイト/秒 節約率:89.0% created: /Volumes/disk2s10/PPC-Mac-mini.dmg retuen code: 0 Fri Aug 17 17:29:28 JST 2007 $
げげん。二時間弱もかかってるし。ここから tar で吸い上げるのでも二時間はかかるだろうに。ちなみに、LANG 関連は一切設定してません。hdiutil が勝手に日本語を喋ってるのです。
tar で吸い上げ
さて、tar は tar で、いろいろある。Mac OS X の tar は GNU tar。なら、--rsh-command=ssh で rmt が使えるはず。
$ cd /Volume/disk2s10 $ tar --rsh-command=ssh -cf kamui.mob.or.jp: PPC-Mac-mini.dmg tar: Cannot execute remote shell: No such file or directory tar: kamui.mob.or.jp?:: Cannot open: Input/output error tar: Error is not recoverable: exiting now
あれ?
$ tar --rsh-command=ssh -cf kamui.mob.or.jp:/dev/sa0 PPC-Mac-mini.dmg tar: Cannot execute remote shell: No such file or directory tar: kamui.mob.or.jp?:/dev/sa0: Cannot open: Input/output error tar: Error is not recoverable: exiting now
フルパスかよ。
$ tar --rsh-command=/usr/bin/ssh -cf kamui.mob.or.jp:/dev/sa0 PPC-Mac-mini.dmg bash: /usr/libexec/gnurmt: No such file or directory tar: noroi@kamui.mob.or.jp?:/dev/sa0: Cannot open: Input/output error tar: Error is not recoverable: exiting now
なんじゃこりゃ?
$ strings /usr/bin/tar | grep rmt /etc/rmt rmt-command --rmt-command=COMMAND use given rmt COMMAND instead of /etc/rmt /usr/libexec/gnurmt
おいおい、嘘をつくなよ。/etc/rmt じゃなくて /usr/libexec/gnurmt が埋め込まれてんじゃんか。んじゃ、こうだ。
$ date; tar --rsh-command=/usr/bin/ssh --rmt-command=/etc/rmt -cf kamui.mob.or.jp:/dev/sa0 PPC-Mac-mini.dmg; date Fri Aug 17 17:32:13 JST 2007 Fri Aug 17 21:02:51 JST 2007
三時間半ですか。ちょっとかかりすぎでは。一応、GbE な環境なんだがなぁ。
とまぁ、こんな感じでできることはわかった。5時間半もかかる作業を、定期的に実行するとは思えんけどね。
2007-08-24
_ [COMP] Mac OS X でのスクリーンキャプチャの方法
すぐに忘れるのでメモ。
- command + shift + 4 で、領域選択カーソルを出す。
- space 押下で、ウィンドウ選択に切替。
- キャプチャしたいウィンドウを選び、クリック。
グラブでのウィンドウキャプチャとは、
- アクティブ状態のキャプチャが採れる。
- マウスポインタが入り込まない。
という 2点が違う。
グラブでアクティブなウィンドウをキャプチャするには、タイマー機能で画面全体をキャプチャし、切り出すしかない。これだと、タイトルバー端の丸まってる部分を透過させたりと面倒。そもそもグラブでキャプチャした画像は tiff でしか出力できないので、後処理は必須。
ってことで、マウスポインタを入れ込みたい時にくらいにしか、グラブって使いものにならんのだが、すぐにその事を忘却してしまうんだよな。さて、このメモを書いた事は覚えていられるだろうか。
追記 2008.02.19
Leopard になってからなのか、10.5.2 になってからなのか不明だけど、ウィンドウキャプチャすると、影込みでキャプチャされるようになった。2ch 情報によれば、command + shift + 4 をすると
/usr/sbin/screencapture -id -tpng /Users/oxon/Desktop/ピクチャ 1.png
が SystemUIServer から起動されるらしい。man screencapture によれば、
-o In window capture mode, do not capture the shadow of the window.
なので、SystemUIServer が screencapture の実行時に -o を付けてくれれば良い。これは、
defaults write com.apple.screencapture "disable-shadow" -bool TRUE killall SystemUIServer
とすることによって実現できるとのこと。
2007-08-27
_ [COMP] 電源ケーブルの端子の並び
これまた備忘録。
普通の PC に付いて来る電源部のコネクタは IEC 60320 C14 というタイプである。うちで使っているテーブルタップは NEMA 5-15R というやつなので、ケーブルは NEMA 5-15P/IEC 60320 C13 という組み合わせになる。まぁ、両端が 3P のふつーのヤツである。以下、これを 3P-3P と呼ぶ。
ところが、今使っている PC 群に付いて来る電源ケーブルのプラグ側が、どれもこれも 2P(NEMA 1-15P) + アース線という、一番キライなパターンなので、お気に入りであるケーブル長が 50cm しかない3P-3P のものに交換して使っている。
が、交換できないものもある。それが Mac mini についてくるケーブルだ。ソケット側が IEC 60320 C5、いわゆるメガネ型3P なのである。ソケット側がメガネ型3P(IEC 60320 C5) でプラグ側が 3P(NEMA 5-15P) のケーブルって未だ見た事がない。たぶん出回っていないと思われる。
あのアース線、ぶらぶらしてて危険なのだ。最近、金属端子部分がビニールで覆ってあるのが増えたとはいえ、少なくとも Mac mini に付いて来るのには覆いがない。
IEC 60320 C5 がついてる電源ケーブルを買ってきて、プラグ側をNEMA 5-15P に差し替えちゃえばいいんだけど、NEMA 5-15P のプラグって、単体で売ってるのって、えらくゴツくて高いのだ。仕方が無いので、こんなアダプターを買ってくることになる。
逆パターンはよくそこらで売っているけど、こいつはやっぱ専門店とかでないと見当たらない。
で、気になるのが、2Pプラグの極性である。交流だし、アースを取るなら気にするこたあないのだが、電気工事レベルでは、3線は厳密に区別されていることを知っている以上、気になってしまうのだ。
で、ここで 3P-3P(NEMA 5-15P/IEC 60320 C13) の電源ケーブルはどうなっているかを見てみる。サンプルは、いつも使っている長さ 50cm の電源ケーブル。
刻印が、プラグ側とソケット側で違うのがわかる。規格が違うからだ。プラグ側(NEMA)で W(hite) と刻印されてる極が、ソケット側(IEC)で N(eutral) と刻印されてる極に結線されている。G(round) はもちろんアース記号と。
この配置にむちゃくちゃ違和感を覚える。普通プラグとレセプタクルを並べると、左右が対称になりそなものなのに。まぁ、規格が違うんだから仕様がないんだけど。
ソケット側メガネタイプの 3P-2P のケーブルだとこんなだ。
プラグ側に極性の刻印がないけど左が W だ。刻印に正対して左が W であることが多い。または、アース線が出てる側が W。実は、このケーブル、自作しようと買ってきたもの。けど作らなかった。プラグがゴツかったのと、白いのが手に入らなかったからとか、そういういい加減な理由だったり。
ちなみに、Mac mini に付いて来るケーブルだとこうだ。
こういう、ソケット・プラグ共に極性の刻印の無い 2P ものはどうやって見分けるか。調べた結論からいうと左が W だった。ここでも、刻印に対して左で、アース線が出てる側というのが当て嵌まっているんだけど、正しくは調べなきゃ。ソケット側が 3P なのだからここから判断できる。IEC 60320 の C13 も C5 も(ともにケーブル側アウトレット) 、端子の並びが山型になるように見たとき、左側が Neutral になる。あとはプラグ側との結線状態はテスターで調べればいい。
ここまでわかれば、プラグに W と刻印のある方を、コンセントの
- 長い方
- Wと刻印のある方
に合わせてやればいい。今回のアダプタの形状はこうなってる。
NEMA 規格なら W、G と刻印がありそうなものなんだけど、N、アース記号で掘られてますな。まぁ、わかるからいいけど。