コグノスケ

エンジン出力特性は三者三様

目次: 車

Automobile Catalogue（リンク）という素敵なサイトがありまして、各メーカーの幅広い車種について情報を公開してくれています。すごい。見ているだけで結構楽しいです。

で、公開している情報のなかにはエンジン出力特性も含まれていて、自分が今まで乗ってきた三車種（三菱 FTO GPX、スバル レガシィB4 GT、ジャガー XE S）の情報もありました。この数字を同一グラフにプロット（※）してみたら各車の性格の違いが出ていて面白かったので紹介したいと思います。

（※）本来は情報元のサイトの画像なりリンクを使って紹介すべきですが、グラフの縦軸がかなり違っていて比較しづらかったため、大体の値を拾って打ち込んだグラフを作りました。元の情報が気になる方はAutomobile Catalogueを見てくださいませ。

各車のエンジンの特徴

各車のエンジンはそれぞれFTOがNA、レガシィがターボ、XEがスーパーチャージャーです。もうちょっと詳しく紹介しておくと、こんな感じです。

三菱 FTO 1995: 6A12

V6, 1996cc, NA, DOHC, MIVEC（可変バルブタイミング機構）

スバル レガシィB4 GT AT 2005: EJ20

B4, 1994cc, ツインスクロールターボ, DOHC, AVCS（可変バルブタイミング機構）

ジャガー XE S 2016: AJ-V6(AJ126)

V6, 2995cc, スーパーチャージャー, DOHC, 直噴

一般論では、可変バルブタイミング機構はトルクが落ちる高回転域をカバーするためのものなので、NAかつ可変バルブタイミング装備のFTOが高回転にトルクのピークがくる高回転型エンジン、低速トルクの特性はNA＜ターボ＜スーチャーと言われますので、XEが低回転にピークがくる低回転型エンジン、レガシィは二者の真ん中と想定されます。

が、しかし実際の出力カーブを見てみるとこんな感じです。トルクのピークが綺麗に別れるのは想定通りですが、想定とちょっと違いました。

FTO、レガシィ、XEのエンジン出力プロット

FTOは想定通り高回転域にトルクのピークが来ます。これは乗っていた時の感覚とも一致しています。上まで回る爽快なエンジンでしたが、回さないときの加速感はあまりなかったです。

一方のターボなレガシィは低回転域にトルクを振っていて、スーチャーなXEは中回転域にトルクを振っているようでした。乗った感じだとレガシィとXEのトルクカーブの山の位置は逆のイメージだったので意外です。素人の感覚は当てになりませんねえ……。

車の修理……のはずが雪

目次: 車

以前（2025年11月21日の日記参照）、ジャガーさんの左前をぶつけてバンパーをガリガリにしてしまいました。1か月前にいい加減直そうと思い立ち修理の予約をしたところ、予約が混んでいたらしくめちゃくちゃ先の日付になってしまいました。

で、今日はいよいよ修理工場に車を持っていく日でした、が……朝起きたら外は雪で真っ白でした……。ええ、なんで今日に限って雪が降る？

一瞬、頑張れば行けるか……？とも考えましたが、夏タイヤで下手に走って一か所でも凍っていたり積雪があったら終わりですし、事故ったら修理もへったくれもないです。修理工場にお電話して予約キャンセルしました。また予約するしかないな〜。

SSLに対応 - Let's Encrypt

目次: 自宅サーバー

一昨年（2024年2月2日の日記参照）にJPRSドメイン認証型SSLを設定しました。年間990円とお安く使えて良かったのですが、サービス終了してしまうらしく、今月から先の継続ができなくなりました。

後継サービスはJPRSドメイン認証型SSL（自動更新）だと思われますが、特に何も変わってなさそうなのに、なぜか料金が年間2,200円（2.5倍）になっていました。値上げするなとは言わないけど、無言で2.5倍にするのはどうなんだ。嘘でもいいから「こんなに良くなりました」くらい言ってほしい……。

そんなこんなでJPRSのSSLとおさらばしてLet's Encryptに変更しました。無料なうえにボタン1個押すだけなのでめちゃ楽です。とてもありがたいんですけど、Let's Encrypt以外を選択する人って居るんだろうか……？

shebangの役割 - シェル側

目次: Linux

前回（2026年1月29日の日記参照）、スクリプトの先頭（例えばシェルスクリプトなど）に書く"#!〜"から始まるおまじないのことをshebangといって、カーネルがexecveシステムコール内で解釈する文字列であることを紹介しました。

また、前々回（2026年1月23日の日記参照）は、shebangは間違っていても動いてしまう場合があることも紹介しました。もう少し正確に言うとexecveシステムコールに渡すとエラーになるスクリプトもシェルで実行できる場合があります。例えばこんな感じです。

#!/bin/dash
 
echo ok

##!/bin/dash
 
echo ng

$ ./ok.sh
ok

$ ./ng.sh
ng

なぜかexecveシステムコールがエラーになるスクリプトでも実行できます。不思議ですよね。

シェルがスクリプトを実行する仕組み

大抵のシェルには、初めにexecveで実行して、失敗したらシェルスクリプトだと思ってシェルに渡して実行する仕組みがあります。実際にコードを見てみましょう。シェルは何でも良いと思われますが、Debianならdashでしょってことでdashを見ます。

// dash/src/exec.c

STATIC void
tryexec(char *cmd, char **argv, char **envp)
{
	char *const path_bshell = _PATH_BSHELL;

repeat:
#ifdef SYSV
	do {
		execve(cmd, argv, envp);
	} while (errno == EINTR);
#else
	execve(cmd, argv, envp);
#endif
	if (cmd != path_bshell && errno == ENOEXEC) {
		*argv-- = cmd;
		*argv = cmd = path_bshell;
		goto repeat;
	}
}

上記のtryexec()関数が先程言った通りの実装になっています。まずexecve()を実行します、成功したら返ってこないのでそれでおしまいです。失敗したらexecve()から返ってくるので、argvを一個ずらしてコマンド名をスクリプトからシェルに変更して再びexecve()を実行します。これは文字で説明してもわかりにくいので、下記にcmdとargvの変化を示します。

• 最初
• cmd: ./ng.sh
• argv[0]: ./ng.sh
• argv[1]: NULL

• 2回目
• cmd: /bin/sh
• argv[0]: /bin/sh
• argv[1]: ./ng.sh
• argv[2]: NULL

先頭のほうで出てくる_PATH_BSHELLはシェルのフルパス文字列を定義したマクロです。

# dash/configure.ac

dnl Check for declarations
AC_CHECK_DECL([_PATH_BSHELL],,AC_DEFINE_UNQUOTED([_PATH_BSHELL], "/bin/sh", [Define to system shell path]),[
#ifdef HAVE_PATHS_H
#include <paths.h>
#endif
])

マクロ_PATH_BSHELLはconfigureのときに決定されます。通常は/usr/include/paths.hが定義しているはずで、私の環境では/bin/shになっていました。もし定義されていない環境の場合はdash側で決めますが、これも/bin/shになるようです。

うまくいかないケース

スクリプトの中身に関わらずシェルスクリプトだと仮定して実行するだけですから、スクリプトがシェルスクリプトでなければエラーになります。やや特殊ケースとして、シェルスクリプトであってもシェル依存の専用構文（bashやzshの専用構文）を使うと実行エラーになります。

わざとbash専用の構文を使ったスクリプトを2つ作ります。片方はshebangが正しく、もう片方はshebangを誤った文字列にしてあり、それ以外は全く同じです。

#### ok_bash.sh

#!/bin/bash

function a()
{
        echo hello
}
a

#### ng_bash.sh

##!/bin/bash

function a()
{
        echo hello
}
a

この2つのスクリプトをdash上で実行しようとすると、下記のようになります。ok_bash.shは実行できますが、ng_bash.shは実行できません。

$ ./ok_bash.sh
hello

$ ./ng_bash.sh
./ng_bash.sh: 3: Syntax error: "(" unexpected

最初のok_bash.shはshebangに書かれた通りbashが起動されるので、bash専用の構文も実行できます。

2つ目のng_bash.shはshebangが間違っていてexecveで実行できないため、dashはスクリプトを/bin/sh = dash上で実行しようと試みます。しかしdashでは使えない構文が含まれているためエラーとなります。

ドラクエ3リメイク、トロフィーコンプ

目次: ゲーム

Steamでドラクエ1＆2 HDリメイクを購入したのですが、完全にほったらかしにしてこれまたSteamのドラクエ3 HDリメイクをずっとやっていまして、今日やっとトロフィーコンプしました。ドラクエ3はクリア後のやりこみ要素、いわゆるエンドコンテンツがあっていつまでも遊べるので、終わりはないといえばないです。でもまあトロフィーコンプは区切りとしては良いところでしょう。

ドラクエ3 HDリメイク、トロフィーコンプ

しんりゅうを7回しばき倒すまでは通常の難易度（ゲームモード「バッチリ冒険」）で進めてましたが、勇者がLv.99になったのに全然クリアできそうな気配がない「試練の神殿」と「グランドラゴーン」は難易度を下げて（ゲームモード「楽ちんプレイ」）クリアしちゃいました。

敵が馬鹿みたいに固いのはまだ良いんですよ、でも武器の制約が面倒すぎて無理でした……。

総じて面白かった

ファミコン版のドラクエ3を遊んだのは小学生の頃だったと思います。もう30年近く前ですかね？細かい部分は覚えていなくても、町の名前とかおおまかな進行とかは意外と覚えているもので懐かしさを感じました。

町は全て3Dで現代PCの計算性能を使いまくって描画され非常に綺麗です。あまりに綺麗なので意味もなく町をうろうろしていました。それでいてドラクエユーザーに馴染み深い固定視点にしていて（あえて視点をぐるぐる回せない）2D時代と同様に操作可能です。よく考えられていて素敵でした。

敵の強さはほどほどです。仲間の職業をあそびにんだらけにするとか、4人未満にするとか極端なことをしない限りは、やたら苦戦したり理不尽に蹂躙されて終わることはほぼないと思います。システムによる救済も昔と比べて格段に親切＆優しいので、向こう見ずに突っ込んで全滅してもほぼデメリットありません。総じて難易度はちょうどよかったと思います。面白かった！

ドラクエ1リメイク、トロフィーコンプ

目次: ゲーム

Steamでドラクエ1＆2 HDリメイクを購入したまま完全放置でドラクエ3やってましたが、やっと戻ってきました。ドラクエ1の分のトロフィーコンプ（たぶん）しました。

ドラクエ1 HDリメイク、（ドラクエ1の分）トロフィーコンプ

ドラクエ1＆2の名の通り、トロフィーはドラクエ1とドラクエ2の分を合わせた表示でコンプかどうかよくわからないですね。まあいいか。一番ありがたかったのはドラクエ1にやりこみ要素がほぼないことでしょうか。やりこみ必要なトロフィーがあったら取れなかったと思います。

ドラクエ1リメイクの感想

ドラクエ1＆2リメイクは、ドラクエ3リメイクとほぼ一緒の制作陣（スクエニ、ARTDINK）です。画面のデザインやゲームのシステムも再利用されているらしくほぼ一緒で、ドラクエ3リメイクを知る人は見慣れた画面だと思います。

ドラクエ1リメイクは敵がやたら強いです。ドラクエ1はずっと1人旅をします。ファミコン版は敵も常に1人（=タイマン戦闘）でしたが、リメイク版は敵多数なのでいつも集団リンチされます。しかも敵から喰らうダメージがデカく、雑魚敵相手でさえ運が悪いと1ターンKOされ、耐えても回復が追いつかずジリ貧の末にKOされます。システムによる救済が格段に親切＆優しいので、全滅してもほぼデメリットないのは唯一の救いです。

私は岩泣き島と竜王の城辺りで、幾度も1ターンKOされて、嫌になってやめました。一応エンディングだけは見ましたよ。道中は「しのびあし」で全部ガン無視、竜王は「楽ちんプレイ」でガン無視した、やる気ゼロスタイルですけど。

ドラクエ3も1もどちらもストーリーの味付けやゲームの出来はとても良かったし、ドラクエ3とシステム共通点の多さを考えると、なぜドラクエ3と1のリメイクでこれほど楽しさの感じ方に差が出たのか？不思議です。

たぶんドラクエ1リメイクのレベルデザインが肌に合わなかっただけだろう、と予想してます。もしかするとLv上げまくったら程よい感じになったのかも？？とは思いますが、今はもう嫌なので、いつか暇だったらやるかも程度です。