2020-12-24

「御名前様」は「御御御付」である

文豪として著名な夏目漱石の作品に『吾輩は猫である』があります。明治時代に書かれたので文体が古風ですが、日本語文法的には「吾輩」=「猫」という関係が成り立っています。そう意味で標題が「御名前様」=「御御御付」という事ではありません。しかし意識上の問題としてはイコール記号で結び付くのではないかと思います。


まず後半の「御御御付」とは「味噌汁」のことです。語源については諸説あるようですが、丁寧さを示す「御」が次第に重複していったようです。


さて前半の「御名前様」ですが、何時頃からか不明ですが、店頭などで名前を尋ねられる時に「御名前様を云々」と言われる経験をするようになりました。「名前」に「御」がついているだけでも十分に丁寧だとおもいます。ところが「御名前」という表現が当たり前になってしまうと、敬意が不足していると感じるようになったのでしょう。そこで何にでも「様」をつけておけば丁寧になるだろうという発想があるのかもしれません。


随分前のことになりますが、大学受験の際に受験会場の構内アナウンスで「受験生様」と呼びかけられた時には吃驚しました。最近では病院によっては「患者様」と呼びかけるところもあるようです。また施設でも「利用者様」のような表現をしているようです。


何にでも「様」をつければ良いというものではないだろうと(個人的には)感じているのですが、このような傾向は今後も続いていくのではないかと思います。将来は「様」だけでも足りなくて、もっと大仰な接辞がつくかもしれません。


現時点では、「御名前様」という表現はされるのですが、さすがに「御電話番号様」とか「御住所様」のような表現は出現していないようです。しかし、これも登場するのは時間の問題かもしれません。

2020-12-11

yumの後継dnfがCentOS7.4で動作しない(CentOS7.9なら動く)

2020年12月8日にCentOSの方針転換が発表され騒ぎになっています(CentOSが開発方針を変更ーー「CentOS 8」は2021年終了、今後は「CentOS Stream」に注力)。気になりますが、発表が唐突ですし、反発も大きいので、別の方向性が示されるかもしれません。今後の動向に注意しようと思います。


それはさておき、CentOS7で使われていたコマンド「yum」は、CentOS8では「dnf」に置き換わることになっています。yumがPython3に対応できないことが理由です。CentOS7ではyumを使い続けることになっていますが、dnfをインストールすることも可能です。そこでCentOS7.4の環境にインストールしてみました。ところが実行するとエラーで動きません。

Traceback (most recent call last):

  File "/usr/bin/dnf", line 57, in <module>

    from dnf.cli import main

  File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 30, in <module>

    import dnf.base

  File "/usr/lib/python2.7/site-packages/dnf/base.py", line 29, in <module>

    import libdnf.transaction

  File "/usr/lib64/python2.7/site-packages/libdnf/__init__.py", line 3, in <module>

    from . import conf

  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 17, in <module>

    _conf = swig_import_helper()

  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 16, in swig_import_helper

    return importlib.import_module('_conf')

  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module

    __import__(name)

ImportError: No module named _conf


何が悪いのか分かりません。別の環境で試してみようと考えて、VirtualBox上にCentOS7.9を準備して、動かしてみました。すると、全く問題ありません。


CentOS7.4とCentOS7.9の中で何かが違うのでしょう。Webを検索してみたら「Centos Extras DNF incompatible with versions less than EL7.6 #827」という情報を見つけました。その解決策は次のようにすると書かれていました。

After installing/updating some related packages, resolved the "ImportError: No module named _conf" issue for me.

yum update python*

yum install dnf-data dnf-plugins-core libdnf-devel libdnf python2-dnf-plugin-migrate dnf-automatic

dnf is now working on a CentOS 7.5 box. Some packages might be unnecessary, but you have to try for yourself...


これで本当に解決するなら、それはそれで良いのですが、何故これで解決になるのか理解できません。なにしろ何が問題の原因なのか把握できていないからです。


状況を調査するため、エラー出力で指摘されているファイル「/usr/lib64/python2.7/importlib/__init__.py」にデバッグ情報を出力するロジックを加えてみました。するとCentOS7.4とCentOS7.9とでは結果が違います。


CentOS7.4では以下のようになりました。

('>>>', 'libdnf._conf')

('>>>', '_conf')

CentOS7.4では以下のようになりました。

('>>>', 'libdnf._conf')

('>>>', 'libdnf._module')

('>>>', 'libdnf._repo')

('>>>', 'libdnf._transaction')

('>>>', 'libdnf._utils')

('>>>', 'libdnf._smartcols')


更に、ファイル「/usr/lib64/python2.7/importlib/__init__.py」にデバッグ情報を出力するロジックを加えて状況を確認すると、次のことが分かりました。

  1. CentOS7.4の場合、ファイル「/usr/lib64/python2.7/site-packages/libdnf/conf.py」の14行目で呼ばれたのが最初の行に相当し、2番目は16行目が呼び出し元のようです。
  2. どうやら初回呼び出しで例外が起きているようですが、その詳細情報がわかりません。それを取得するロジックを加えてみると、「ImportError('/lib64/libmodulemd.so.1: undefined symbol: g_log_structured_standard'」であることがわかりました。

ちなみにファイル「/usr/lib64/python2.7/site-packages/libdnf/conf.py」の14行目とか16行目というのは、以下のようになっています。

    13          try:
    14              return importlib.import_module(mname)
    15          except ImportError:
    16              return importlib.import_module('_conf')

コマンド「ldd -r /lib64/libmodulemd.so.1」で確認しても、やはり同様のエラーになります。

undefined symbol: g_log_structured_standard     (/lib64/libmodulemd.so.1)

        linux-vdso.so.1 =>  (0x00007fffbf9b8000)

        libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007fa9b63d0000)

        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fa9b60be000)

        libyaml-0.so.2 => /lib64/libyaml-0.so.2 (0x00007fa9b5e9e000)

        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa9b5c88000)

        libc.so.6 => /lib64/libc.so.6 (0x00007fa9b58ba000)

        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fa9b5658000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa9b543c000)

        libffi.so.6 => /lib64/libffi.so.6 (0x00007fa9b5234000)

        /lib64/ld-linux-x86-64.so.2 (0x00007fa9b6881000)


だいぶ状況が理解出来てきたので、あらためてWebを検索すると「ローカルで動いてたpuppeteerがCentos7で動かにゃい」という情報が見つかりました。


この問題はパッケージ「glib2」を更新すれば良いようです。現状を確認してみると、CentOS7.4では「glib2.x86_64  2.50.3-3.el7  @anaconda」、CentOS7.9では「glib2.x86_64  2.56.1-7.el7  @anaconda」でした。CentOS7.4でコマンド「yum update glib2」を実行すると「glib2.x86_64  2.56.1-8.el7  @updates」になりました。


以上の処置をすませて、コマンド「dnf」を実行してみると、無事に動作してくれました。


2020-12-08

放送大学教養学部「漢文の読み方('19)」の参考書としての『中国語の歴史』(著/大島正二)

放送大学教養学部で2020年第2学期は「漢文の読み方('19)」を受講しています。漢文を読むというと訓点の使い方の印象が強いのですが、本授業では品詞や文構造の説明が出てきます。こういう内容は、もしかすると高校の頃に習っていたのかもしれませんが、全然覚えていません。


漢文の品詞体系は、英語や日本語の文法の知識が参考になるような気がしますが、ちょっと独特だと感じます。前置詞を「介詞」とも呼ぶようですし、代詞(人称代詞、指示代詞、疑問代詞)と呼ぶことにも吃驚です。


頭を整理するために、何か参考となる書籍があるかと思って、近所の図書館に行ってみました。中国語の文法に関する書籍は見つかりましたが、現代中国語の文法と、「漢文」の文法は(全く異なるわけではないのでしょうが)同じなのでしょうか。


更に書棚を探していたら『中国語の歴史』(大島正二、ISBN978-4-469-23314-8)を見つけました。目次は次のようになっています。

  1. 第1章 漢字の〈形〉のはなし
  2. 第2章 漢字の〈音〉のはなし
  3. 第3章 漢字の〈義〉のはなし
  4. 第4章 中国語の〈文法〉のはなし

「漢字」は「形音義」を表しているとされていますし、さらに中国語文法の話題も取り扱っているので、本書は講義の参考として全体像を把握するのにピッタリである気がしています。

2020-12-07

xfs_bmapで出力されるブロックは何処にあるのか

VirtualBox上にCentOS 7.4をインストールしています。ファイルシステムはXFSですが、LVMも使われているようです。

[root@centos74 xfs]# df -T -t xfs

Filesystem              Type 1K-blocks    Used Available Use% Mounted on

/dev/mapper/centos-root xfs   30385668 4715672  25669996  16% /

/dev/sda1               xfs    1038336  183468    854868  18% /boot


任意のファイルを作成し、コマンド「xfs_bmap」を実行すると、そのファイルの実体が置かれているブロック位置がわかりますが、これは具体的に何処なのでしょうか。

[root@centos74 xfs]# cat date.txt 

Fri Dec  4 09:54:58 JST 2020

[root@centos74 xfs]# xfs_bmap -v date.txt 

date.txt:

 EXT: FILE-OFFSET      BLOCK-RANGE        AG AG-OFFSET        TOTAL

   0: [0..7]:          30936616..30936623  2 (536104..536111)     8


コマンド「dd」を使って確認してみると、BLOCK-RANGEで表示されたのが実体のあるブロック位置という事のようです。

[root@centos74 xfs]# dd if=/dev/mapper/centos-root bs=512 count=1 skip=30936616 | strings

1+0 records in

1+0 records out

512 bytes (512 B) copied, 8.8025e-05 s, 5.8 MB/s

Fri Dec  4 09:54:58 JST 2020


ひとまず納得できましたが、LVMの論理ボリューム「centos-root」は、HDD上(VirtualBoxで実験しているので、仮想ディスクですが)にあるパーティションのひとつの中に構成されています。

[root@centos74 xfs]# fdisk -l /dev/sda

Disk /dev/sda: 34.4 GB, 34359738368 bytes, 67108864 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk label type: dos

Disk identifier: 0x000017ce

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1   *        2048     2099199     1048576   83  Linux

/dev/sda2         2099200    67108863    32504832   8e  Linux LVM


論理ボリューム「centos-root」から見たブロック位置は、パーティション「/dev/sda2」やHDD「/dev/sda」から見て、どのブロック位置になるのでしょうか。


LVMの構成情報はディレクトリ「/etc/lvm/backup」にあります。テキスト形式になっており、次のような情報が得られます。

# Generated by LVM2 version 2.02.171(2)-RHEL7 (2017-05-03): Mon Dec  7 10:05:56 2020

(略)

centos {

(略)

        physical_volumes {

                pv0 {

                        id = "NcNMF2-iNcr-jMVY-379Q-orOj-PHfL-DZU3BN"

                        device = "/dev/sda2"    # Hint only

(略)

                        pe_start = 2048

                        pe_count = 7935 # 30.9961 Gigabytes

                }

        }

        logical_volumes {

                swap {

                        id = "fWmF2u-VxqX-06BN-IZnx-e8FQ-NM6Y-THhGZk"

(略)

                        segment1 {

                                start_extent = 0

                                extent_count = 512      # 2 Gigabytes

(略)

                        }

                }

                root {

                        id = "qzxis0-iY72-OMfH-3psn-HV05-TDxi-c3VEF8"

(略)

                        segment1 {

                                start_extent = 0

                                extent_count = 7422     # 28.9922 Gigabytes

(略)

                        }

                }

        }

}


ここから次のことがわかります。

  1. 論理ボリューム「centos-root」は、論理ボリューム「centos-swap」の後ろに置かれている。
  2. 物理ボリューム「pv0」は、デバイス「/dev/sda2」の相対位置「2048」から始まる(pe_start = 2048)。

以上より次の計算をおこないます。
  1. 論理ボリューム「centos-swap」は「extent_count = 512」なので、512バイトブロック単位に換算すると、4194304(= 512 * 8192)となります。
  2. 物理ボリューム「pv0」は、パーティション「/dev/sda2」の先頭から2048離れた位置から始まっていることに注意が必要です。
  3. 論理ボリューム「centos-root」にあるファイル「date.txt」のブロック位置「30936616」は、パーティション「/dev/sda2」から見るとブロック位置「35132968」(= 30936616 + 512 * 8192 + 2048)になるはずです。

この計算結果を確かめてみました。
[root@centos74 xfs]# dd if=/dev/sda2 bs=512 count=1 skip=35132968 | strings -tx
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.0211708 s, 24.2 kB/s
      0 Fri Dec  4 09:54:58 JST 2020

考え方は合っているようです。同じように考えれば、HDD「/dev/sda」から見たブロック位置も求められるでしょう。

2020-12-06

「軍」に属しているのに「軍人」ではないメンバーを擁する団体

プロ野球チームのひとつである「読売ジャイアンツ」は「巨人軍」とも呼ばれています。当たり前のように耳にしますが、よく考えてみると、なぜジャイアンツだけ巨人「軍」と呼ばれているのか不思議です。「阪神タイガース」など他のチームは「○○軍」のような呼び方をしませんし、野球以外のプロスポーツも同様です。


このような疑問を抱く人は他にもいて、Webを検索したら「「巨人軍」だけなぜ「軍」が付く?ジャイアンツ誕生秘話」という記事を見つけました。要するにチームの成り立ちに由来するというのが答えのようです。


なぜ「巨人軍」と呼ばれているのか分かりましたが、ジャイアンツの所属選手は「軍人」とは呼ばれないのでしょうか。会社に所属しているのは「社員」ですし、学校の所属しているのは「学生」です。しかし「巨人軍」に所属しているのは(当然ながら)「軍人」ではないのです。

2020-12-05

京阪のダブルデッカー

先日淀屋橋から京阪のダブルデッカーに乗車しました。京阪以外でも2階建て車両を運行している鉄道はありますが、ダブルデッカーというと京阪というイメージがあります。


カタカナで表記する「ダブルデッカー」というのは英語の「double decker」の事ですが、英語を日本語で表記する規則は微妙な例外があることに注意が必要かもしれません。


例えば「computer」をカタカナで表記する際に「コンピューター」とも「コンピュータ」とも表記します。長音「ー」は省略されることがあります。同様に「ユーザー」と「ユーザ」や、「サーバー」と「サーバ」があります。しかし常に長音を省略することができる訳でもないのが難しいところです。


さて「デッカー」は「デッカ」と表記できるのでしょうか。常識的には出来ないと思いますが、出来ない理由が存在する訳でもないと思います。もし省略できるとしたら、「ダブルデッカー」でも「ダブルデッカ」でも構わないことになるのですが、この両者が同じものとは感じられなくなります。そのポイントは、京阪が大阪に拠点を持つ鉄道会社である事にあるのではないでしょうか。


カタカナ文字で「ダブルデッカー」と「ダブルデッカ」を記述すれば、どちらでも構わない気がするかもしれません。しかし音声で聴くとしたら(音声には平仮名も片仮名もありませんから)「ダブルデッカー」と「ダブルでっか」となりかねません。


もっとも、ありがちな方言は現実には存在しないとも言われるので、語尾に「でっか」をつける方言は大阪には存在しないということになるのでしょうか。

海外書店に注文した古本は何処から届くのか

以前から洋書を購入する際に、古本でも構わないのであれば、AbeBooksを利用するようにしています。このサイトを使えば、古書店を個々にアクセスしなくても済むので、ずいぶん手間が省けます。日本にも「日本の古本屋」というサイトがあります。


今年の10月初めにAbeBooksを通じて米国の書店に注文を出しました。すぐに発送処理はされたようですが、COVID-19の影響で到着が遅くなるかもしれないと、メールで連絡が来ました。COVID-19の影響が各所に出ているのは理解できますが、どれくらい遅れるというのか見当がつきません。


注文した本は11月下旬に到着しました。約2ヶ月かかっていますが、どこで時間がかかってしまったのか、不思議です。もっと不思議なのは、注文した書店が米国なのに、到着した古本はスイスから発送されていることです。現代社会の物流は、国家の枠組みを外れて、世界規模で回っているという事なのかもしれません。

タブレットを用いた閉塞方式

昔の鉄道の仕組みを解説した文章を読むと「タブレット交換」の話題がでてきます。漠然としたイメージは持っているのですが、詳細な手順については知らないのでYouTubeで動画を見てみました。同じようなものは他にもあると思いますが、検索して偶々見つけた動画を見ました。



率直な感想は「手順が難しい」です(慣れれば簡単なのでしょうが)。当時の技術水準を踏まえたシステムになっているのだと思いますが、とにかく人手をかけて運用されているという印象です。こんな手間をかけて閉塞をおこなっているようでは、現在の山の手線のような運行本数は確保できないでしょう。


ここで疑問が生じたのですが、タブレット交換の運用手順は、何時頃登場したのでしょう。また運用手順は最初から同様だったのでしょうか。イギリスで鉄道が誕生し、日本で明治初期に新橋横浜間で鉄道が始まった頃、閉塞はどうしていたのでしょう。おそらく数々の事故を起こした経験からシステムが出来上がっていったのではないかと思います。タブレット交換の歴史的変遷にも興味が出てきました。


ここで(馬鹿げていると思うかもしれませんが)「歴史のif」として、「もし東海道新幹線にタブレット交換閉塞方式が採用されていたら」という事を考えてみるのも一興です。真面目に考えれば荒唐無稽なのは分かりきっているので、ちょっとしたお遊びです。


駅ごとに停車していく列車ならば、駅員がタブレットを手渡しできます。しかし駅を通過する急行列車のような場合は、車両にタブレットキャッチャーが装備されています。同じような感じで、団子鼻で有名な0系新幹線の運転台の下にタブレットキャッチャーが装備されていると想像するのも「鉄道マニア」の夢物語としては悪くありません。

100分 de 名著「伊勢物語」

NHK Eテレで放送されている「100分 de 名著」で2020年11月に取り上げた作品は「伊勢物語」でした。伊勢物語というと「昔、おとこありけり。」という書き出しで有名ですが、実は作品を通読したことはなく、どのような作品なのか知りませんでした。


平安時代の作品であることは知っていました。同時代の作品としては『源氏物語』が有名なので、同じような感じなのだろうと思っていましたが、随分と様相が異なるようです。小説というよりも、和歌を主体として若干の詞書が添えられたもののようで、全体で125章段ありますが、とても短いので、表面的に読むだけなら時間はかからないでしょう。


岩波文庫から『伊勢物語』が出ているので買ってみようと思ったのですが、あいにくと近所の書店では在庫がありませんでした。その代わりに高樹のぶ子著『業平』があったので買ってみました。


『業平』は『伊勢物語』の翻刻や現代語訳ではなく、オリジナリティのある小説なので、『伊勢物語』を読むのとは違うと思いますが、また違った趣で楽しく読んでみようと思います。

NHK BS世界のドキュメンタリー「世界一豪華な刑務所の内側」

NHK BS1で深夜に「BS世界のドキュメンタリー」という番組があります。2020年11月24日に放送されたのは「世界一豪華な刑務所の内側」という作品でした。 これは2020年にイギリスの放送局が制作した作品で、ノルウェーにあるという豪華な刑務所をイギリス人が尋ねるという内容です。


刑務所というと、時代も国も違いますが、映画「ショーシャンクの空に」や「グリーンマイル」で描かれているようなものを想像します。多分世界の何処でも同じような感じでしょう。ところがノルウェーのハルデン刑務所は全然違っていて、まるでリゾートホテルのようです。


この刑務所には鉄格子が見当たりません。しかも刑務所内に音楽スタジオがあって囚人がラップ音楽の制作に励んでいます。他にも数々の設備が整っているようです。訪問したイギリス人は、信じられない、ありえない、を連発していました。


ただしノルウェーでは当たり前ということではないようで、実験的な位置づけではあるようです。


このような在りかたが妥当なのか否かは容易に判断できませんが、作品の中で刑務官が「私たちの役割は、囚人を貶めることではなく、社会復帰するのを手助けすることなのです。」と語っていた言葉は印象的でした。