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の方が心持ち速いようですが、劇的に速くなるわけでもなく、ほとんど誤差の範囲です。
Ten Words to Understand Modern Britain
NHKラジオ第2放送の「ラジオ英会話」のテキストにJapanglophiliaというエッセイが連載されています。著者はColin Joyceさんです。2017年12月号のタイトルは標記の通りです。
いろいろ書いてあるのですが、次のような文がありました。
「シーズン」というのは英語起源の表現なんだろうとは思っていましたが、アメリカ英語独特の表現だとは思いませんでした。
もう一か所、気になったところがあります。
今まで「A+」を「A プラス」と呼んでいたのですが、もしかすると、これも勘違いだったのでしょうか。
いろいろ書いてあるのですが、次のような文がありました。
a lot of American "movies" and whole "seasons" of American television dramas. (They use those words, though the British English is "films" and "series".)注目したのは、アメリカ英語では「シーズン」と呼んでいるものを、（イギリス）英語では「シリーズ」と呼ぶ、というところです。最近は日本のドラマでも「シーズン」という呼び方をしています（テレビ朝日の人気番組「相棒」はシーズン16だそうです）。
「シーズン」というのは英語起源の表現なんだろうとは思っていましたが、アメリカ英語独特の表現だとは思いませんでした。
もう一か所、気になったところがあります。
get a "starred A" (A*)試験の成績を英字で表現することがありますが、「A」よりも良い成績を「A*」というのですね。「A+」というのは知っていたのですが、同じことでしょう。でも気になったのは、そういうことではなくて、「A*」を「starred A」と読むというところです。これを知らなければ「A スター」と呼んでいたところでした。
今まで「A+」を「A プラス」と呼んでいたのですが、もしかすると、これも勘違いだったのでしょうか。
2017-12-06
File Save and Backup AddOn for FireFox 57++
Firefoxのバージョンが上がったことで昔から利用しているアドオンが使えなくなってしまいました。その中のひとつに「TiddlyWiki for Firefox」があります。ローカルで使っているTiddlyWikiに書き込みを加えると、自動的に保存してくれて、便利でした。
これが旧式の拡張機能という扱いになり使えなくなって困っていたところ「File Save and Backup AddOn for FireFox 57++」が登場しました。「TiddlyWiki for Firefox」と同等の動作をするわけではありませんが、当面の解決策の一つだと思います。
ドキュメントにも書かれていることですが、重要な制限事項があります。それは自動的に保存される対象となるのは特定のディレクトリに限られていることです。つまり「ダウンロード先」として指定されているディレクトリだけです。Firefoxのオプションで変更することも可能ですが、デフォルトでは%HOMEPATH%\Downloadsになっているはずです。
過去に書き溜めてきたTiddlyWikiのファイルは%HOMEPATH%\Documentsに置いてあるので、このままでは自動保存の対象になりません。どうしたものかと思いましたが、次のような対応が考えられます。
このようにすることで、ひとまず解決したかと思ったのですが、まだ厄介なことがありました。過去に作成したTWCやTW5のファイルでは、相互のリンクにおいて%HOMEPATH%\Documentsであることを前提にしてファイルパスを埋め込んでいるところがあるのです。これを個々に変更するか、何か別の対処方法を考えるかしなければなりません。
これが旧式の拡張機能という扱いになり使えなくなって困っていたところ「File Save and Backup AddOn for FireFox 57++」が登場しました。「TiddlyWiki for Firefox」と同等の動作をするわけではありませんが、当面の解決策の一つだと思います。
ドキュメントにも書かれていることですが、重要な制限事項があります。それは自動的に保存される対象となるのは特定のディレクトリに限られていることです。つまり「ダウンロード先」として指定されているディレクトリだけです。Firefoxのオプションで変更することも可能ですが、デフォルトでは%HOMEPATH%\Downloadsになっているはずです。
過去に書き溜めてきたTiddlyWikiのファイルは%HOMEPATH%\Documentsに置いてあるので、このままでは自動保存の対象になりません。どうしたものかと思いましたが、次のような対応が考えられます。
- Firefoxのオプションで「ダウンロード先」を%HOMEPATH%\Documentsに変更する。こうすればアドオンの機能により自動的に保存してくれます。しかし何かファイルをダウンロードした時に、DownloadsではなくてDocumentsに入ってしまうことになるので、あまり気持ちよくありません。
- Microsoft Windowsの機能を利用して、あたかも%HOMEPATH%\Downloadsの下に%HOMEPATH%\Documentsのファイルがあるかのように見せかける。
このようにすることで、ひとまず解決したかと思ったのですが、まだ厄介なことがありました。過去に作成したTWCやTW5のファイルでは、相互のリンクにおいて%HOMEPATH%\Documentsであることを前提にしてファイルパスを埋め込んでいるところがあるのです。これを個々に変更するか、何か別の対処方法を考えるかしなければなりません。
2017-12-04
NetBSD/i386で公衆無線LANに接続
dynabook SS SX/15AにインストールしたNetBSD/i386の無線LANを使うために自宅など wpa_supplicantを使っています。SSIDとパスフレーズを記録しておけば、マシンをブートした時点で接続してくれます（ただし接続に失敗することも、よくあるので、これはこれで原因を調査して解決したいと思っていますが、将来的な課題です）。
ところが公衆無線LAN（公衆Wi-Fiとも呼ばれます） の場合、接続するためのSSIDしか公表されていないことがあります（パスフレーズを必要としない）。この場合の手順としては、指定されたSSIDに接続した後でブラウザを開くと利用規約に同意を求められ、その後利用が可能となるのが一般的です。例えばJALのサクララウンジがそうですし、スターバックスもそのようです。
この方式を用いる場合もwpa_supplicantで対応できる（「NetBSDでwpa_supplicantを使ってWEPでWi-Fi接続する場合 」）ようなのですが、うまくいきません。次の手順ならば接続できることは確認しました。
この方法で成功することもありますが、何度か失敗を繰り返すこともあります。スッキリと解決した訳ではないのですが、当面はなんとかなっています。もっと綺麗な解決策があるか調べたいと思っています。
ところが公衆無線LAN（公衆Wi-Fiとも呼ばれます） の場合、接続するためのSSIDしか公表されていないことがあります（パスフレーズを必要としない）。この場合の手順としては、指定されたSSIDに接続した後でブラウザを開くと利用規約に同意を求められ、その後利用が可能となるのが一般的です。例えばJALのサクララウンジがそうですし、スターバックスもそのようです。
この方式を用いる場合もwpa_supplicantで対応できる（「NetBSDでwpa_supplicantを使ってWEPでWi-Fi接続する場合 」）ようなのですが、うまくいきません。次の手順ならば接続できることは確認しました。
- /etc/rc.d/wpa_supplicant stop
- ifconfig 無線LANインターフェイス ssid 指定されたSSID -nwkey
この方法で成功することもありますが、何度か失敗を繰り返すこともあります。スッキリと解決した訳ではないのですが、当面はなんとかなっています。もっと綺麗な解決策があるか調べたいと思っています。
「Japanese English」の和訳の一つの事例
放送大学教養学部で「英語の軌跡をたどる旅（'13）－The Adventure of Englishを読む－」を受講しています。この講義ではMelvyn Braggの『The Adventure of English: The Biography of a Language』（英語の冒険：ある言語の一生）の一部が使われています。
邦訳で「23英語の植民地化」においては「日本人は独特の日本語英語の形態を生み出した。」（340頁）とあります。ここに現れる「日本語英語」というのは、原文をあたっている訳ではないのですが、「Japanese English」を訳したものでしょう。
「Japanese English」の意図するところは、日本人が使う母語（日本語）の影響を受けた英語（表現）ということだと思います。例えば英辞郎だと「日本語訛りの［日本人風の］英語」としています。
日本人の英語を語るとき「Japanese English」という表現はよく出てくると思われます。実際に上述した文献でも出てきています。その時に英辞郎のような訳出でも構わない場合もあるでしょうけど、もっと簡潔に表現したい場合もあると思います。先の例では「日本語英語」としています。特に定まった訳語というのは無いようなので、これ以外にも様々な表現が使われます。
話は飛びますが「Japanese American」は「日系アメリカ人」という訳語が定着しています。「日本人アメリカ人」と訳されることは（ほぼ）無いでしょう。これを考えると「Japanese English」にも何か定訳が欲しいところです。
邦訳で「23英語の植民地化」においては「日本人は独特の日本語英語の形態を生み出した。」（340頁）とあります。ここに現れる「日本語英語」というのは、原文をあたっている訳ではないのですが、「Japanese English」を訳したものでしょう。
「Japanese English」の意図するところは、日本人が使う母語（日本語）の影響を受けた英語（表現）ということだと思います。例えば英辞郎だと「日本語訛りの［日本人風の］英語」としています。
日本人の英語を語るとき「Japanese English」という表現はよく出てくると思われます。実際に上述した文献でも出てきています。その時に英辞郎のような訳出でも構わない場合もあるでしょうけど、もっと簡潔に表現したい場合もあると思います。先の例では「日本語英語」としています。特に定まった訳語というのは無いようなので、これ以外にも様々な表現が使われます。
話は飛びますが「Japanese American」は「日系アメリカ人」という訳語が定着しています。「日本人アメリカ人」と訳されることは（ほぼ）無いでしょう。これを考えると「Japanese English」にも何か定訳が欲しいところです。
登録:
投稿 (Atom)