Amazonマーケットプレイスに出品している「ZOverstocksJPN」で標記のCDを買いました。元祖「Hooked on Classics」は当初LPで、後にCDで買い直して持っています。関連CDも気が付いたら買うようにしていたのですが、このCDは実は知りませんでした。届いたCDを見ると(C)1999とありますから、もう20年ほど前の発売ですね。
存在を知ったきっかけはYouTubeです。CDを入手したいと思いましたが、既に新品としては日本国内では流通していないようでした。諦めかけたのですがAmazonならば中古CDとして入手できるようです。演奏しているのがThe Royal Philharmonic Orchestraというイギリスの楽団なので、出品業者もイギリスの「ZOverstocks」を選んでみました。
今月9日に注文して、今月13日から28日の間に到着予定とありましたから、だいたい予定通りですね。ただし気になったのは、発送元がイギリスと思われるので、Amazonに登録されている宛先が日本語のままで大丈夫だろうかという点でした。結論からすると大丈夫でした。宛名ラベルは日本語の住所氏名が印刷されていましたが、最後に「JAPAN」とあるので、イギリス国内では日本語が読めなくても日本向けのコンテナに積み込まれるように手配されるのだと思います。
ZOverstocksというのはマンチェスター近郊にある会社のようです。住所はそうなっていました。
これまでの海外から古本を買った経験もありますが、場合によっては届くまで2カ月以上も待たされたりしました。それに比べると今回は順調でした。
もうすぐクリスマスです。良いクリスマスプレゼントになった気がします。
2017-12-21
FORFILES.EXEがエラーを出す
日常的に利用しているWindows10の%HOMEPATH%\Documentsのファイル群をdynabook SS SX/15A上に構築しているNetBSD/i386の~/Documentsに同期させる仕組みを構築するために、Windows10側でFORFILES.EXEを利用することにしていました。うまくいくと思いましたが、エラーが出てくるようになってしまいました。
処理中に「エラー: パラメーターが間違っています。」 というメッセージが出て、処理が中断してしまいます。この「パラメーター」というのはコマンドラインオプションの事ではないと思います。では何の「パラメーター」なのか？それが不明なのが困ったところです。これ以上の情報が無いので、何がどのように「パラメーターが間違ってい」るのか、さっぱり分かりません。
エラーを解決する方法が不明なので、代替策を検討する必要があります。当初の目的に立ち返ることにしましょう。そもそもの発想の原点は、Windows10側で更新されたファイルリストを生成させておくという事でした。UNIXであればfindを使うのが素直な解決策だと思いますが、Windows流儀ではどうすれば良いのでしょうか。Win32用に移植されたfind.exe（Windowsには昔からFIND.EXEという名前の、UNIXで言うところのgrepのようなプログラムがありますが、そのことではありません）が見つかれば良いかもしれません。またはCygwinのような環境を構築しておくという方法もあるでしょう。しかし、どうも気が進まないのです。「鶏を割くに焉んぞ牛刀を用いん」と言うか、「木に竹を接ぐ」と言うか、違和感があるのです。
Windows10のFall Creator UpdateからはWSLが利用できるようになりました。WSL内でWindowsのプログラムを起動させることができるようなのですが、逆はどうなのでしょうか？試しに簡単なシェルスクリプトを書いて、Windows側から起動させてみたところ、%SystemRoot%\System32\wsl.exeを使えば、シェルスクリプトを起動できることが分かりました。
しかし問題があって、wsl.exeに渡すファイル名は、WSL環境が理解できるパスになっている必要があるのです。つまり、例えば「C:\Users\FOO\BAR」であれば 「/mnt/c/Users/FOO/BAR」と指定する必要があるのです。またWSLは一応UNIXですので、ファイル名の文字種（大文字と小文字）の違いにも意識する必要があります。
結局、簡単なWindows用スクリプトを介してwsl.exeを使うことにしました。以下の内容を含むcmdファイルを作って使うことにしました。
考えてみるとWSLというのは不思議な世界です。Windows上でUNIX環境が動くのですが、過去に存在した如何なるものとも違うのです。Win32用バイナリを探してU*IX-likeな環境を作るのとも違うし、Cygwinの環境とも違い、またVirtualBoxなどで仮想環境にU*IX系OSをインストールした環境とも違います。使い道は個人個人で異なるとは思いますが、WSLには可能性を感じます。
処理中に「エラー: パラメーターが間違っています。」 というメッセージが出て、処理が中断してしまいます。この「パラメーター」というのはコマンドラインオプションの事ではないと思います。では何の「パラメーター」なのか？それが不明なのが困ったところです。これ以上の情報が無いので、何がどのように「パラメーターが間違ってい」るのか、さっぱり分かりません。
エラーを解決する方法が不明なので、代替策を検討する必要があります。当初の目的に立ち返ることにしましょう。そもそもの発想の原点は、Windows10側で更新されたファイルリストを生成させておくという事でした。UNIXであればfindを使うのが素直な解決策だと思いますが、Windows流儀ではどうすれば良いのでしょうか。Win32用に移植されたfind.exe（Windowsには昔からFIND.EXEという名前の、UNIXで言うところのgrepのようなプログラムがありますが、そのことではありません）が見つかれば良いかもしれません。またはCygwinのような環境を構築しておくという方法もあるでしょう。しかし、どうも気が進まないのです。「鶏を割くに焉んぞ牛刀を用いん」と言うか、「木に竹を接ぐ」と言うか、違和感があるのです。
Windows10のFall Creator UpdateからはWSLが利用できるようになりました。WSL内でWindowsのプログラムを起動させることができるようなのですが、逆はどうなのでしょうか？試しに簡単なシェルスクリプトを書いて、Windows側から起動させてみたところ、%SystemRoot%\System32\wsl.exeを使えば、シェルスクリプトを起動できることが分かりました。
しかし問題があって、wsl.exeに渡すファイル名は、WSL環境が理解できるパスになっている必要があるのです。つまり、例えば「C:\Users\FOO\BAR」であれば 「/mnt/c/Users/FOO/BAR」と指定する必要があるのです。またWSLは一応UNIXですので、ファイル名の文字種（大文字と小文字）の違いにも意識する必要があります。
結局、簡単なWindows用スクリプトを介してwsl.exeを使うことにしました。以下の内容を含むcmdファイルを作って使うことにしました。
set CMDPATH=%~pnx1WindowsからWSLのシェルスクリプトを呼び出すことにすれば、堂々とfindを使うことが出来ます。これで同期対象ファイルのリストを生成させられれば、後はNetBSD側でリストを読んで、対象ファイルをコピーするだけです。その仕組みは従来と同じなので、たぶん大丈夫でしょう。
wsl /mnt/c%CMDPATH:\=/%
考えてみるとWSLというのは不思議な世界です。Windows上でUNIX環境が動くのですが、過去に存在した如何なるものとも違うのです。Win32用バイナリを探してU*IX-likeな環境を作るのとも違うし、Cygwinの環境とも違い、またVirtualBoxなどで仮想環境にU*IX系OSをインストールした環境とも違います。使い道は個人個人で異なるとは思いますが、WSLには可能性を感じます。
2017-12-17
iMacrosの代替はseleniumが良さそう
Firefox57で動作しなくなったiMacrosの代替として、wildfireとseleniumが候補にあがりました。まずwildfireをインストールしてみました。簡単に使えるという触れ込みでしたが、iMacrosで簡単に出来ていたことが、うまくいきません。
Web操作の記録はできているようなのですが、それを再生しても、意図したようになりません。別に難しい操作をしたわけでもないのですが、それなのに再生が上手くいかないようでは、先が危ぶまれます。wildfireは却下しようと思います。
次にseleniumもインストールしてみました。こちらは見た目はwildfireよりも地味でiMacrosに似ている気がします。使ってみた感じでは、Web操作が再現できています。このままseleniumでiMacrosと同じことが全て出来るのか不明ですが、可能性はありそうです。
結局iMacrosの代替にはseleniumを使っていこうと思います。
Web操作の記録はできているようなのですが、それを再生しても、意図したようになりません。別に難しい操作をしたわけでもないのですが、それなのに再生が上手くいかないようでは、先が危ぶまれます。wildfireは却下しようと思います。
次にseleniumもインストールしてみました。こちらは見た目はwildfireよりも地味でiMacrosに似ている気がします。使ってみた感じでは、Web操作が再現できています。このままseleniumでiMacrosと同じことが全て出来るのか不明ですが、可能性はありそうです。
結局iMacrosの代替にはseleniumを使っていこうと思います。
2017-12-16
iMacrosの代替アドオン候補
Firefox57から旧式アドオンが動かなくなりました。これまで使っていたiMacrosが使えなくなってしまいました。
iMacrosというのはWeb操作を自動化するものです。例えば近所の図書館のOPACを自動的に巡回して書籍を検索するときなどに利用していました。
iMacrosはFirefox57に対応させる予定がないようです。そうなると代替アドオンを探さなければなりません。調べてみるとwildfireとかseleniumというのが見つかりました。どちらも昔からあるアドオンですが、これらはFirefox57にも対応しているようです。
Webの記事を読んでみるかぎりでは、wildfireの方がseleniumよりも「使いやすさ」を強調したつくりになっているようです。seleniumというのは（あえて言えば）プロ向けという感じでしょうか。
あまり凝ったことをするつもりはありませんが、以前にiMacrosで出来ていたことは最低限できて欲しいと思っています。もしwildfireで出来るなら、それで良し。wildfireで出来なくても、seleniumで出来るなら、それでも良し、というところです。
まずはwildfireから使ってみようかと思います。
iMacrosはFirefox57に対応させる予定がないようです。そうなると代替アドオンを探さなければなりません。調べてみるとwildfireとかseleniumというのが見つかりました。どちらも昔からあるアドオンですが、これらはFirefox57にも対応しているようです。
Webの記事を読んでみるかぎりでは、wildfireの方がseleniumよりも「使いやすさ」を強調したつくりになっているようです。seleniumというのは（あえて言えば）プロ向けという感じでしょうか。
あまり凝ったことをするつもりはありませんが、以前にiMacrosで出来ていたことは最低限できて欲しいと思っています。もしwildfireで出来るなら、それで良し。wildfireで出来なくても、seleniumで出来るなら、それでも良し、というところです。
まずはwildfireから使ってみようかと思います。
計算機プログラムの構造と解釈
『 計算機プログラムの構造と解釈』（原題：Structure and Interpretation of Computer Programs、略称：SICP）という計算機科学の分野における名著があります。存在は以前から知っていて、図書館で何度か手にしたこともあるのですが、今一つ興味がなく終わっていました。
ただし評判が良いことも承知していて、Webを検索すれば関連情報がたくさん見つかります。簡単に読める本ではないようですが、読み終えれば達成感はあるようです。
日本語訳も書籍として出版されています。2000年にピアソンエデュケーションから出版された『計算機プログラムの構造と解釈 第二版』と2014年に翔泳社から出版された『計算機プログラムの構造と解釈 第2版』があります。漢数字の「第二版」というのは（紛らわしいですが）原著の2nd editionが底本という意味のようで、日本語版としては初版です。
ありがたいことに公式サイトではテキストを無料で読むことが出来ます（英文ですが）。また非公式の和訳も何種類かあるようです。コンピュータ関連の洋書について「和訳を読むくらいなら（訳が変だから）原著を読んだ方がマシだ」とよく言われます。非公式な和訳が何種類もあるのも、そのためのようです。それは一面の真理ではあると思いますが、（変な和訳だったとしても）日本語で読める方が有り難いのは確かです。
この本ではLISP（というかScheme）が例示として使われています。原著が書かれた時代背景もあるでしょうが、Cとか（最近大流行のPythonとか）が使われている訳ではないので、手っ取り早く（CやC派生言語の）プログラミング能力をあげる役には立たないでしょう。しかし本文をよく読んで、練習問題にも取り組めば、縁の下の力持ち的に役立ちそうな予感がします。
いろいろな事に手を出しているので、これに集中できるわけではありませんが、ライフワークとして取り組んでみようと思います。
ただし評判が良いことも承知していて、Webを検索すれば関連情報がたくさん見つかります。簡単に読める本ではないようですが、読み終えれば達成感はあるようです。
日本語訳も書籍として出版されています。2000年にピアソンエデュケーションから出版された『計算機プログラムの構造と解釈 第二版』と2014年に翔泳社から出版された『計算機プログラムの構造と解釈 第2版』があります。漢数字の「第二版」というのは（紛らわしいですが）原著の2nd editionが底本という意味のようで、日本語版としては初版です。
ありがたいことに公式サイトではテキストを無料で読むことが出来ます（英文ですが）。また非公式の和訳も何種類かあるようです。コンピュータ関連の洋書について「和訳を読むくらいなら（訳が変だから）原著を読んだ方がマシだ」とよく言われます。非公式な和訳が何種類もあるのも、そのためのようです。それは一面の真理ではあると思いますが、（変な和訳だったとしても）日本語で読める方が有り難いのは確かです。
この本ではLISP（というかScheme）が例示として使われています。原著が書かれた時代背景もあるでしょうが、Cとか（最近大流行のPythonとか）が使われている訳ではないので、手っ取り早く（CやC派生言語の）プログラミング能力をあげる役には立たないでしょう。しかし本文をよく読んで、練習問題にも取り組めば、縁の下の力持ち的に役立ちそうな予感がします。
いろいろな事に手を出しているので、これに集中できるわけではありませんが、ライフワークとして取り組んでみようと思います。
2017-12-14
Windows10 1709 (Fall Creator Update)のWSLにはtcshが無い
Windows10 1709（Fall Creator Update）ではWSL（Windows Subssytem for Linux）が標準機能になりました。以前には「Bash on Ubuntu on Windows」という扱いでしたが、今はUbuntuには限定されていません。Windows10の更新が始まる前にBoWをアンインストールして準備を整えておきました。
つい最近になって、ようやく機能更新の順番が回ってきたようで、ついに1709版になりました。そしてWSLを使ってUbuntuも使えるようにしました。Microsoft StoreではOpenSUSEなども選べるのですが、どのディストリビューションにも拘りがない（つまりどれでも構わないということ）ので、最も人気があると思われるUbuntuにしておきました。
インストールには「「Windows Subsystem for Linux(WSL)」セットアップガイド【スクリーンショットつき解説】」を参考にしました。 インストール自体は簡単で、Microsoft StoreでUbuntuを選んだあと、ダウンロードに数分、ダウンロード後の起動時に初期化で数分というところでした。
ここまででインストールは完了ですが、追加的に以下の対応をしておきました。
しかもtmuxとかscreenも入っているのは初めて目にしました。以前はtmuxを使っており、今はscreenを使っているのですが、これらを/etc/shellsに指定するとは知りませんでした。
つい最近になって、ようやく機能更新の順番が回ってきたようで、ついに1709版になりました。そしてWSLを使ってUbuntuも使えるようにしました。Microsoft StoreではOpenSUSEなども選べるのですが、どのディストリビューションにも拘りがない（つまりどれでも構わないということ）ので、最も人気があると思われるUbuntuにしておきました。
インストールには「「Windows Subsystem for Linux(WSL)」セットアップガイド【スクリーンショットつき解説】」を参考にしました。 インストール自体は簡単で、Microsoft StoreでUbuntuを選んだあと、ダウンロードに数分、ダウンロード後の起動時に初期化で数分というところでした。
ここまででインストールは完了ですが、追加的に以下の対応をしておきました。
- タイムゾーンをJSTに変更
- パッケージを最新に更新
- 端末画面のフォントが見難いので「Source Code Pro Light」の18ポイントに変更
# /etc/shells: valid login shellsなんとtcshがありません。自分でtcshを入れなければならないようですね。
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/usr/bin/tmux
/usr/bin/screen
しかもtmuxとかscreenも入っているのは初めて目にしました。以前はtmuxを使っており、今はscreenを使っているのですが、これらを/etc/shellsに指定するとは知りませんでした。
2017-12-09
Can't translate pathname 'path/to/the/file/foo.bar' to UTF-8:
20年位前のノートPCにFreeBSD/i386を入れて利用してきましたが、さすがに旧過ぎるので問題を感じています（ハードウェア的な問題という訳でもないのですが）。ジャンクでThinkPad Edge 530cを入手したので、FreeBSD/amd64の環境に移行しようと作業を進めています。
OSやアプリケーションを入れるのは、特別に難しいことではありません。問題は以前のマシンに置いてある長年蓄積されたファイルをコピーする方法です。外付けHDDを仲介する方法もあると思いますが、LANを使ってネットワーク越しにコピーしようと思います。NFSでマウントしておきさえすれば、普通のコマンドでコピーできるでしょう。
まず試したのがtarを使う方法です。普段から一括コピーする場合はtarを利用することが多いのです。注意したのはロケールです。ファイル名に日本語を使っているところもあるので、余計な処理がおこなわれないようにするためCロケールにしておきました。
ところが標記したようなメッセージが大量に出てくるのです（何故？）。Webを検索してみると「TARコマンドのCan't translate pathnameメッセージ 」という情報を見つけました。 やはりロケールには注意しなければいけないようですが、Cロケールにしたのに何故「Can't translate pathname ～ to UTF-8」というメッセージが出てくるのでしょうか。
このようなメッセージが出てきたとしても、コピー自体は出来ているのか、それとも失敗しているのか、何分にもメッセージが大量に出るので個々に確認していられません。
tarを使うのを諦めて、rsyncを使ってみました。こちらは妙なメッセージが出ることも無く、スッキリと転送されました。rsyncはFreeBSDに標準的に入っているコマンドではありませんが、うまくいくのであればrsyncにしようと思います。
tarを使って転送した場合には39時間ほどかかりましたが、rsyncでは37時間あまりでした。rsyncの方が心持ち速いようですが、劇的に速くなるわけでもなく、ほとんど誤差の範囲です。
OSやアプリケーションを入れるのは、特別に難しいことではありません。問題は以前のマシンに置いてある長年蓄積されたファイルをコピーする方法です。外付けHDDを仲介する方法もあると思いますが、LANを使ってネットワーク越しにコピーしようと思います。NFSでマウントしておきさえすれば、普通のコマンドでコピーできるでしょう。
まず試したのがtarを使う方法です。普段から一括コピーする場合はtarを利用することが多いのです。注意したのはロケールです。ファイル名に日本語を使っているところもあるので、余計な処理がおこなわれないようにするためCロケールにしておきました。
ところが標記したようなメッセージが大量に出てくるのです（何故？）。Webを検索してみると「TARコマンドのCan't translate pathnameメッセージ 」という情報を見つけました。 やはりロケールには注意しなければいけないようですが、Cロケールにしたのに何故「Can't translate pathname ～ to UTF-8」というメッセージが出てくるのでしょうか。
このようなメッセージが出てきたとしても、コピー自体は出来ているのか、それとも失敗しているのか、何分にもメッセージが大量に出るので個々に確認していられません。
tarを使うのを諦めて、rsyncを使ってみました。こちらは妙なメッセージが出ることも無く、スッキリと転送されました。rsyncはFreeBSDに標準的に入っているコマンドではありませんが、うまくいくのであればrsyncにしようと思います。
tarを使って転送した場合には39時間ほどかかりましたが、rsyncでは37時間あまりでした。rsyncの方が心持ち速いようですが、劇的に速くなるわけでもなく、ほとんど誤差の範囲です。
登録:
投稿 (Atom)