DEV Community: vast cow

Controlling CPU Fan Speed on Mac mini 5,2 with Ubuntu 24.04

vast cow — Wed, 09 Sep 2026 01:54:03 +0000

If you have a Mac mini 5,2 (Mid 2011) running Ubuntu 24.04, a convenient setup is to use applesmc + mbpfan. mbpfan 2.4.0 is also included as a standard package in Ubuntu 24.04 (Noble). Ubuntu Packages

The Linux applesmc driver provides Intel Mac temperature sensors and fan control via sysfs. GitHub

1. First, check `applesmc`

sudo modprobe applesmc
sudo modprobe coretemp

lsmod | grep -E 'applesmc|coretemp'

Next, check the fan interface.

SMC=$(find /sys/devices/platform -maxdepth 1 -type d -name 'applesmc.*' -print -quit)
echo "$SMC"

ls -l "$SMC"/fan*

For example, if you see something like this, you can control it.

fan1_input
fan1_manual
fan1_max
fan1_min
fan1_output

Be sure to check fan1_min and fan1_max.

cat "$SMC/fan1_min"
cat "$SMC/fan1_max"
cat "$SMC/fan1_input"

The values will vary depending on the Mac, so it is safer not to assume values like 1800-5500 RPM.

2. Manually change the rotation speed

You can first test it temporarily at, for example, 3000 RPM.

echo 1 | sudo tee "$SMC/fan1_manual"
echo 3000 | sudo tee "$SMC/fan1_output"

Current actual rotation speed:

cat "$SMC/fan1_input"

After a few seconds, it should be around 3000 RPM.

On Intel Macs in Linux, the method of setting fan1_manual=1 and then writing the target RPM to fan1_output is used. Ask Ubuntu

Return to automatic control

This is important.

echo 0 | sudo tee "$SMC/fan1_manual"

If you leave it in manual mode and fix it at a low rotation speed, the rotation speed will not increase even when the CPU/GPU load increases.

3. Recommended: Use `mbpfan` to link to temperature

On Ubuntu 24.04,

sudo apt update
sudo apt install mbpfan lm-sensors

Enable:

sudo systemctl enable --now mbpfan

Check status:

systemctl status mbpfan

mbpfan reads the CPU temperature from coretemp and changes the fan speed via applesmc. GitHub

Configuration:

sudo nano /etc/mbpfan.conf

For example, for Mac mini 5,2, I would first try the following as a gentle setting.

[general]

low_temp = 55
high_temp = 65
max_temp = 80

polling_interval = 1

For the fan's min/max, mbpfan can use the values reported by applesmc. If you want to specify it explicitly,

cat "$SMC/fan1_min"
cat "$SMC/fan1_max"

and then

min_fan1_speed = 2000
max_fan1_speed = 5500

Set it using the actual values of your machine. mbpfan's default setting also specifies that it refers to /sys/devices/platform/applesmc.768/fan*_min and fan*_max. GitHub

After changing:

sudo systemctl restart mbpfan

4. Monitor temperature and RPM in real time

sensors

Or,

watch -n 1 sensors

If you want to see the fan RPM directly:

watch -n 1 "cat $SMC/fan1_input; sensors"

macmini5,2 ubuntu24.04でcpuファンスピードをコントロールしたい

Macmini5,2（Mid 2011）+ Ubuntu 24.04 なら、applesmc + mbpfan が扱いやすい構成です。Ubuntu 24.04（Noble）にも mbpfan 2.4.0 が標準パッケージとしてあります。(Ubuntu Packages)

Linux の applesmc ドライバは Intel Mac の温度センサーとファン制御を sysfs 経由で提供しています。(GitHub)

1. まず `applesmc` を確認

sudo modprobe applesmc
sudo modprobe coretemp

lsmod | grep -E 'applesmc|coretemp'

次にファンのインターフェースを確認します。

SMC=$(find /sys/devices/platform -maxdepth 1 -type d -name 'applesmc.*' -print -quit)
echo "$SMC"

ls -l "$SMC"/fan*

例えば、以下のようなものが出れば制御できます。

fan1_input
fan1_manual
fan1_max
fan1_min
fan1_output

fan1_min と fan1_max を必ず確認してください。

cat "$SMC/fan1_min"
cat "$SMC/fan1_max"
cat "$SMC/fan1_input"

Mac によって値は違うので、1800～5500 RPM などと決め打ちしない方が安全です。

2. 手動で回転数を変更する

まず一時的に 3000 RPM などでテストできます。

echo 1 | sudo tee "$SMC/fan1_manual"
echo 3000 | sudo tee "$SMC/fan1_output"

現在の実回転数：

cat "$SMC/fan1_input"

数秒すると 3000 RPM 前後になっているはずです。

Linux 上の Intel Mac では、fan1_manual=1 にしてから fan1_output に目標RPMを書く方法が使われています。(Ask Ubuntu)

自動制御に戻す

これは重要です。

echo 0 | sudo tee "$SMC/fan1_manual"

手動モードのまま低回転に固定すると、CPU/GPU負荷が上がっても回転数が上がらなくなります。

3. おすすめ：`mbpfan` で温度連動

Ubuntu 24.04 なら、

sudo apt update
sudo apt install mbpfan lm-sensors

有効化：

sudo systemctl enable --now mbpfan

状態確認：

systemctl status mbpfan

mbpfan は coretemp からCPU温度を読み、applesmc 経由でファン速度を変更します。(GitHub)

設定は：

sudo nano /etc/mbpfan.conf

例えば私は Macmini5,2 なら、まず穏当な設定として次のあたりから試します。

[general]

low_temp = 55
high_temp = 65
max_temp = 80

polling_interval = 1

ファンの min/max は applesmc が報告する値を mbpfan が利用できます。明示的に設定したい場合は、

cat "$SMC/fan1_min"
cat "$SMC/fan1_max"

を確認してから、

min_fan1_speed = 2000
max_fan1_speed = 5500

のように実機の値を使って設定します。mbpfan の標準設定も /sys/devices/platform/applesmc.768/fan*_min と fan*_max を参照する仕様です。(GitHub)

変更後：

sudo systemctl restart mbpfan

4. 温度とRPMをリアルタイム監視

sensors

または、

watch -n 1 sensors

ファンRPMも直接見たいなら：

watch -n 1 "cat $SMC/fan1_input; sensors"

Macmini5,2 なら私ならこうします

常用は mbpfan、手動の fan1_output は動作確認用にします。

最初に、次の結果を貼ってもらえれば、Macmini5,2 の実機値に合わせて /etc/mbpfan.conf を具体的に作れます。

uname -r
lsmod | grep -E 'applesmc|coretemp'
SMC=$(find /sys/devices/platform -maxdepth 1 -type d -name 'applesmc.*' -print -quit)
echo "$SMC"
for f in "$SMC"/fan*; do echo -n "$f = "; cat "$f"; done
sensors

特に fan1_min / fan1_max とアイドル時・負荷時CPU温度が分かれば、「静音寄り」「冷却寄り」のファンカーブを決められます。

Checking if a Used Core i7-6700 is Genuine Without Benchmarks

vast cow — Fri, 04 Sep 2026 04:07:06 +0000

When purchasing a used Intel CPU, you might wonder if the heat spreader has been swapped with another CPU or if it's a fake with a modified model number.

This time, using an actual Intel Core i7-6700 as an example, we'll try to determine how much we can verify its authenticity without using performance measurements, by checking:

Heat spreader markings
S-Spec
FPO (Batch Number)
ATPO (Serial Number)
Data Matrix
Partial ATPO

The Core i7-6700 We're Checking

The CPU surface has the following markings:

i7-6700
SR2L2 3.40GHZ
X012C345 (e4)

First, let's clarify what each of these means.

Display	Meaning
i7-6700	CPU model name
SR2L2	S-Spec
3.40GHZ	Base clock speed
X012C345	FPO (Batch Number)
(e4)	Not ATPO

According to Intel's official information, the Core i7-6700 has an S-Spec of SR2L2 and an R0 stepping. Also, the i7-6700 has a base clock speed of 3.40GHz.

Therefore, there are no inconsistencies in the markings on the surface so far.

What is FPO?

FPO stands for "Finished Process Order," and Intel treats it as the Batch Number.

In this CPU,

X012C345

is the FPO.

The FPO is located on the heat spreader.

Importantly, it is different from SR2L2.

SR2L2    → S-Spec
X012C345 → FPO

Even in Intel's Warranty Information, the FPO is entered as the "Batch number."

What is ATPO?

ATPO stands for "Assembly Test Process Order," and it is treated as the CPU's Serial Number.

While the FPO is a batch number, the ATPO is a number to identify each individual processor.

Intel CPUs have a very small 2D Matrix on the outer edge of the substrate.

Decoding this 2D Matrix allows you to obtain the Full ATPO (complete serial number).

Reading a 2D Matrix with a Smartphone

This time, I was able to read the code using the "Code Scan - QR & Barcode Scanner" app from the App Store on my iPhone.

https://apps.apple.com/jp/app/code-scan-qr-barcode-scanner/id1554812545

Because the Intel CPU code is very small, it may not be recognized properly by a regular QR code reader. Intel also states that you can read the 2D Matrix using a compatible app that utilizes your smartphone's camera.

When reading, it helps to:

Clean the surface of the CPU to remove any dirt.
Take the picture in a well-lit area.
If there is reflection, shine a light on it from an angle.
Focus on the code.
If necessary, use macro photography.
Cover the parts other than the 2D Matrix with dark paper or objects to increase the contrast between the code and the board.

This will increase the chances of success.

In particular, in the tests I conducted, covering the parts other than the code with something dark and making the 2D Matrix stand out made it easier to recognize.

The CPU board has characters, wiring patterns, and metal parts, so when viewed from the camera, there are many fine patterns in addition to the 2D Matrix. Therefore, the method of covering the surroundings to hide them and making only the code you want to read stand out is worth trying when the scan is unstable.

With this i7-6700, I scanned it with my iPhone using this method as well, and the app gave me the following result:

U6SG012345678

What you need is the Content side.

Therefore, the Full ATPO of this CPU is:

U6SG012345678

Note that Hex is not a different serial number.

For example:

55 → U
36 → 6
53 → S
47 → G

It is a hexadecimal representation of the characters in the Content string.

Finding the Partial ATPO

Next, carefully examine the outer edge of the CPU substrate.

On this CPU, a very small string:

was printed.

This is the Partial ATPO.

According to Intel, the Partial ATPO is the last 3-5 characters of the Full ATPO.

Therefore, compare it with the Full ATPO read from the Data Matrix earlier.

Full ATPO
U6SG012345678
        ↓↓↓↓↓
        45678

Partial ATPO on the substrate
45678

The last 5 characters matched perfectly.

This is an important checkpoint.

Intel also advises, as a procedure for checking counterfeit CPUs, to read the Full ATPO from the 2D Matrix and compare the last 5 characters with the Partial ATPO printed on the outer edge of the CPU. If it is genuine, they should match.

Therefore, in this CPU:

Data Matrix
     ↓
U6SG012345678
        ↓
      45678
        ↑
"45678" on the substrate

This correspondence was confirmed.

At least, the Data Matrix on the substrate and the Partial ATPO that humans can read are correctly matched.

Can the Heat Spreader and Substrate be Directly Matched?

This is the part I was particularly concerned about while researching.

On the heat spreader side, there is:

i7-6700
SR2L2
X012C345

On the other hand, on the substrate side, there is:

Full ATPO:
U6SG012345678

Partial ATPO:
45678

In summary:

[Heat Spreader]
i7-6700
SR2L2
FPO: X012C345
       │
       │ ← This is what I wanted to confirm
       │
[CPU Substrate]
Full ATPO: U6SG012345678
Partial ATPO: 45678

Regarding Full ATPO and Partial ATPO:

U6SG012345678
        ↓↓↓↓↓
        45678

This can be physically confirmed.

However, there is no publicly available rule that users can use to calculate and confirm the relationship between:

FPO X012C345
      ↕
ATPO U6SG012345678

If you can successfully search Intel's Warranty Information, you can confirm the combination of FPO and ATPO, but in this i7-6700, no search results were found.

Therefore, I could not completely confirm that the heat spreader was originally attached to this substrate at the factory.

How to Check for "A Fake with an i7-6700 Heat Spreader Placed on a Different CPU"?

For example, consider the following:

Different CPU substrate
   ＋
Heat spreader labeled i7-6700

This is a form of forgery.

In this case, it will look like an i7-6700 just by looking at the surface.

In this case, what is effective is the identification information inside the CPU.

Intel also advises that if you can install the CPU in a PC, use the Intel Processor Diagnostic Tool to check:

Genuine Intel: Pass

and that the product name matches.

Furthermore, with CPU-Z and HWiNFO, check:

Core i7-6700
Skylake
4 cores, 8 threads
8MB L3
R0 stepping
CPUID is consistent with Skylake

If you check these, it will be much easier to detect a simple forgery where "the heat spreader says i7-6700, but the inside is a different CPU."

This is different from comparing benchmark scores; it's a method of checking the identification information returned by the CPU itself.

Results This Time

In this Core i7-6700:

Check	Result
i7-6700 is printed on the surface	○
S-Spec `SR2L2`	Matches Intel's official information
3.40GHZ	Matches Intel's specifications
FPO `X012C345`	Confirmed
2D Matrix	Successfully read
Full ATPO	Successfully obtained
Partial ATPO	`45678`
Full ATPO ending	`45678`
Full/Partial ATPO	5 characters match perfectly
Warranty Information	Could not find the product
FPO and ATPO Intel DB check	Unconfirmed

Therefore, within the scope that we could confirm this time, no information contradicting the fact that it is a genuine Core i7-6700 was found.

In particular,

The last 5 characters of the Full ATPO obtained from the Data Matrix and the Partial ATPO printed directly on the substrate matched.

This is a strong piece of evidence.

However, since the combination of FPO and ATPO could not be confirmed in Intel's Warranty Information,

We could not completely confirm that the heat spreader and substrate were originally a set from the factory.

Summary of How to Check a Used Intel CPU

If you want to check without using performance measurements, the following order is practical:

① Check the model number on the CPU surface
        ↓
② Compare the S-Spec with Intel's official information
        ↓
③ Record the FPO
        ↓
④ Scan the 2D Matrix on the outer edge of the substrate
        ↓
⑤ Obtain the Full ATPO
        ↓
⑥ Find the Partial ATPO on the substrate
        ↓
⑦ Compare with the last 3-5 characters of the Full ATPO
        ↓
⑧ Enter the FPO + ATPO in Intel Warranty Information
        ↓
⑨ If you can install it in a PC, use the
   Intel Processor Diagnostic Tool to check
   for Genuine Intel and the product name

In particular, ④-⑦ can be checked without running the CPU.

Caution: It's Best Not to Publish the ATPO

The ATPO is the CPU's Serial Number.

When publishing photos on blogs or flea market sites, it is best to hide part of it, like this:

U6SG0123*****

Also, since it may be possible to read the Full ATPO from the code even if you hide the 2D Matrix itself, it is safe to put a mosaic on the 2D Matrix as well.

Summary

Intel CPUs have multiple identification pieces of information, not just "Core i7" written on them:

S-Spec → FPO → Data Matrix → Full ATPO → Partial ATPO

In this i7-6700, we were able to confirm up to:

SR2L2
FPO: X012C345
Full ATPO: U6SG0123*****
Partial ATPO: 45678

and the correspondence between Full ATPO and Partial ATPO was also confirmed.

When checking the authenticity of a used CPU, it is useful to use not only benchmark results but also this method of cross-checking physical traceability information.

However, this does not cryptographically prove the authenticity of the semiconductor. In particular, with older CPUs, search results may not be found in Intel's current Warranty search, so it is practical to combine:

Physical marking consistency + ATPO consistency + identification information inside the CPU

to make a judgment.

中古のCore i7-6700が本物か、ベンチマークを使わずに確認してみた

中古でIntel CPUを入手したとき、「ヒートスプレッダだけ別のCPUに交換されていないか」「型番を書き換えた偽物ではないか」が気になることがあります。

今回は実際のIntel Core i7-6700を例に、性能測定を使わず、

ヒートスプレッダの刻印
S-Spec
FPO（Batch Number）
ATPO（Serial Number）
Data Matrix
Partial ATPO

を使って、どこまで真贋を確認できるのか試してみました。

今回確認するCore i7-6700

CPU表面には次のように刻印されています。

i7-6700
SR2L2 3.40GHZ
X012C345 (e4)

まず、それぞれの意味を整理します。

表示	意味
i7-6700	CPUの製品名
SR2L2	S-Spec
3.40GHZ	ベースクロック
X012C345	FPO（Batch Number）
(e4)	ATPOではない

Intel公式情報でも、Core i7-6700の製品版にはS-Spec SR2L2、R0ステッピングが存在します。また、i7-6700のベースクロックは3.40GHzです。

したがって、ここまでの表面刻印には矛盾がありません。

FPOとは？

FPOは「Finished Process Order」の略で、IntelではBatch Numberとして扱われています。

今回のCPUでは、

X012C345

がFPOだとします。

FPOはヒートスプレッダ上にあります。

ここで重要なのは、SR2L2とは別物ということです。

SR2L2    → S-Spec
X012C345 → FPO

IntelのWarranty InformationでもFPOは「Batch number」として入力します。

ATPOとは？

ATPOは「Assembly Test Process Order」の略で、CPUのSerial Numberとして扱われています。

FPOがバッチ番号なのに対して、ATPOは個々のプロセッサを識別するための番号です。

Intel CPUでは、基板外周に非常に小さな2D Matrixがあります。

この2D Matrixをデコードすると、Full ATPO（完全なシリアル番号）を取得できます。

2D Matrixをスマートフォンで読み取る

今回、iPhoneではApp Storeの「Code Scan - QR & Barcode Scanner」を使用すると読み取ることができました。

https://apps.apple.com/jp/app/code-scan-qr-barcode-scanner/id1554812545

Intel CPUのコードは非常に小さいため、通常のQRコードリーダーではうまく認識されない場合があります。Intelも、スマートフォンのカメラを利用する対応アプリで2D Matrixを読み取れると案内しています。

読み取り時は、

CPU表面の汚れを落とす
明るい場所で撮影する
反射する場合は光を斜めから当てる
コードにピントを合わせる
必要ならマクロ撮影する
2D Matrix以外の部分を暗めの紙や物で隠し、コード部分と基板とのコントラストを高くする

と成功しやすくなります。

特に今回試した範囲では、コード以外の部分を暗いもので覆い、2D Matrixだけが目立つ状態にすると認識しやすくなりました。

CPU基板には文字や配線パターン、金属部分などがあり、カメラから見ると2D Matrix以外にも細かな模様が多数存在します。そのため、周囲を暗く隠して読み取らせたいコードだけを目立たせる方法は、スキャンが安定しない場合に試す価値があります。

今回のi7-6700では、この方法も併用しながらiPhoneでスキャンしたところ、アプリから次のような結果が得られました。

U6SG012345678

必要なのはContent側です。

したがって、このCPUのFull ATPOは、

U6SG012345678

となります。

なお、Hexは別のシリアル番号ではありません。

例えば、

55 → U
36 → 6
53 → S
47 → G

というように、Contentの文字列を16進数で表現したものです。

Partial ATPOを探す

次に、CPU基板の外周をよく確認します。

今回のCPUには、

という非常に小さな文字が印刷されていました。

これがPartial ATPOです。

IntelによるとPartial ATPOは、Full ATPOの末尾3～5文字です。

そこで先ほどData Matrixから読み取ったFull ATPOと比較します。

Full ATPO
U6SG012345678
        ↓↓↓↓↓
        45678

基板上のPartial ATPO
45678

末尾5文字が完全に一致しました。

これは重要なチェックポイントです。

Intel自身も偽造CPUを確認する手順として、2D MatrixからFull ATPOを読み取り、その末尾5文字とCPU外周に印刷されたPartial ATPOを比較し、正規品なら一致することを確認するよう案内しています。

つまり今回のCPUでは、

Data Matrix
     ↓
U6SG012345678
        ↓
      45678
        ↑
基板上の「45678」

という対応が確認できました。

少なくとも、基板上のData Matrixと人間が読めるPartial ATPOは正しく対応しています。

ヒートスプレッダと基板は直接照合できるのか？

ここが今回調べていて特に気になった部分です。

ヒートスプレッダ側には、

i7-6700
SR2L2
X012C345

があります。

一方、基板側には、

Full ATPO:
U6SG012345678

Partial ATPO:
45678

があります。

整理すると、

【ヒートスプレッダ】
i7-6700
SR2L2
FPO: X012C345
       │
       │ ← 本来この対応を確認したい
       │
【CPU基板】
Full ATPO: U6SG012345678
Partial ATPO: 45678

という構造です。

Full ATPOとPartial ATPOについては、

U6SG012345678
        ↓↓↓↓↓
        45678

と物理的に確認できます。

しかし、

FPO X012C345
      ↕
ATPO U6SG012345678

について、ユーザーが番号から計算して確認できる公開された規則は見当たりません。

IntelのWarranty Informationが正常に検索できれば、FPOとATPOを組み合わせて確認できますが、今回のi7-6700では検索結果が得られませんでした。

そのため、ヒートスプレッダが本当にこの基板に元々取り付けられていたものなのかを、刻印だけで100％証明するところまでは到達できませんでした。

「別CPUにi7-6700のヒートスプレッダを載せた偽物」はどう確認する？

例えば、

別のCPU基板
   ＋
i7-6700と書かれたヒートスプレッダ

という偽装を考えます。

この場合、表面を見るだけではi7-6700に見えてしまいます。

そこで有効なのがCPU内部の識別情報です。

Intel自身も、CPUをPCに搭載できる場合はIntel Processor Diagnostic Toolを使用し、

Genuine Intel: Pass

となること、および製品名が一致することを確認する方法を案内しています。

さらにCPU-ZやHWiNFOなどで、

Core i7-6700
Skylake
4コア8スレッド
8MB L3
R0ステッピング
CPUIDがSkylakeとして整合

などを確認すれば、「ヒートスプレッダにはi7-6700と書いてあるが、中身は別CPU」という単純な偽装はかなり見抜きやすくなります。

これはベンチマークのスコア比較とは異なり、CPU自身が返す識別情報を確認する方法です。

今回の結果

今回のCore i7-6700では、

チェック	結果
表面にi7-6700と刻印	○
S-Spec `SR2L2`	Intel公式情報と一致
3.40GHz	Intel公式仕様と一致
FPO `X012C345`	確認
2D Matrix	読み取り成功
Full ATPO	取得成功
Partial ATPO	`45678`
Full ATPO末尾	`45678`
Full/Partial ATPO	5文字完全一致
Warranty Information	製品を発見できず
FPOとATPOのIntel DB照合	未確認

したがって、今回確認できた範囲では、正規のCore i7-6700と矛盾する情報は見つかりませんでした。

特に、

Data Matrixから取得したFull ATPOの末尾5文字と、基板に直接印刷されたPartial ATPOが一致した

ことは強い確認材料です。

ただし、Intel Warranty InformationでFPOとATPOの組み合わせを確認できなかったため、

「ヒートスプレッダと基板が工場出荷時から同じ組み合わせだった」ことまで完全に証明できたわけではありません。

中古Intel CPUを確認するときの手順まとめ

性能測定を使わず確認するなら、次の順番が実用的だと思います。

① CPU表面の型番を確認
        ↓
② S-SpecをIntel公式情報と照合
        ↓
③ FPOを記録
        ↓
④ 基板外周の2D Matrixをスキャン
        ↓
⑤ Full ATPOを取得
        ↓
⑥ 基板上のPartial ATPOを探す
        ↓
⑦ Full ATPO末尾3～5文字と比較
        ↓
⑧ Intel Warranty Informationに
   FPO + ATPOを入力
        ↓
⑨ PCに搭載できるなら
   Intel Processor Diagnostic Toolで
   Genuine Intelと製品名を確認

特に④～⑦は、CPUを動作させなくても確認できます。

注意：ATPOは公開しない方がよい

ATPOはCPUのSerial Numberです。

ブログやフリマサイトなどで写真を公開する場合は、

U6SG0123*****

のように一部を隠しておいた方がよいでしょう。

Data Matrixそのものを鮮明な写真で公開すると、文字を隠していてもコードからFull ATPOを読み取れる可能性があるため、Data Matrixにもモザイクをかけるのが安全です。

まとめ

Intel CPUには、単に「Core i7」と書かれているだけではなく、

S-Spec → FPO → Data Matrix → Full ATPO → Partial ATPO

という複数の識別情報があります。

今回のi7-6700では、

SR2L2
FPO: X012C345
Full ATPO: U6SG0123*****
Partial ATPO: 45678

まで確認でき、Full ATPOとPartial ATPOの対応も確認できました。

中古CPUの真贋確認ではベンチマーク結果だけを見るのではなく、こうした物理的なトレーサビリティ情報を相互照合する方法も有効です。

ただし、これだけで半導体の真正性を暗号学的に証明できるわけではありません。特に古いCPUではIntelの現行Warranty検索で結果が得られない場合もあるため、

物理刻印の整合性 + ATPOの整合性 + CPU内部の識別情報

を組み合わせて判断するのが現実的です。

How to Remove Specific Files from Git Commit History

vast cow — Tue, 01 Sep 2026 05:52:58 +0000

When working with Git, you might encounter a situation where you want to:

"Make it as if this file was never committed in the first place."

If you simply delete the file from the current branch, you can use git rm and commit. However, this only removes the file from the current state; it remains in the past commit history.

This article introduces a method using interactive rebase (git rebase --committer-date-is-author-date　-i) to remove changes related to a specific file from past commits.

Please note that this method rewrites the commit history. Be cautious when using it on branches that have already been pushed to a remote repository or are shared among multiple people.

1. Find the Commits Related to the Target File

First, identify the commits in which the file you want to remove was added or modified.

If you know the file path, run the following command:

git log --oneline --name-status -- path/to/file

If you don't know the exact name or path of the target file, you can check the commits and the files that were changed together:

git log --oneline --name-status

The important thing here is the status displayed on the left side of the file.

A    path/to/file
M    path/to/file

You mainly need to check the following two:

A: The file was newly added.
M: An existing file was modified.

The approach will differ depending on this distinction.

2. Rebase from the Oldest Commit Related to the Target File

After identifying the commits related to the target file, find the oldest commit among them.

If that commit is earliest_commit_id, start the interactive rebase as follows:

git rebase --committer-date-is-author-date -i {oldest_commit_id}^

The ^ is added to include the target commit itself in the rebase range.

For example, if the oldest commit is abc1234, then:

git rebase --committer-date-is-author-date　-i abc1234^

3. Change the Target Commit to `drop` or `edit`

When you run the command, an editor will open and display the list of commits.

pick abc1234 add config
pick def5678 update config
pick ghi9012 implement feature

From here, you will modify the commits related to the target file.

If the Commit Only Changes That File

Since the commit itself is unnecessary, change pick to drop.

drop abc1234 add config

This will remove the commit itself from the history.

However, do not use drop if the commit contains changes you want to keep.

If the Commit Includes Changes to Other Files

Since you want to keep the changes to other files, you cannot delete the commit itself.

In this case, change pick to edit.

edit abc1234 implement feature

When you start the rebase, the process will temporarily stop at that commit.

At this point, remove only the changes related to the target file.

4. Remove Changes to the Target File from the `edit` Commit

From here, the operation changes depending on whether the target file was newly added or an existing file was modified in that commit.

If the File Was Newly Added

If the file was newly added in that commit, delete the file.

git rm path/to/file

Then, recreate the commit.

git commit --amend

Modify the commit message as needed.

If an Existing File Was Modified

If the target file was modified in that commit, revert the target file to its state in the commit immediately before that commit.

git restore --source={commit_id}^ --staged --worktree -- path/to/file

For example, if the target commit is abc1234, then:

git restore --source=abc1234^ --staged --worktree -- path/to/file

This will remove the changes to the target file that were included in that commit.

Next, modify the commit.

git commit --amend

If there are any descriptions about the target file in the commit message, modify them here as appropriate.

5. Continue the Rebase

After finishing the commit modification, continue the rebase.

git rebase --continue

If there are multiple commits that you changed to edit, the process will stop again at the next edit.

Each time, repeat the following:

Remove the changes to the target file.
git commit --amend.
git rebase --continue.

If you complete all the steps, the rebase will be finished.

Finally, Check the History

After the rebase is complete, confirm that the history related to the target file is as intended.

git log --name-status -- path/to/file

Also, check:

git status

and

git log --oneline

to be sure about the overall state of the branch.

Caution: If You Have Already Pushed

git rebase --committer-date-is-author-date　-i is an operation that rewrites past commits.

Therefore, if you have already pushed the target commit to a remote repository, the commit IDs will be different between the local and remote repositories after the rebase.

If you need to reflect the rewritten history in the remote repository, you will need to perform a force push.

git push --force-with-lease

It is safer to use --force-with-lease instead of --force, as it is less likely to overwrite changes that others have added to the remote repository.

However, rewriting the history of a shared branch will affect other developers. If you are working on a branch that is used by a team, be sure to check the scope of the impact before running it.

Summary

If you want to remove changes related to a specific file from the commit history, follow these steps:

Find the commits related to the target file.
        ↓
Start git rebase --committer-date-is-author-date -i from the oldest commit.
        ↓
If the commit is unnecessary, use drop.
        ↓
If it includes other changes, use edit.
        ↓
Remove only the changes to the target file.
        ↓
git commit --amend.
        ↓
git rebase --continue.

The key is to use drop if you can delete the commit, and edit if you only want to delete part of the commit.

Also, if using edit, check whether the target file was "newly added" or "modified to an existing file" in that commit before proceeding.

Using interactive rebase, you can remove changes related to a specific file from past commits while keeping other changes.

Gitのコミット履歴から特定のファイルだけ「なかったこと」にする方法

Gitで作業していると、

「このファイル、そもそもコミットしたこと自体をなかったことにしたい」

というケースがあります。

単純に現在のブランチからファイルを削除するだけなら git rm してコミットすれば済みます。しかし、それでは過去のコミット履歴にはファイルが残ったままです。

この記事では、interactive rebase（git rebase --committer-date-is-author-date -i）を使って、特定のファイルに関する変更を過去のコミットから取り除く方法を紹介します。

なお、この方法はコミット履歴を書き換えます。すでにリモートへ push しているブランチや、複数人で共有しているブランチで実行する場合は注意してください。

1. 対象ファイルに関係するコミットを探す

まず、削除したいファイルがどのコミットで追加・変更されたのかを確認します。

ファイルパスがわかっている場合は、次のコマンドを実行します。

git log --oneline --name-status -- path/to/file

対象ファイルの正確な名前やパスがわからない場合は、コミットと変更されたファイルをまとめて確認します。

git log --oneline --name-status

ここで重要なのが、ファイルの左側に表示されるステータスです。

A    path/to/file
M    path/to/file

主に確認するのは次の2つです。

A：ファイルが新規追加された
M：既存ファイルが変更された

後ほど、この違いによって対応方法が変わります。

2. 一番古い対象コミットからrebaseする

対象ファイルに関係するコミットを洗い出したら、その中で一番古いコミットを確認します。

そのコミットを earliest_commit_id とすると、次のように interactive rebase を開始します。

git rebase --committer-date-is-author-date -i {oldest_commit_id}^

^ を付けているのは、対象コミット自身を rebase の範囲に含めるためです。

たとえば対象となる最古のコミットが abc1234 なら、

git rebase --committer-date-is-author-date　-i abc1234^

となります。

3. 対象コミットをdropまたはeditに変更する

コマンドを実行すると、エディターが開いてコミット一覧が表示されます。

pick abc1234 add config
pick def5678 update config
pick ghi9012 implement feature

ここから、対象ファイルに関係するコミットを修正していきます。

そのファイルだけを変更しているコミットの場合

そのコミット自体が不要なので、pick を drop に変更します。

drop abc1234 add config

これによって、そのコミット自体が履歴から削除されます。

ただし、同じコミットに残したい変更が含まれている場合は drop してはいけません。

他のファイルの変更も含まれている場合

対象ファイル以外の変更は残したいので、コミットそのものを削除することはできません。

その場合は pick を edit に変更します。

edit abc1234 implement feature

rebase を開始すると、そのコミットのところで処理が一時停止します。

そこで、対象ファイルの変更だけを取り除きます。

4. editしたコミットから対象ファイルの変更を取り除く

ここからは、そのコミットで対象ファイルを新規追加したのか、既存ファイルを変更したのかによって操作が変わります。

ファイルを新規追加していた場合

そのコミットでファイル自体を新しく追加していたのであれば、ファイルを削除します。

git rm path/to/file

その後、コミットを作り直します。

git commit --amend

必要に応じてコミットメッセージも修正します。

既存ファイルを変更していた場合

そのコミットで対象ファイルに変更を加えていた場合は、対象ファイルだけをそのコミットの直前の状態に戻します。

git restore --source={commit_id}^ --staged --worktree -- path/to/file

たとえば対象コミットが abc1234 なら、

git restore --source=abc1234^ --staged --worktree -- path/to/file

とします。

これによって、そのコミットに含まれていた対象ファイルの変更を取り除くことができます。

続いてコミットを修正します。

git commit --amend

コミットメッセージに対象ファイルについての記述があれば、ここで適宜修正します。

5. rebaseを続行する

コミットの修正が終わったら、rebaseを続けます。

git rebase --continue

edit にしたコミットが複数ある場合は、次の edit の位置で再び処理が停止します。

そのたびに、

対象ファイルの変更を取り除く
git commit --amend する
git rebase --continue する

という作業を繰り返します。

すべて処理できれば rebase は完了です。

最後に履歴を確認する

rebase が完了したら、対象ファイルに関する履歴が意図したとおりになっているか確認します。

git log --name-status -- path/to/file

あわせて、

git status

や、

git log --oneline

などでブランチ全体の状態も確認しておくと安心です。

注意：すでにpushしている場合

git rebase --committer-date-is-author-date　-i は過去のコミットを書き換える操作です。

そのため、対象コミットをすでにリモートへ push している場合、rebase 後はローカルとリモートでコミットIDが異なる状態になります。

リモート側にも書き換え後の履歴を反映する必要がある場合は force push が必要になります。

git push --force-with-lease

--force よりも、他の人がリモートへ追加した変更を誤って上書きしにくい --force-with-lease を使うほうが安全です。

ただし、共有ブランチの履歴を書き換えると他の開発者にも影響します。チームで使用しているブランチの場合は、実行前に影響範囲を確認しておきましょう。

まとめ

特定のファイルに関する変更だけをコミット履歴から取り除きたい場合は、次の流れになります。

対象ファイルに関係するコミットを調べる
        ↓
一番古いコミットから git rebase --committer-date-is-author-date　-i
        ↓
不要なコミットなら drop
        ↓
他の変更も含むなら edit
        ↓
対象ファイルの変更だけ取り除く
        ↓
git commit --amend
        ↓
git rebase --continue

ポイントは、コミット単位で消してよいなら drop、コミットの一部だけ消したいなら edit と使い分けることです。

また、edit の場合は対象ファイルがそのコミットで「新規追加されたもの」なのか「既存ファイルへの変更」なのかを確認してから操作します。

interactive rebase を使えば、他の変更を残したまま、特定のファイルに関する変更だけを過去のコミットから取り除くことができます。

How to Use a Japanese Keyboard (JIS Layout) in GRUB: Rocky Linux / RHEL Compatible

vast cow — Sun, 30 Aug 2026 07:46:21 +0000

How to Use a Japanese Keyboard (JIS Layout) in GRUB: Rocky Linux / RHEL Compatible

When working with the GRUB menu or command line, you may encounter issues where the keyboard is treated as a US layout.

This is particularly problematic with Japanese keyboards, as:

These symbols are located in different positions on US and JIS layouts, making it quite inconvenient to edit kernel parameters or enter commands in GRUB.

This article summarizes how to change the GRUB keyboard layout to the Japanese JIS layout on RHEL-based Linux distributions such as Rocky Linux, AlmaLinux, RHEL, and CentOS Stream.

Note that the "Japanese keyboard" referred to here does not refer to the Japanese input IME. It is not intended to enable Japanese character input in GRUB, but rather to configure it to match the physical key layout of a JIS keyboard.

Linux Keyboard Settings and GRUB Keyboard Settings Are Different

Normally, you can change the Linux console keymap with the following command:

localectl set-keymap jp

Alternatively, you can specify it in the kernel parameters or configuration file, such as:

vconsole.keymap=jp

However, these are settings that take effect after the Linux kernel has booted.

Since GRUB runs before Linux, the Linux keyboard settings are not reflected in GRUB.

In other words, in the boot sequence:

GRUB
  ↓
Linux kernel
  ↓
systemd / console

The keyboard layout for GRUB must be configured within GRUB itself.

Packages Required for Rocky Linux / RHEL

In Rocky Linux and RHEL-based systems, GRUB-related commands have grub2- prefixes.

Install the necessary packages:

sudo dnf install grub2-tools-extra kbd

The following commands are mainly used:

grub2-kbdcomp
grub2-mkconfig

Use grub2-kbdcomp to create a keyboard layout file that GRUB can read.

Create a Japanese Keymap for GRUB

First, create a save location:

sudo mkdir -p /boot/grub2/layouts

Next, create the Japanese JIS layout keymap:

sudo grub2-kbdcomp -o /boot/grub2/layouts/jp.gkb jp

Verify that it was created:

ls -l /boot/grub2/layouts/jp.gkb

If a file exists as follows, the preparation is complete:

/boot/grub2/layouts/jp.gkb

In GRUB, the keyboard layout is changed by loading this .gkb file.

Temporarily Change to JIS Layout Only During GRUB Boot

Instead of making a permanent change all at once, it is recommended to first load it temporarily from the GRUB command line and verify that it works.

When the GRUB menu is displayed, press:

to enter the GRUB command line.

Execute the following command:

insmod keylayouts
keymap jp

This will change to the Japanese JIS layout for that GRUB session only.

Since it will revert to the original upon reboot, it is suitable for testing the settings.

If `keymap jp` Cannot Be Loaded

Check the prefix used by GRUB:

echo $prefix

For example, it may display:

(hd0,gpt2)/grub2

Next, check if the keymap is visible:

ls $prefix/layouts/

If:

jp.gkb

is displayed, GRUB can access the file.

In this case, it should normally be loaded with:

keymap jp

Depending on the environment, you may want to explicitly specify the file to confirm:

keymap $prefix/layouts/jp.gkb

Make the JIS Layout Permanent

Once you have verified that it works, incorporate it into the GRUB configuration.

On RHEL-based systems, appending to /etc/grub.d/40_custom is a clear method.

sudo vi /etc/grub.d/40_custom

Add the following content:

insmod keylayouts
keymap ${prefix}/layouts/jp.gkb

Alternatively, depending on the environment, the following specification may also work:

insmod keylayouts
keymap jp

Personally, I prefer to explicitly specify it so that it is clear which file is being used:

keymap ${prefix}/layouts/jp.gkb

This makes it easier to troubleshoot.

Regenerate grub.cfg

After changing the settings, regenerate the GRUB configuration.

On newer RHEL-based systems such as Rocky Linux 9:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Reboot:

sudo reboot

In the GRUB menu, press c to open the command line and check the symbol keys.

For example:

@
:
"
\
_

If these can be entered as they are printed on the keycaps, the JIS layout has been applied.

Notes for UEFI Environments

Older articles mention examples of running grub2-mkconfig directly on the following file in UEFI environments:

/boot/efi/EFI/redhat/grub.cfg

In Rocky Linux, it may be:

/boot/efi/EFI/rocky/grub.cfg

However, in recent RHEL-based systems, the UEFI grub.cfg is configured to be used as a stub to load the main /boot/grub2/grub.cfg.

Therefore, in Rocky Linux 9 and later, it is generally recommended to use:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

It is safer not to directly overwrite the UEFI grub.cfg unnecessarily.

Is `terminal_input at_keyboard` Necessary?

In GRUB keyboard configuration examples, you may see settings like:

insmod at_keyboard
terminal_input at_keyboard

However, on USB keyboards and UEFI environments, explicitly switching the input path to at_keyboard may prevent keyboard input.

If you only want to change to the JIS layout, it is safest to first try:

insmod keylayouts
keymap ${prefix}/layouts/jp.gkb

Unless there is a specific reason, it is not necessary to change the input terminal itself.

Temporary Change vs. Permanent Change

To summarize, the following applies:

Method	Setting	After Reboot
GRUB command line	`insmod keylayouts` → `keymap jp`	Reverts
Add to `40_custom`	`keymap ${prefix}/layouts/jp.gkb`	Persists
Linux `localectl`	Changes only the Linux console	Does not affect GRUB

It is safe to test with a temporary change first, and then make it permanent if there are no problems.

Can I Change to the JIS Layout in GRUB Without Creating a `.gkb` File?

Basically, no.

The keymap command in GRUB is designed to load pre-created GRUB keyboard layout files.

Therefore, during Linux startup, you need to:

grub2-kbdcomp

to create:

jp.gkb

in advance.

At a minimum, you need to perform the following preparations on the Linux side:

sudo mkdir -p /boot/grub2/layouts
sudo grub2-kbdcomp -o /boot/grub2/layouts/jp.gkb jp

After that, you can always run:

insmod keylayouts
keymap jp

in the GRUB command line to temporarily switch to the JIS layout.

Summary

When setting GRUB to a Japanese JIS keyboard layout on Rocky Linux or RHEL, the key points are:

First, create a GRUB keymap:

sudo dnf install grub2-tools-extra kbd
sudo mkdir -p /boot/grub2/layouts
sudo grub2-kbdcomp -o /boot/grub2/layouts/jp.gkb jp

If you want to try it temporarily in GRUB:
```
insmod keylayouts
keymap jp
```

To make it permanent, add to /etc/grub.d/40_custom:

insmod keylayouts
keymap ${prefix}/layouts/jp.gkb

and run:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

GRUB runs before Linux boots, so the localectl set-keymap jp and other Linux settings are completely separate.

If you frequently edit kernel parameters or perform rescue operations in GRUB, setting up the JIS keyboard will make it much easier to operate.

GRUBで日本語キーボード（JIS配列）を使う方法：Rocky Linux / RHEL系対応

GRUBのメニューやコマンドラインを操作していると、キーボードがUS配列として扱われて困ることがあります。

特に日本語キーボードでは、

などの記号位置がUS配列とJIS配列で異なるため、GRUB上でカーネルパラメータを編集したり、コマンドを入力したりする際にかなり不便です。

この記事では、Rocky Linux、AlmaLinux、RHEL、CentOS StreamなどのRHEL系Linuxで、GRUBのキーボードレイアウトを日本語JIS配列に変更する方法をまとめます。

なお、ここでいう「日本語キーボード」は日本語入力IMEのことではありません。GRUB上で日本語文字を入力できるようにするものではなく、物理的なJISキーボードのキー配置に合わせるための設定です。

Linuxのキーボード設定とGRUBのキーボード設定は別物

通常、Linux側のコンソールキーマップは次のようなコマンドで変更できます。

localectl set-keymap jp

あるいはカーネルパラメータや設定ファイルで、

vconsole.keymap=jp

のように指定することもあります。

しかし、これらはLinuxカーネルが起動した後の設定です。

GRUBはLinuxより前に動作しているため、Linux側のキーボード設定はGRUBには反映されません。

つまり、

GRUB
  ↓
Linux kernel
  ↓
systemd / console

という起動順序において、GRUB用のキーボードレイアウトはGRUB自身に設定する必要があります。

Rocky Linux / RHEL系で必要なパッケージ

Rocky LinuxやRHEL系では、GRUB関連コマンドの名前に grub2- が付いています。

必要なパッケージをインストールします。

sudo dnf install grub2-tools-extra kbd

主に使用するのは次のコマンドです。

grub2-kbdcomp
grub2-mkconfig

grub2-kbdcomp を使って、GRUBが読み込めるキーボードレイアウトファイルを作成します。

GRUB用の日本語キーマップを作成する

まず保存先を作ります。

sudo mkdir -p /boot/grub2/layouts

続いて、日本語JIS配列のキーマップを作成します。

sudo grub2-kbdcomp -o /boot/grub2/layouts/jp.gkb jp

生成できたか確認します。

ls -l /boot/grub2/layouts/jp.gkb

例えば次のようにファイルが存在していれば準備完了です。

/boot/grub2/layouts/jp.gkb

GRUBでは、この .gkb ファイルを読み込むことでキーボード配列を変更します。

まずはGRUB起動中だけ一時的にJIS配列へ変更する

いきなり永続設定を変更するより、最初はGRUBのコマンドラインから一時的に読み込んで動作確認するのがおすすめです。

GRUBメニューが表示されたら、

を押してGRUBコマンドラインに入ります。

次のコマンドを実行します。

insmod keylayouts
keymap jp

これで、そのGRUBセッション中だけ日本語JIS配列になります。

再起動すれば元に戻るため、設定テストにも向いています。

`keymap jp` で読み込めない場合

GRUBが使用している prefix を確認します。

echo $prefix

例えば、

(hd0,gpt2)/grub2

のように表示されることがあります。

次に、キーマップが見えるか確認します。

ls $prefix/layouts/

ここで、

jp.gkb

が表示されれば、GRUBからファイルにアクセスできています。

その場合は通常、

keymap jp

で読み込めます。

環境によっては明示的にファイルを指定して確認してもよいでしょう。

keymap $prefix/layouts/jp.gkb

永続的にJIS配列へ変更する

動作確認できたら、GRUBの設定に組み込みます。

RHEL系では /etc/grub.d/40_custom に追記する方法が分かりやすいです。

sudo vi /etc/grub.d/40_custom

次の内容を追加します。

insmod keylayouts
keymap ${prefix}/layouts/jp.gkb

あるいは、環境によっては次のような指定でも動作します。

insmod keylayouts
keymap jp

個人的には、どのファイルを使用しているか分かりやすいので、

keymap ${prefix}/layouts/jp.gkb

のように明示しておく方がトラブルシュートしやすいでしょう。

grub.cfgを再生成する

設定を変更したら、GRUB設定を再生成します。

Rocky Linux 9などの比較的新しいRHEL系では、

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

を使用します。

再起動します。

sudo reboot

GRUBメニューで c を押してコマンドラインを開き、記号キーを確認します。

例えば、

@
:
"
\
_

などがキートップの刻印どおり入力できれば、JIS配列が適用されています。

UEFI環境での注意点

古い記事を見ると、UEFI環境では次のようなファイルへ直接 grub2-mkconfig を実行する例があります。

/boot/efi/EFI/redhat/grub.cfg

Rocky Linuxでは、

/boot/efi/EFI/rocky/grub.cfg

となっている場合があります。

ただし、最近のRHEL系ではUEFI側の grub.cfg は、本体となる /boot/grub2/grub.cfg を読み込むためのスタブとして使用される構成があります。

そのため、Rocky Linux 9などでは基本的に、

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

を使用します。

UEFI側の grub.cfg を不用意に直接上書きしない方が安全です。

`terminal_input at_keyboard` は必要か

GRUBのキーボード設定例では、

insmod at_keyboard
terminal_input at_keyboard

といった設定を見かけることがあります。

ただし、USBキーボードやUEFI環境では、入力経路を明示的に at_keyboard へ切り替えることで、逆にキーボード入力ができなくなる場合があります。

JIS配列へ変更するだけであれば、まずは、

insmod keylayouts
keymap ${prefix}/layouts/jp.gkb

だけで試すのが無難です。

特別な理由がない限り、入力端末そのものを変更する必要はありません。

一時変更と永続変更の違い

整理すると、次のようになります。

方法	設定	再起動後
GRUBコマンドライン	`insmod keylayouts` → `keymap jp`	元に戻る
`40_custom`へ追加	`keymap ${prefix}/layouts/jp.gkb`	維持される
Linuxの `localectl`	Linuxコンソールのみ変更	GRUBには影響しない

まず一時変更でテストし、問題がなければ永続設定にするのが安全です。

`.gkb`を作らずGRUBだけでJIS配列へ変更できるか

基本的にはできません。

GRUB上の keymap コマンドは、あらかじめ作成されたGRUB用キーマップファイルを読み込む仕組みです。

そのため、Linux起動中に、

grub2-kbdcomp

を使って、

jp.gkb

を事前に作っておく必要があります。

最低限、次の準備だけはLinux側で行います。

sudo mkdir -p /boot/grub2/layouts
sudo grub2-kbdcomp -o /boot/grub2/layouts/jp.gkb jp

その後であれば、GRUB起動中にいつでも、

insmod keylayouts
keymap jp

と実行して、一時的にJIS配列へ切り替えられます。

まとめ

Rocky LinuxやRHEL系でGRUBを日本語JISキーボード配列にする場合、ポイントは次の3つです。

まずGRUB用のキーマップを作ります。

sudo dnf install grub2-tools-extra kbd
sudo mkdir -p /boot/grub2/layouts
sudo grub2-kbdcomp -o /boot/grub2/layouts/jp.gkb jp

GRUB上で一時的に試す場合は、

insmod keylayouts
keymap jp

とします。

永続化する場合は /etc/grub.d/40_custom に、

insmod keylayouts
keymap ${prefix}/layouts/jp.gkb

を追加し、

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

を実行します。

GRUBはLinux起動前に動作するため、localectl set-keymap jp などのLinux側設定とは完全に別です。

GRUB上で頻繁にカーネルパラメータを編集したり、レスキュー操作をしたりする環境では、JISキーボードの設定を入れておくとかなり操作しやすくなります。

How to Temporarily Change the Keyboard Layout

vast cow — Sun, 30 Aug 2026 07:29:13 +0000

In a Linux desktop environment, you can temporarily change the keyboard layout using the setxkbmap command.

This is useful if you want to use a US keyboard layout or switch back to a Japanese layout.

Changing to the US Layout

To change the keyboard layout to the US layout, run the following command:

setxkbmap us

This will use the US layout in the current login session.

Changing to the Japanese Layout

To change to the Japanese layout, run the following command:

setxkbmap jp

This can also be used to switch back to the Japanese layout after changing to the US layout.

Checking the Current Settings

To check the keyboard layout currently in use, run the following command:

setxkbmap -query

You can check the current layout by looking at the layout item in the displayed output.

For example, it will display us for the US layout or jp for the Japanese layout.

Note that the Change is Temporary

Changes made with setxkbmap are generally temporary.

Logging out or restarting may revert to the original keyboard layout set by the distribution or desktop environment.

If you want to use the same keyboard layout after logging in, you need to configure a permanent setting. The configuration method varies depending on the distribution you are using, such as Ubuntu, Xubuntu, Debian, or Arch Linux.

If you just want to temporarily switch layouts, it is convenient to remember the three commands: setxkbmap us, setxkbmap jp, and setxkbmap -query.

一時的にキーボードレイアウトを変更する方法

Linuxのデスクトップ環境では、setxkbmapコマンドを使うことで、キーボードレイアウトを一時的に変更できます。

US配列のキーボードを使いたい場合や、日本語配列に戻したい場合に便利です。

US配列に変更する

キーボードレイアウトをUS配列に変更するには、次のコマンドを実行します。

setxkbmap us

実行すると、現在のログインセッションでUS配列が使用されます。

日本語配列に変更する

日本語配列に変更する場合は、次のコマンドを実行します。

setxkbmap jp

US配列に変更したあと、日本語配列へ戻したい場合にも使用できます。

現在の設定を確認する

現在使用しているキーボードレイアウトを確認するには、次のコマンドを実行します。

setxkbmap -query

表示された内容のうち、layoutの項目を見ることで、現在のレイアウトを確認できます。

たとえば、US配列の場合はus、日本語配列の場合はjpと表示されます。

一時的な変更であることに注意

setxkbmapによる変更は基本的に一時的なものです。

ログアウトや再起動をすると、ディストリビューションやデスクトップ環境で設定されている元のキーボードレイアウトに戻ることがあります。

ログイン後も同じキーボードレイアウトを使用したい場合は、永続的な設定が必要です。設定方法はUbuntuやXubuntu、Debian、Arch Linuxなど、使用しているディストリビューションによって異なります。

一時的にレイアウトを切り替えたいだけであれば、setxkbmap us、setxkbmap jp、setxkbmap -queryの3つを覚えておくと便利です。

Using Multiple GitHub Accounts: Automatically Select the Correct `gh` PAT Based on Repo Owner

vast cow — Wed, 26 Aug 2026 07:16:37 +0000

When using multiple GitHub accounts, the process of selecting the correct Personal Access Token (PAT) for git push or git pull over HTTPS can be a bit cumbersome.

Specifically, when dealing with repositories from multiple owners, such as:

https://github.com/aont/foo.git
https://github.com/another-user/bar.git

Git Credential Manager or gh auth git-credential might default to the currently active account, leading to errors like:

remote: Permission to owner/repo.git denied to other-user.

To address this, the owner portion of the remote URL is interpreted as the GitHub CLI account name, and a credential helper is embedded directly into the .gitconfig file. This helper retrieves the PAT using:

gh auth token --user OWNER

and provides it to Git.

This eliminates the need for external scripts.

Prerequisites

First, ensure that you are logged into your GitHub accounts using gh:

gh auth login

If you have multiple accounts registered, you can verify them with:

gh auth status

With this method, if a repository URL is:

https://github.com/aont/foo.git

the command:

gh auth token --user aont

will be executed.

Therefore, the basic assumption is:

repository owner = gh registered account name

`.gitconfig`

The configuration should be as follows:

[credential]
    useHttpPath = true

[credential "https://github.com/"]
    helper =
    helper = "!f() { \
        [ \"$1\" = get ] || exit 0; \
        account=''; \
        while IFS='=' read -r k v; do \
            [ \"$k\" = path ] && account=${v%%/*}; \
        done; \
        [ -n \"$account\" ] || exit 0; \
        token=$(gh auth token --user \"$account\") || exit 0; \
        printf 'username=%s\\npassword=%s\\n' \"$account\" \"$token\"; \
    }; f"

[credential "https://gist.github.com/"]
    helper =
    helper = "!f() { \
        [ \"$1\" = get ] || exit 0; \
        account=''; \
        while IFS='=' read -r k v; do \
            [ \"$k\" = path ] && account=${v%%/*}; \
        done; \
        [ -n \"$account\" ] || exit 0; \
        token=$(gh auth token --user \"$account\") || exit 0; \
        printf 'username=%s\\npassword=%s\\n' \"$account\" \"$token\"; \
    }; f"

There are three key points:

`credential.useHttpPath = true` is Important

Typically, Git's credential helper receives only:

protocol=https
host=github.com

However, in this case, we need:

aont/foo.git

the path.

Therefore, set:

[credential]
    useHttpPath = true

This causes the path to be passed to the credential helper's standard input, such as:

protocol=https
host=github.com
path=aont/foo.git

Use the Beginning of the Path as the Account

Inside the helper, the first element of the path is extracted using:

[ "$k" = path ] && account=${v%%/*}

For example, if:

path=aont/foo.git

then:

account=aont

After that, the corresponding PAT for that account is retrieved from the GitHub CLI using:

token=$(gh auth token --user "$account")

Therefore, when accessing:

https://github.com/aont/foo.git

the command:

gh auth token --user aont

is automatically executed.

Conversely, for:

https://github.com/another-user/bar.git

the command:

gh auth token --user another-user

is executed.

There is no need to run gh auth switch every time.

Reset Existing Credential Helpers with `helper =`

Another important point is:

helper =

On Git for Windows, for example, Git Credential Manager or gh auth git-credential might already be configured.

If another helper returns the credentials first, this helper might not be executed.

As a result, you might encounter an error like:

remote: Permission to foo/bar.git denied to wrong-account.

Therefore, use:

helper =
helper = "!f() { ... }; f"

The first empty helper = resets any previously configured credential helpers, and then only this helper is registered.

This is crucial when dealing with multiple GitHub accounts.

Use the Same Mechanism for Gists

The same credential helper can be configured for Gists.

However, the standard Gist clone URL is:

https://gist.github.com/GIST_ID.git

and the username cannot be determined from the URL.

Therefore, in this setup, the Gist remote URL is intentionally formatted as:

https://gist.github.com/USER/GIST_ID.git

For example, if:

https://gist.github.com/aont/0123456789abcdef.git

then, from the credential helper's perspective:

path=aont/0123456789abcdef.git

so, the command:

gh auth token --user aont

is automatically used.

This allows you to treat GitHub repositories and Gists with the same rules.

github.com/USER/REPO
gist.github.com/USER/GIST
                ↓
             USER is extracted
                ↓
gh auth token --user USER

Verification

You can check which credentials Git is actually retrieving using git credential fill.

For example, run:

printf '%s\n' \
  'protocol=https' \
  'host=github.com' \
  'path=aont/foo.git' \
  '' |
git credential fill

The expected output is:

protocol=https
host=github.com
username=aont
password=...

If the username is a different account, you can check if another credential helper is still present using:

git config --show-origin --get-all credential.helper

Why Not Use `gh auth git-credential` Directly?

The GitHub CLI has a standard command:

gh auth git-credential

This is sufficient for normal single-account usage.

However, when using multiple accounts with the same host (github.com), you might want to explicitly control which gh account is used based on the repository owner.

This helper uses a very simple rule:

remote URL
  ↓
owner is extracted
  ↓
gh auth token --user owner

so you don't need to be aware of which account is currently active in gh.

Advantages of This Configuration

This method does not save the PAT itself in the .gitconfig file.

The PAT is retrieved each time it is needed using:

gh auth token --user ACCOUNT

Therefore, the configuration only saves the rule for which account to use.

Additionally, you do not need to run:

gh auth switch

or set:

git config credential.username ...

for each repository.

The remote URL itself becomes the credential routing information.

Summary

When using multiple GitHub accounts over HTTPS, using the account portion of:

github.com/<account>/<repo>

directly for selecting the gh account can simplify operations.

The mechanism is:

Git remote URL
  ↓
credential.useHttpPath
  ↓
path=owner/repo.git
  ↓
owner is extracted
  ↓
gh auth token --user owner
  ↓
username/password is returned to Git

If you have multiple personal accounts and the relationship:

repository owner = GitHub account

holds true, this method is quite easy to use.

For organization-owned repositories where:

owner != account used for authentication

you will need separate mappings, but this configuration is sufficient for primarily personal accounts.

GitHub複数アカウント運用で、repo ownerから自動的にghのPATを選ぶ

GitHubで複数アカウントを使っていると、HTTPSでのgit pushやgit pull時に「どのアカウントのPATを使うか」が地味に面倒です。

特に、

https://github.com/aont/foo.git
https://github.com/another-user/bar.git

のように複数ownerのrepositoryを扱っていると、Git Credential Managerやgh auth git-credentialが現在のアクティブアカウントを使ってしまい、

remote: Permission to owner/repo.git denied to other-user.

のようなエラーになることがあります。

そこで、remote URLのowner部分をそのままGitHub CLIのアカウント名として解釈し、

gh auth token --user OWNER

からPATを取り出してGitに返すcredential helperを.gitconfigへ直接埋め込みます。

外部スクリプトも不要です。

前提

まず、利用するGitHubアカウントはあらかじめghにログインしておきます。

gh auth login

複数アカウントを登録している場合は、

gh auth status

で確認できます。

この方法では、たとえばrepository URLが

https://github.com/aont/foo.git

なら、

gh auth token --user aont

を実行します。

したがって、基本的には

repository owner = ghに登録したaccount名

という運用を前提にします。

`.gitconfig`

設定は次のようにします。

[credential]
    useHttpPath = true

[credential "https://github.com/"]
    helper =
    helper = "!f() { \
        [ \"$1\" = get ] || exit 0; \
        account=''; \
        while IFS='=' read -r k v; do \
            [ \"$k\" = path ] && account=${v%%/*}; \
        done; \
        [ -n \"$account\" ] || exit 0; \
        token=$(gh auth token --user \"$account\") || exit 0; \
        printf 'username=%s\\npassword=%s\\n' \"$account\" \"$token\"; \
    }; f"

[credential "https://gist.github.com/"]
    helper =
    helper = "!f() { \
        [ \"$1\" = get ] || exit 0; \
        account=''; \
        while IFS='=' read -r k v; do \
            [ \"$k\" = path ] && account=${v%%/*}; \
        done; \
        [ -n \"$account\" ] || exit 0; \
        token=$(gh auth token --user \"$account\") || exit 0; \
        printf 'username=%s\\npassword=%s\\n' \"$account\" \"$token\"; \
    }; f"

ポイントは3つあります。

`credential.useHttpPath = true` が重要

通常、Gitのcredential helperには

protocol=https
host=github.com

程度しか渡されません。

しかし今回必要なのは、

aont/foo.git

というpathです。

そこで、

[credential]
    useHttpPath = true

を設定します。

これによってcredential helperの標準入力に、

protocol=https
host=github.com
path=aont/foo.git

のようにpathも渡されます。

pathの先頭をaccountとして使う

helper内では、

[ "$k" = path ] && account=${v%%/*}

として、pathの最初の要素を取得しています。

たとえば、

path=aont/foo.git

なら、

account=aont

になります。

その後、

token=$(gh auth token --user "$account")

で、そのアカウントに対応するPATをGitHub CLIから取得します。

つまり、

https://github.com/aont/foo.git

へのアクセス時は自動的に、

gh auth token --user aont

相当になります。

一方、

https://github.com/another-user/bar.git

なら、

gh auth token --user another-user

になります。

gh auth switchを毎回実行する必要はありません。

`helper =` で既存credential helperをリセットする

もう一つ重要なのが、

helper =

です。

Git for Windowsなどでは、すでにGit Credential Managerやgh auth git-credentialなどが設定されている場合があります。

たとえば別のhelperが先にcredentialを返すと、今回のhelperまで処理が回ってきません。

その結果、

remote: Permission to foo/bar.git denied to wrong-account.

のようになります。

そこで、

helper =
helper = "!f() { ... }; f"

とします。

最初の空のhelper =で、それ以前に設定されていたcredential helperをリセットし、その後に今回のhelperだけを登録しています。

複数GitHubアカウントを扱う場合には、この部分がかなり重要です。

Gistにも同じ仕組みを使う

Gistにも同じcredential helperを設定できます。

ただし通常のGist clone URLは、

https://gist.github.com/GIST_ID.git

となっていて、URLからユーザー名を判断できません。

そこで、この運用ではGistのremote URLを意図的に、

https://gist.github.com/USER/GIST_ID.git

という形式にします。

たとえば、

https://gist.github.com/aont/0123456789abcdef.git

なら、credential helperから見ると、

path=aont/0123456789abcdef.git

となるので、

gh auth token --user aont

を自動的に使えます。

つまりGitHub repositoryとGistを同じルールで扱えます。

github.com/USER/REPO
gist.github.com/USER/GIST
                ↓
             USERを抽出
                ↓
gh auth token --user USER

動作確認

Gitが実際にどのcredentialを取得するかは、git credential fillで確認できます。

たとえば、

printf '%s\n' \
  'protocol=https' \
  'host=github.com' \
  'path=aont/foo.git' \
  '' |
git credential fill

を実行します。

期待する出力は、

protocol=https
host=github.com
username=aont
password=...

です。

ここでusernameが別アカウントになっている場合は、

git config --show-origin --get-all credential.helper

で、別のcredential helperが残っていないか確認するとよいです。

なぜ`gh auth git-credential`をそのまま使わないのか

GitHub CLIには標準で、

gh auth git-credential

があります。

通常の単一アカウント運用ならこれで十分です。

ただ、複数アカウントを同一ホストgithub.comで使っている場合、「repository ownerに応じてどのgh accountを使うか」を明示的に制御したくなります。

今回のhelperでは、

remote URL
    ↓
ownerを抽出
    ↓
gh auth token --user owner

という非常に単純な規則にしているため、現在どのアカウントがghでactiveになっているかを意識する必要がありません。

この構成の利点

この方法だとPATそのものを.gitconfigに保存しません。

PATは必要になるたびに、

gh auth token --user ACCOUNT

から取得します。

そのため、設定として保存されるのは「どのアカウントを使うか」というルールだけです。

また、repositoryごとに、

gh auth switch

したり、

git config credential.username ...

を設定したりする必要もありません。

remote URLそのものがcredential routingの情報になります。

まとめ

複数GitHubアカウントをHTTPSで使う場合、

github.com/<account>/<repo>

のaccount部分をそのままghのaccount選択に使うと、かなりシンプルに運用できます。

仕組みとしては、

Git remote URL
  ↓
credential.useHttpPath
  ↓
path=owner/repo.git
  ↓
ownerを抽出
  ↓
gh auth token --user owner
  ↓
username/passwordとしてGitへ返す

だけです。

個人アカウントを複数使っていて、

repository owner = GitHub account

という関係が成立している環境なら、かなり扱いやすい方法だと思います。

Organization配下のrepositoryなどで、

owner != 認証に使うaccount

となる場合だけは別途マッピングが必要ですが、個人アカウント中心ならまずこの構成で十分です。

Using Windows ssh-agent with MSYS2's ssh

vast cow — Wed, 26 Aug 2026 06:58:14 +0000

Using OmniSSHAgent

Windows comes with standard OpenSSH and ssh-agent. MSYS2 also has /usr/bin/ssh, allowing you to use SSH, Git, rsync, and other tools in a Unix-like environment.

The problem is that you can't directly use keys registered in Windows' ssh-agent with MSYS2's ssh.

This article will outline why this problem occurs, what solutions are available, and then introduce a configuration using OmniSSHAgent, which I personally find the easiest to use.

As of August 2026, using OmniSSHAgent is a good first choice for Windows 11 x64 environments.

Conclusion

The configuration is as follows:

MSYS2 /usr/bin/ssh
        │
        │ SSH_AUTH_SOCK
        ▼
Cygwin/MSYS2 compatible socket
        │
        │ OmniSSHAgent
        ▼
Windows OpenSSH ssh-agent
        │
        ▼
Private key

OmniSSHAgent is not an SSH agent that manages private keys itself.

It's a bridge that converts the interface so that you can use the standard Windows OpenSSH Authentication Agent from MSYS2/Cygwin. The current OmniSSHAgent connects to the Windows OpenSSH agent's \\.\pipe\openssh-ssh-agent and publishes a Cygwin/MSYS2 compatible interface.

The advantages of this configuration are:

You can use the standard Windows ssh-agent for key management.
You can use MSYS2's /usr/bin/ssh directly.
Git, scp, rsync, and other tools can use the same agent.
It can start automatically after Windows relogin.
It can also be used with the Pageant interface for PuTTY / WinSCP / TortoiseGit.
OmniSSHAgent itself does not store private keys or passphrases.

Why can't you use Windows' ssh-agent directly?

Windows OpenSSH and MSYS2 OpenSSH both have commands named ssh, so it seems like you should be able to connect directly.

However, the communication methods with the SSH agent are different.

Windows OpenSSH uses Windows Named Pipes.

\\.\pipe\openssh-ssh-agent

On the other hand, MSYS2, Cygwin, and Git for Windows' Unix-like OpenSSH use Cygwin/MSYS2-style sockets via SSH_AUTH_SOCK.

Therefore,

Windows OpenSSH
    ↓
Windows Named Pipe

and

MSYS2 OpenSSH
    ↓
Cygwin/MSYS2 compatible socket

are different.

The OmniSSHAgent README explains that the reason this tool exists is that Windows native OpenSSH, Pageant, and Git for Windows/MSYS2/Cygwin all use incompatible SSH agent interfaces.

Therefore, simply setting

export SSH_AUTH_SOCK='\\.\pipe\openssh-ssh-agent'

in MSYS2 will not solve the problem.

What is needed is a bridge that translates between the protocols/socket formats.

Comparing solutions

There are several ways to use Windows' ssh-agent from MSYS2.

Method	MSYS2 `/usr/bin/ssh`	Ease of Setup	Recommendation
OmniSSHAgent	○	High	★★★★★
sshwin-msys2	○	Relatively High	★★★★☆
socat + npiperelay	○	Somewhat Complex	★★☆☆☆
Use Windows `ssh.exe` directly	×	Very Easy	Depends on Use Case
Directly specify Named Pipe as `SSH_AUTH_SOCK`	×	-	Not Possible

For Windows 11 x64, OmniSSHAgent is the most complete choice at the moment.

What is OmniSSHAgent?

OmniSSHAgent is an SSH agent compatibility bridge for Windows.

In its current design,

Windows OpenSSH Authentication Agent

is used as the only backend for key management.

OmniSSHAgent itself does not:

Store private keys
Store passphrases
Replace Windows' ssh-agent

It specializes in adding a

Pageant
Cygwin/MSYS2

compatible interface to the Windows OpenSSH agent.

This design is quite straightforward.

Key management is centralized in

Windows OpenSSH ssh-agent

and OmniSSHAgent only bridges the clients:

Windows ssh.exe
MSYS2 ssh
Git for Windows
PuTTY
WinSCP
TortoiseGit

Currently, the target environment for OmniSSHAgent MVP is Windows 11 x86-64. Windows 10 and ARM64 are not supported in the current version.

1. Enable Windows ssh-agent

First, enable the standard Windows OpenSSH Authentication Agent.

Open PowerShell with administrator privileges.

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

Check the status.

Get-Service ssh-agent

If it shows Running, it's OK.

The Microsoft official documentation also provides this setting as a way to automatically start Windows' ssh-agent.

2. Register the private key in Windows ssh-agent

For example, for an Ed25519 key:

ssh-add $env:USERPROFILE\.ssh\id_ed25519

Check the registered keys.

ssh-add -l

If it displays something like:

256 SHA256:xxxxxxxxxxxxxxxx user@example (ED25519)

then Windows is ready.

From now on, the main entity managing the keys will be this Windows ssh-agent.

3. Install OmniSSHAgent

The OmniSSHAgent official README provides a PowerShell installer.

Run from PowerShell or PowerShell 7.

irm https://raw.githubusercontent.com/masahide/OmniSSHAgent/main/install.ps1 | iex

The installer will:

Obtain the latest x86-64 release
Verify the SHA-256 checksum
Place it in %LOCALAPPDATA%\Programs\OmniSSHAgent
Create a Start Menu shortcut
Start OmniSSHAgent

Administrator privileges are not required.

If you don't want to run the script directly, you can also install it by checking the release contents from GitHub Releases.

As of August 26, 2026, v0.8.0 is the latest release. v0.8.0 adds tray settings and Windows autostart.

4. Enable the Cygwin/MSYS2 interface

When you start OmniSSHAgent, an icon will appear in the notification area.

From the menu, enable:

Cygwin/MSYS2 interface

The current OmniSSHAgent creates a socket descriptor for MSYS2/Cygwin at:

%USERPROFILE%\.ssh\omnisshagent-cygwin.sock

by default.

5. Set SSH_AUTH_SOCK in MSYS2

Start MSYS2 and run:

export SSH_AUTH_SOCK="$(cygpath -u "$USERPROFILE/.ssh/omnisshagent-cygwin.sock")"

Check it.

echo "$SSH_AUTH_SOCK"

For example:

/c/Users/example/.ssh/omnisshagent-cygwin.sock

Next, run:

ssh-add -l

If the same keys that were registered on the Windows side are displayed, it's successful.

The OmniSSHAgent official README also describes this SSH_AUTH_SOCK setting for MSYS2 / Git Bash / Cygwin.

6. Verify that you are actually using MSYS2's ssh

There may be multiple ssh.exe files on Windows, so it's a good idea to check.

which ssh
which ssh-add

The one you want to use is:

/usr/bin/ssh
/usr/bin/ssh-add

That is:

$ which ssh
/usr/bin/ssh

$ ssh-add -l
256 SHA256:...

If so, communication is happening via:

MSYS2 OpenSSH → OmniSSHAgent → Windows ssh-agent.

7. Automate by adding to .bashrc

You don't need to set SSH_AUTH_SOCK every time.

Add the following to ~/.bashrc:

export SSH_AUTH_SOCK="$(cygpath -u "$USERPROFILE/.ssh/omnisshagent-cygwin.sock")"

Open a new MSYS2 shell and:

ssh-add -l

If it succeeds, you're done.

After restarting/re-logging into Windows

This is another point where OmniSSHAgent is easy to use.

If autostart is configured correctly, you usually don't need to manually start OmniSSHAgent every time you relogin.

Windows ssh-agent

Windows' ssh-agent is set as a service:

Get-Service ssh-agent | Set-Service -StartupType Automatic

so it starts automatically when Windows starts.

OmniSSHAgent

In the notification area, enable:

Start with Windows

This registers autostart for the current user.

Administrator privileges are not required.

This feature was added in OmniSSHAgent v0.8.0.

MSYS2

Add the following to ~/.bashrc:

export SSH_AUTH_SOCK="$(cygpath -u "$USERPROFILE/.ssh/omnisshagent-cygwin.sock")"

so it's automatically set when the MSYS2 shell starts.

Therefore, overall:

Windows startup
    ↓
Windows ssh-agent starts automatically
    ↓
Windows login
    ↓
OmniSSHAgent starts automatically
    ↓
omnisshagent-cygwin.sock is created
    ↓
MSYS2 startup
    ↓
.bashrc sets SSH_AUTH_SOCK
    ↓
/usr/bin/ssh uses Windows ssh-agent

For normal operation, you just start MSYS2 and:

ssh example.com

How to verify after relogin

When problems occur, it's easier to check from the top down.

First, in PowerShell:

Get-Service ssh-agent

Check if it's Running.

ssh-add -l

to check if the keys are visible to the Windows agent.

Next, check if OmniSSHAgent is running in the notification area.

Finally, in MSYS2:

echo "$SSH_AUTH_SOCK"
ssh-add -l

This will make it easier to isolate:

Key problem
Windows ssh-agent problem
OmniSSHAgent problem
MSYS2 environment variable problem

OmniSSHAgent has logging and diagnostics features, and the logs are saved at:

%LOCALAPPDATA%\OmniSSHAgent\logs

Security considerations for OmniSSHAgent

When evaluating OmniSSHAgent, it's important to note that it does not store the private keys themselves.

In the current design:

Private key
    ↓
Windows OpenSSH ssh-agent

The private key is stored there, and OmniSSHAgent only bridges the signing requests.

The official README explains the security model:

Does not store private keys
Does not store passphrases
Does not write SSH agent payloads to logs
Cygwin compatibility listener is bound only to 127.0.0.1
Uses nonce handshake for Cygwin socket descriptor

Of course, even when using an SSH agent, there are SSH agent-specific security considerations regarding "signing requests from processes that can access the agent."

However, centralizing key management in Windows OpenSSH agent is a management advantage compared to registering the same private keys in multiple agents:

Windows agent
MSYS2 agent
Pageant

sshwin-msys2 as an alternative

Another tool, sshwin-msys2, is also available.

This also uses the Windows OpenSSH named pipe as a backend and creates a socket descriptor that MSYS2 can recognize.

In a standard C:\msys64 environment:

C:\MSYS64\tmp\sshwin-msys2.sock

is created, and on the MSYS2 side:

export SSH_AUTH_SOCK=/tmp/sshwin-msys2.sock

is set.

The README also states that it has been tested with Windows 10 build 19044 and MSYS2, Git Bash, and WSL2.

Therefore,

If you are using Windows 10, sshwin-msys2 is also a viable option.

However, for Windows 11 x64, OmniSSHAgent is easier to use because:

Tray application
Cygwin/MSYS2 interface
Pageant interface
Windows autostart
Logging
Diagnostics
Centralization on the Windows OpenSSH backend

What about socat + npiperelay?

Another method often mentioned is combining:

socat
+
npiperelay

to connect Windows Named Pipes and Unix sockets.

Conceptually:

MSYS2 ssh
 ↓
Unix socket
 ↓
socat
 ↓
npiperelay
 ↓
Windows Named Pipe
 ↓
Windows ssh-agent

This is a common method in WSL, but problems may arise with how MSYS2 handles native Windows executables and standard input/output.

In fact, issue #13 in the npiperelay repository describes a case where someone tried to connect from MSYS2 to the Windows OpenSSH agent and encountered:

copy from stdin to pipe failed:
read /dev/stdin: invalid argument

Since the number of components is also increasing, OmniSSHAgent or sshwin-msys2 are simpler solutions if the goal is only MSYS2.

Using Windows ssh.exe directly may be sufficient for Git

If the goal is only:

git clone
git pull
git push

then you don't need to use MSYS2's ssh.

You can make Git use:

C:\Windows\System32\OpenSSH\ssh.exe

directly, which uses the Windows ssh-agent directly.

This method is very simple.

However, if you want to use the MSYS2 OpenSSH itself, such as:

/usr/bin/ssh
scp
sftp
rsync -e ssh

then OmniSSHAgent is more suitable.

About WSL2

Note that the current OmniSSHAgent does not directly bridge the socket for WSL2.

In the current OmniSSHAgent design:

MSYS2 / Cygwin
    → OmniSSHAgent

Pageant
    → OmniSSHAgent

WSL2
    → Pipeferry

the roles are divided.

If you want to use the Windows OpenSSH agent from WSL2, Pipeferry, which is by the same author, is recommended.

Older articles about OmniSSHAgent may mention WSL functionality, so be careful when searching.

Why I recommend OmniSSHAgent

If the premise is Windows 11 x64 + MSYS2, I recommend OmniSSHAgent.

It's not just because "it works."

The design is clearly separated:

Key management
    = Windows OpenSSH ssh-agent

Compatibility conversion
    = OmniSSHAgent

OmniSSHAgent does not create its own key store; it centers on the standard Windows agent.

Then, it bridges the differences in interface:

Windows OpenSSH
MSYS2
Cygwin
Git for Windows
PuTTY系アプリ

Furthermore, with v0.8.0, Windows autostart was added, so:

ssh-agent automatic startup
OmniSSHAgent automatic startup
Set SSH_AUTH_SOCK in .bashrc

is all you need to do, and you usually don't need to be aware of the bridge in daily use.

Final Settings

PowerShell — One-time setup

Administrator PowerShell:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

ssh-add $env:USERPROFILE\.ssh\id_ed25519
ssh-add -l

OmniSSHAgent

From the notification area:

✓ Cygwin/MSYS2 interface
✓ Start with Windows

MSYS2 ~/.bashrc

export SSH_AUTH_SOCK="$(cygpath -u "$USERPROFILE/.ssh/omnisshagent-cygwin.sock")"

Verification

which ssh
ssh-add -l

Expected state:

/usr/bin/ssh

256 SHA256:xxxxxxxxxxxxxxxx ...

This completes the configuration:

MSYS2 /usr/bin/ssh
      ↓
OmniSSHAgent
      ↓
Windows OpenSSH ssh-agent

Summary

When using SSH in both Windows and MSYS2, the SSH agent can end up being double-managed.

For example:

Register the key in Windows ssh-agent
Register the key in MSYS2 ssh-agent

This configuration can make startup and SSH_AUTH_SOCK management more complex.

With OmniSSHAgent, you can:

                ┌─ Windows OpenSSH
                │
Windows          ├─ MSYS2 / Cygwin
OpenSSH agent ───┤
                └─ Pageant compatible apps

This centralizes the Windows OpenSSH agent as the key management center.

In particular, if:

Windows 11 x64
You want to use MSYS2's /usr/bin/ssh
You want to centralize key management in the Windows ssh-agent
You want it to be available automatically after relogin

then OmniSSHAgent is a very user-friendly choice at the moment.

Ultimately, you only need:

export SSH_AUTH_SOCK="$(cygpath -u "$USERPROFILE/.ssh/omnisshagent-cygwin.sock")"

in MSYS2.

I think it's a relatively clean way to resolve the SSH agent issues that often arise at the boundary between Windows and Unix-like tools.

References

OmniSSHAgent README / Architecture / Installation / MSYS2 setup / Security model
OmniSSHAgent Releases — v0.8.0 adds Windows autostart
Microsoft Learn — Automatically starting Windows ssh-agent and ssh-add
sshwin-msys2 — Another implementation for using Windows OpenSSH agent from MSYS2
npiperelay issue #13 — MSYS2 + socat standard input error case

Windows の ssh-agent を MSYS2 の ssh から使う

OmniSSHAgent を使う方法

Windows には標準の OpenSSH と ssh-agent が用意されています。一方、MSYS2 にも /usr/bin/ssh があり、Unix に近い環境で SSH や Git、rsync などを使えます。

ここで問題になるのが、Windows の ssh-agent に登録した鍵を MSYS2 の ssh からそのまま利用できないことです。

この記事では、この問題がなぜ起きるのか、どのような解決策があるのかを整理した上で、個人的に最も扱いやすいと考える OmniSSHAgent を使った構成を紹介します。

2026年8月時点では、Windows 11 x64 環境であれば OmniSSHAgent を使う方法を第一候補にするのがよいでしょう。

結論

先に結論を書くと、構成は次のようにします。

MSYS2 /usr/bin/ssh
        │
        │ SSH_AUTH_SOCK
        ▼
Cygwin/MSYS2互換 socket
        │
        │ OmniSSHAgent
        ▼
Windows OpenSSH ssh-agent
        │
        ▼
秘密鍵

OmniSSHAgent は秘密鍵を独自管理する SSH agent ではありません。

Windows 標準の OpenSSH Authentication Agent をそのまま使い、そのインターフェースを MSYS2/Cygwin から利用できる形に変換するブリッジとして動作します。現在の OmniSSHAgent は Windows OpenSSH agent の \\.\pipe\openssh-ssh-agent に接続し、MSYS2/Cygwin 向けの互換インターフェースを公開します。

この構成の利点は、

Windows 標準 ssh-agent を鍵管理の中心にできる
MSYS2 の /usr/bin/ssh をそのまま使える
Git、scp、rsync なども同じ agent を利用できる
Windows 再ログイン後も自動起動できる
PuTTY / WinSCP / TortoiseGit 用の Pageant インターフェースも利用可能
OmniSSHAgent 自体は秘密鍵やパスフレーズを保存しない

という点です。

なぜ Windows の ssh-agent を直接使えないのか

Windows OpenSSH と MSYS2 OpenSSH は、どちらも ssh という名前なので一見そのまま接続できそうに見えます。

しかし SSH agent との通信方式が異なります。

Windows OpenSSH は Windows の Named Pipe を使用します。

\\.\pipe\openssh-ssh-agent

一方、MSYS2、Cygwin、Git for Windows の Unix 系 OpenSSH は、Cygwin/MSYS2 形式の socket を SSH_AUTH_SOCK 経由で利用します。

つまり、

Windows OpenSSH
    ↓
Windows Named Pipe

と、

MSYS2 OpenSSH
    ↓
Cygwin/MSYS2互換 socket

という違いがあります。

OmniSSHAgent の README でも、Windows ネイティブ OpenSSH、Pageant、Git for Windows/MSYS2/Cygwin がそれぞれ互換性のない SSH agent インターフェースを利用していることが、このツールの存在理由として説明されています。

そのため、単純に MSYS2 で、

export SSH_AUTH_SOCK='\\.\pipe\openssh-ssh-agent'

などと設定しても解決しません。

必要なのは プロトコル／ソケット形式を橋渡しするブリッジです。

解決方法の比較

Windows の ssh-agent を MSYS2 から使う方法はいくつかあります。

方法	MSYS2 `/usr/bin/ssh`	設定の容易さ	おすすめ度
OmniSSHAgent	○	高い	★★★★★
sshwin-msys2	○	比較的高い	★★★★☆
socat + npiperelay	○	やや複雑	★★☆☆☆
Windows `ssh.exe` を直接使う	×	非常に簡単	用途次第
Named Pipe を `SSH_AUTH_SOCK` に直接指定	×	-	不可

Windows 11 x64 なら、現在は OmniSSHAgent が最もまとまりのよい選択肢です。

OmniSSHAgent とは

OmniSSHAgent は Windows 用の SSH agent compatibility bridge です。

現在の設計では、

Windows OpenSSH Authentication Agent

を鍵管理の唯一のバックエンドとして利用します。

OmniSSHAgent 自身が、

秘密鍵を保存する
パスフレーズを保存する
Windows の ssh-agent を置き換える

わけではありません。

Windows OpenSSH agent に対して、

Pageant
Cygwin/MSYS2

という互換インターフェースを追加する役割に特化しています。

これは設計としてかなり分かりやすいです。

鍵管理は、

Windows OpenSSH ssh-agent

に一本化し、

Windows ssh.exe
MSYS2 ssh
Git for Windows
PuTTY
WinSCP
TortoiseGit

などのクライアント側だけを OmniSSHAgent が橋渡しします。

なお、現在の OmniSSHAgent MVP の対象環境は Windows 11 x86-64 です。Windows 10 や ARM64 は現行版の対象外とされています。

1. Windows ssh-agent を有効にする

まず Windows 標準の OpenSSH Authentication Agent を有効にします。

管理者権限で PowerShell を起動します。

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

状態を確認します。

Get-Service ssh-agent

Running になっていれば OK です。

Microsoft 公式ドキュメントでも、Windows の ssh-agent を自動起動する方法としてこの設定が案内されています。

2. 秘密鍵を Windows ssh-agent に登録する

例えば Ed25519 鍵なら、

ssh-add $env:USERPROFILE\.ssh\id_ed25519

登録された鍵を確認します。

ssh-add -l

例えば、

256 SHA256:xxxxxxxxxxxxxxxx user@example (ED25519)

のように表示されれば Windows 側は準備完了です。

今後、鍵を管理する主体は OmniSSHAgent ではなく、この Windows ssh-agent になります。

3. OmniSSHAgent をインストールする

OmniSSHAgent 公式 README では PowerShell installer が用意されています。

PowerShell または PowerShell 7 から実行します。

irm https://raw.githubusercontent.com/masahide/OmniSSHAgent/main/install.ps1 | iex

インストーラは、

最新 x86-64 release の取得
SHA-256 checksum の検証
%LOCALAPPDATA%\Programs\OmniSSHAgent への配置
Start Menu shortcut の作成
OmniSSHAgent の起動

を行います。

管理者権限は不要です。

リモートスクリプトをそのまま実行したくない場合は、GitHub Releases からリリース内容を確認した上で導入する方法でも構いません。

2026年8月26日時点では v0.8.0 が Latest release として公開されています。v0.8.0 では tray settings と Windows autostart が追加されています。

4. Cygwin/MSYS2 interface を有効にする

OmniSSHAgent を起動すると通知領域にアイコンが表示されます。

メニューから、

Cygwin/MSYS2 interface

を有効にします。

現在の OmniSSHAgent はデフォルトで、

%USERPROFILE%\.ssh\omnisshagent-cygwin.sock

に MSYS2/Cygwin 用 socket descriptor を作成します。

5. MSYS2 に SSH_AUTH_SOCK を設定する

MSYS2 を起動して、

export SSH_AUTH_SOCK="$(cygpath -u "$USERPROFILE/.ssh/omnisshagent-cygwin.sock")"

を実行します。

確認します。

echo "$SSH_AUTH_SOCK"

例えば、

/c/Users/example/.ssh/omnisshagent-cygwin.sock

のようになります。

次に重要なのが、

ssh-add -l

です。

Windows 側で登録した鍵と同じものが表示されれば成功です。

OmniSSHAgent 公式 README でも、MSYS2 / Git Bash / Cygwin についてこの SSH_AUTH_SOCK 設定が案内されています。

6. 本当に MSYS2 の ssh を使っているか確認する

Windows には複数の ssh.exe が存在することがあるので、一度確認しておくことをおすすめします。

which ssh
which ssh-add

今回使いたいのは、

/usr/bin/ssh
/usr/bin/ssh-add

です。

つまり、

$ which ssh
/usr/bin/ssh

$ ssh-add -l
256 SHA256:...

となれば、

MSYS2版 OpenSSH → OmniSSHAgent → Windows ssh-agent

という経路で通信できています。

7. .bashrc に設定して自動化する

毎回 SSH_AUTH_SOCK を設定する必要はありません。

~/.bashrc に、

export SSH_AUTH_SOCK="$(cygpath -u "$USERPROFILE/.ssh/omnisshagent-cygwin.sock")"

を追加します。

新しい MSYS2 shell を開いて、

ssh-add -l

が成功すれば完了です。

Windows を再起動・再ログインした場合

ここも OmniSSHAgent をおすすめしやすいポイントです。

自動起動を正しく設定しておけば、普段は再ログインのたびに OmniSSHAgent を手動で起動する必要はありません。

Windows ssh-agent

Windows の ssh-agent はサービスとして、

Get-Service ssh-agent | Set-Service -StartupType Automatic

にしてあります。

そのため Windows 起動時に自動で立ち上がります。

OmniSSHAgent

通知領域の OmniSSHAgent メニューで、

Start with Windows

を有効にします。

これは現在のユーザーに対する autostart を登録します。

管理者権限は不要です。

この機能は OmniSSHAgent v0.8.0 で追加されています。

MSYS2

~/.bashrc に、

export SSH_AUTH_SOCK="$(cygpath -u "$USERPROFILE/.ssh/omnisshagent-cygwin.sock")"

を入れてあるので、MSYS2 shell 起動時に自動設定されます。

したがって全体として、

Windows起動
    ↓
Windows ssh-agent 自動起動
    ↓
Windowsログイン
    ↓
OmniSSHAgent 自動起動
    ↓
omnisshagent-cygwin.sock 作成
    ↓
MSYS2起動
    ↓
.bashrc が SSH_AUTH_SOCK を設定
    ↓
/usr/bin/ssh が Windows ssh-agent を利用

となります。

普段の操作としては、MSYS2 を起動して、

ssh example.com

するだけです。

再ログイン後の確認方法

問題が起きたときは、上流から順番に確認すると分かりやすいです。

まず PowerShell で、

Get-Service ssh-agent

Running か確認します。

次に、

ssh-add -l

で Windows agent に鍵が見えているか確認します。

次に OmniSSHAgent が通知領域で起動しているか確認します。

最後に MSYS2 で、

echo "$SSH_AUTH_SOCK"
ssh-add -l

を確認します。

この順番なら、

鍵の問題
Windows ssh-agent の問題
OmniSSHAgent の問題
MSYS2環境変数の問題

を切り分けやすくなります。

OmniSSHAgent にはログや configuration check 用の機能も用意されており、ログは、

%LOCALAPPDATA%\OmniSSHAgent\logs

に保存されます。

OmniSSHAgent のセキュリティ面

OmniSSHAgent を評価するときに重要なのは、秘密鍵そのものを保持しない点です。

現在の設計では、

秘密鍵
    ↓
Windows OpenSSH ssh-agent

に保持され、

OmniSSHAgent は署名要求などを bridge するだけです。

公式 README では、

秘密鍵を保存しない
passphrase を保存しない
SSH agent payload をログに書かない
Cygwin compatibility listener は 127.0.0.1 のみに bind
Cygwin socket descriptor の nonce handshake を使用

というセキュリティモデルが説明されています。

もちろん SSH agent 自体を利用する以上、「agent にアクセスできるプロセスによる署名要求」という SSH agent 共通のセキュリティ上の考慮は残ります。

それでも、

Windowsのagent
MSYS2のagent
Pageant

などに同じ秘密鍵を何重にも登録するより、Windows OpenSSH agent に一本化できる点は管理上のメリットがあります。

sshwin-msys2 という選択肢

OmniSSHAgent 以外では sshwin-msys2 というツールもあります。

これも Windows OpenSSH の named pipe を backend として利用し、MSYS2 が認識できる socket descriptor を作ります。

標準的な C:\msys64 環境では、

C:\MSYS64\tmp\sshwin-msys2.sock

を作成し、MSYS2 側では、

export SSH_AUTH_SOCK=/tmp/sshwin-msys2.sock

と設定します。

README では Windows 10 build 19044 と MSYS2、Git Bash、WSL2 でのテスト実績も記載されています。

そのため、

Windows 10 を使っている場合は sshwin-msys2 も有力候補

です。

一方、Windows 11 x64 なら、

tray application
Cygwin/MSYS2 interface
Pageant interface
Windows autostart
logging
diagnostics
Windows OpenSSH backend への一本化

までまとまっている OmniSSHAgent の方が使いやすいと考えます。

socat + npiperelay はどうか

Windows Named Pipe と Unix socket を接続する方法として、

socat
+
npiperelay

を組み合わせる方法もよく紹介されています。

概念的には、

MSYS2 ssh
 ↓
Unix socket
 ↓
socat
 ↓
npiperelay
 ↓
Windows Named Pipe
 ↓
Windows ssh-agent

となります。

WSL ではよく利用される方式ですが、MSYS2 では native Windows executable と MSYS2 の標準入出力の扱いが問題になる場合があります。

実際、npiperelay の issue には MSYS2 から Windows OpenSSH agent に接続しようとして、

copy from stdin to pipe failed:
read /dev/stdin: invalid argument

となった事例があります。

構成要素も増えるので、MSYS2 だけが目的なら、現在は OmniSSHAgent や sshwin-msys2 の方が素直です。

Git だけなら Windows ssh.exe を使う手もある

目的が、

git clone
git pull
git push

だけなら、そもそも MSYS2 の ssh を使わない方法もあります。

Windows の、

C:\Windows\System32\OpenSSH\ssh.exe

を Git に使わせれば Windows ssh-agent を直接利用できます。

この方法は bridge が不要なので非常に単純です。

ただし、

/usr/bin/ssh
scp
sftp
rsync -e ssh

など MSYS2 OpenSSH 自体を利用したい場合には解決になりません。

MSYS2 の Unix 的な環境を維持したい場合は OmniSSHAgent の方が適しています。

WSL2 について

注意点として、現在の OmniSSHAgent は WSL2 の socket bridge を直接担当しません。

OmniSSHAgent の現在の設計では、

MSYS2 / Cygwin
    → OmniSSHAgent

Pageant
    → OmniSSHAgent

WSL2
    → Pipeferry

と役割が分けられています。

WSL2 から Windows OpenSSH agent を使う場合は、同じ作者による Pipeferry が案内されています。

古い OmniSSHAgent の記事では WSL 機能も紹介されている場合があるため、検索時には注意が必要です。

OmniSSHAgent をおすすめする理由

Windows 11 x64 + MSYS2 という前提なら、OmniSSHAgent をおすすめします。

理由は単に「動くから」だけではありません。

設計が、

鍵管理
    = Windows OpenSSH ssh-agent

互換性変換
    = OmniSSHAgent

と明確に分離されているからです。

OmniSSHAgent は独自の鍵ストアを作るのではなく、Windows 標準の agent を中心に据えます。

その上で、

Windows OpenSSH
MSYS2
Cygwin
Git for Windows
PuTTY系アプリ

のインターフェース差だけを吸収します。

さらに v0.8.0 では Windows autostart が入ったため、

ssh-agent 自動起動
OmniSSHAgent 自動起動
SSH_AUTH_SOCK を .bashrc に設定

まで行えば、日常的には bridge の存在を意識する必要がほぼありません。

最終的な設定

PowerShell — 一度だけ

管理者 PowerShell：

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

ssh-add $env:USERPROFILE\.ssh\id_ed25519
ssh-add -l

OmniSSHAgent

通知領域から、

✓ Cygwin/MSYS2 interface
✓ Start with Windows

を有効にします。

MSYS2 ~/.bashrc

export SSH_AUTH_SOCK="$(cygpath -u "$USERPROFILE/.ssh/omnisshagent-cygwin.sock")"

動作確認

which ssh
ssh-add -l

期待する状態：

/usr/bin/ssh

256 SHA256:xxxxxxxxxxxxxxxx ...

これで、

MSYS2 /usr/bin/ssh
      ↓
OmniSSHAgent
      ↓
Windows OpenSSH ssh-agent

という構成が完成します。

まとめ

Windows と MSYS2 の両方で SSH を使っていると、SSH agent が二重管理になりがちです。

例えば、

Windows ssh-agent に鍵を登録
MSYS2 ssh-agent にも鍵を登録

という構成にすると、起動処理や SSH_AUTH_SOCK の管理も複雑になります。

OmniSSHAgent を使えば、

                ┌─ Windows OpenSSH
                │
Windows          ├─ MSYS2 / Cygwin
OpenSSH agent ───┤
                └─ Pageant互換アプリ

という形で、Windows OpenSSH agent を SSH 鍵管理の中心にできます。

特に、

Windows 11 x64
MSYS2 の /usr/bin/ssh を使いたい
Windows の ssh-agent に鍵管理を一本化したい
再ログイン後も自動で利用可能にしたい

という環境なら、現時点では OmniSSHAgent が非常に扱いやすい選択肢です。

MSYS2 側に必要なのは最終的に、

export SSH_AUTH_SOCK="$(cygpath -u "$USERPROFILE/.ssh/omnisshagent-cygwin.sock")"

だけです。

Windows と Unix 系ツールの境界でありがちな SSH agent 問題を、比較的きれいに解消できる構成だと思います。

参考資料

OmniSSHAgent README / Architecture / Installation / MSYS2 setup / Security model
OmniSSHAgent Releases — v0.8.0 で Windows autostart を追加
Microsoft Learn — Windows OpenSSH ssh-agent の自動起動と ssh-add
sshwin-msys2 — MSYS2 から Windows OpenSSH agent を利用する別実装
npiperelay issue #13 — MSYS2 + socat での標準入力エラー事例

What is the "Alerts" Syntax You Can Use in GitHub Markdown?

vast cow — Wed, 26 Aug 2026 06:55:58 +0000

When reading GitHub READMEs or Issues, you may come across syntax like this:

> [!IMPORTANT]
> **If you are upgrading from a previous version**
>
> The configuration method has changed.
> Please check the migration procedure before upgrading.

This is not a regular Markdown quote; it's a Markdown extension called Alerts that GitHub supports.

On GitHub, it is displayed as a note box with icons and decorations according to the type, such as IMPORTANT.

It's Not Standard Markdown

First, it's important to understand this part:

This is the standard Markdown quote syntax.

On the other hand,

[!IMPORTANT]

is not part of the standard Markdown specification. It is interpreted as having a special meaning.

Therefore,

> [!IMPORTANT]
> This is important information.

is a GitHub-specific extension syntax that utilizes Markdown's quote syntax.

As a result, while it may be displayed as a note box on GitHub, it may be displayed as a simple quote in other Markdown renderers.

Alert Types You Can Use

GitHub mainly supports the following five types of Alerts:

NOTE

Use this to indicate supplementary information.

> [!NOTE]
> This setting is optional.

TIP

Use this to indicate convenient methods or recommended ways of doing things.

> [!TIP]
> You can easily check the settings using this command.

IMPORTANT

Use this for important information that users should definitely know.

> [!IMPORTANT]
> Back up your configuration file before upgrading.

WARNING

Use this to alert users to operations that may cause problems.

> [!WARNING]
> This operation will overwrite existing settings.

CAUTION

Use this for operations that involve particularly serious risks, such as data loss.

> [!CAUTION]
> Running this command will delete saved data.

Writing Multiple Lines

If you want to write multiple lines of text within an Alert, add a > to each line.

> [!IMPORTANT]
> The configuration method has changed.
>
> Before upgrading,
> check the new configuration method.

If you want to insert a blank line, write:

This is the same mechanism as a standard Markdown blockquote.

You Can Also Use Bold Text and Links

You can also use standard Markdown syntax within Alerts.

> [!IMPORTANT]
> **Check before upgrading**
>
> See the [Migration Guide](docs/migration.md) for details.

This is useful when you want to guide readers to important documents in the README.

When Should You Use It?

Alerts are useful for making the text in a README easier to read and organize.

For example:

Notes for upgrading
Breaking changes
Security notes
Configuration notes
Common mistakes
Recommended settings

In particular,

## Upgrade

This describes how to upgrade.

> [!IMPORTANT]
> The configuration file format has changed in version 2 and later.

Run the following command.

Using it this way clearly separates the main text from important information.

Be Careful Not to Overuse It

Although it is a useful syntax, if you use Alerts for all information, you will end up making it difficult to distinguish the importance of each item.

For example, if a README is filled with:

> [!NOTE]
> ...

> [!TIP]
> ...

> [!IMPORTANT]
> ...

> [!WARNING]
> ...

like a box full of notes, it will be difficult to determine what to read.

Basically, use regular text, and use Alerts only for information you really want to highlight.

The Display May Change Outside of GitHub

Another thing to keep in mind when using this syntax is the environment in which it will be displayed.

On GitHub,

> [!IMPORTANT]
> Important information

is displayed as a dedicated Alert.

However, in Markdown renderers that do not support this syntax, it may be displayed as a regular quote:

[!IMPORTANT]
Important information

Therefore, while this syntax is easy to use for documents intended to be read on GitHub, such as GitHub READMEs, you need to be aware of compatibility when displaying documents in various Markdown processing systems.

Summary

The syntax you see on GitHub, such as

> [!IMPORTANT]

is a Markdown extension called Alerts.

The > is the standard Markdown quote syntax, but the part that interprets [!IMPORTANT] and so on as a special note box is not included in standard Markdown.

On GitHub READMEs and Issues, it is a useful way to visually highlight important information.

The types you can use are:

NOTE
TIP
IMPORTANT
WARNING
CAUTION

When writing important notes in a README, using this Alerts syntax can convey the priority of information more clearly than just using bold text.

GitHubのMarkdownで使える「Alerts」記法とは？

GitHub の README や Issue を読んでいると、次のような記法を見かけることがあります。

> [!IMPORTANT]
> **以前のバージョンからアップグレードする場合**
>
> 設定方法が変更されています。
> アップグレード前に移行手順を確認してください。

これは通常の Markdown の引用ではなく、GitHub がサポートしている Alerts という Markdown 拡張です。

GitHub 上では、IMPORTANT のような種類に応じてアイコンや装飾が付いた注意ボックスとして表示されます。

標準Markdownではない

まず押さえておきたいのは、次の部分です。

これは標準的な Markdown の引用記法です。

一方、

[!IMPORTANT]

を特別な意味として解釈する仕組みは、標準 Markdown の仕様ではありません。

つまり、

> [!IMPORTANT]
> 重要な情報です

という記法は、Markdown の引用構文を利用した GitHub独自の拡張記法です。

そのため、GitHub では注意ボックスとして表示されても、別の Markdown レンダラーでは単なる引用として表示される場合があります。

使用できるAlertの種類

GitHub では、主に次の5種類の Alert が利用できます。

NOTE

補足情報を示したい場合に使います。

> [!NOTE]
> この設定は省略可能です。

TIP

便利な方法やおすすめの使い方を示す場合に使います。

> [!TIP]
> このコマンドを使うと設定を簡単に確認できます。

IMPORTANT

ユーザーに必ず知っておいてほしい重要事項に使います。

> [!IMPORTANT]
> アップグレード前に設定ファイルをバックアップしてください。

WARNING

問題が発生する可能性がある操作について注意を促す場合に使います。

> [!WARNING]
> この操作を行うと既存の設定が上書きされます。

CAUTION

データ損失など、特に重大なリスクを伴う操作に使います。

> [!CAUTION]
> このコマンドを実行すると保存済みデータが削除されます。

複数行を書く場合

Alert の中に複数行の文章を書く場合は、それぞれの行に > を付けます。

> [!IMPORTANT]
> 設定方法が変更されています。
>
> アップグレードする前に、
> 新しい設定方法を確認してください。

空行を入れたい場合も、

と書きます。

通常の Markdown の blockquote と同じ仕組みです。

太字やリンクも使える

Alert の中では、通常の Markdown 記法も利用できます。

> [!IMPORTANT]
> **アップグレードする前に確認してください**
>
> 詳細は[移行ガイド](docs/migration.md)を参照してください。

README の中で重要なドキュメントへ誘導するときには便利です。

どんな場面で使うとよいか

Alerts は、README の文章を読みやすく整理するのに向いています。

たとえば、

バージョンアップ時の注意事項
破壊的変更
セキュリティ上の注意
設定時の補足
よくあるミス
推奨設定

などです。

特に、

## Upgrade

アップグレード方法について説明します。

> [!IMPORTANT]
> バージョン2以降では設定ファイルの形式が変更されています。

次のコマンドを実行します。

のように使うと、通常の本文と重要事項を明確に分けられます。

使いすぎには注意

便利な記法ですが、すべての情報を Alert にしてしまうと、かえって重要度が分かりにくくなります。

たとえば README が、

> [!NOTE]
> ...

> [!TIP]
> ...

> [!IMPORTANT]
> ...

> [!WARNING]
> ...

のような注意ボックスだらけになると、どこを読むべきなのか判断しづらくなります。

基本的には通常の文章を使い、本当に目立たせたい情報だけを Alert にするのがよいでしょう。

GitHub以外では表示が変わる可能性がある

この記法を使う場合にもう一つ注意したいのが、表示する環境です。

GitHub 上では、

> [!IMPORTANT]
> 重要な情報

が専用の Alert として表示されます。

しかし、この記法に対応していない Markdown レンダラーでは、

[!IMPORTANT]
重要な情報

という普通の引用として表示される可能性があります。

そのため、GitHub README のように GitHub上で読むことを前提とした文書では使いやすい記法ですが、さまざまな Markdown 処理系で表示する文書では互換性を意識する必要があります。

まとめ

GitHub で見かける、

> [!IMPORTANT]

という記法は、GitHub の Alerts と呼ばれる Markdown 拡張です。

> は標準 Markdown の引用記法ですが、[!IMPORTANT] などを特別な注意ボックスとして解釈する部分は標準 Markdown には含まれていません。

GitHub の README や Issue では、重要事項を視覚的に目立たせる方法として便利です。

利用できる種類は、

NOTE
TIP
IMPORTANT
WARNING
CAUTION

の5種類です。

README に重要な注意事項を書くときは、単純な太字だけでなく、この Alerts 記法を使うと情報の優先度をより分かりやすく伝えられます。

How to Safely Manually Edit the Bash History File

vast cow — Mon, 24 Aug 2026 13:52:31 +0000

Bash command history is normally stored in $HISTFILE (in many environments, ~/.bash_history).

Sometimes you may want to edit this file directly in an editor, for example to delete a batch of unwanted history entries.

However, care is required in environments where multiple Bash sessions are open at the same time. If you simply edit $HISTFILE, your changes may later be overwritten by history held by another Bash session.

This article outlines a procedure for editing the history file as safely as possible while keeping multiple Bash sessions open.

Bash History Exists Both in Memory and in a File

The first thing to understand is that Bash history is not managed solely through $HISTFILE.

Each running Bash process independently keeps its own history in memory.

For example, if Bash is running in three terminals, the situation looks like this:

Bash A ── history in memory
Bash B ── history in memory
Bash C ── history in memory
              ↓
         $HISTFILE

Therefore, when directly editing $HISTFILE, you need to consider not only the file itself, but also the history held by each Bash process.

First, Write Out the History from All Sessions and Disable History Recording

First, run the following in every Bash session that is currently open:

history -a
set +o history

history -a appends history entries from that Bash session that have not yet been saved to $HISTFILE.

In other words, by running it in every session, you can collect each session's unsaved history into the file:

Bash A ─┐
Bash B ─┼─ history -a → $HISTFILE
Bash C ─┘

The next command,

set +o history

temporarily disables history recording in that Bash session.

The key point is to run this in every session as well.

Edit the History File from One Session

Once you have run

history -a
set +o history

in every Bash session, edit $HISTFILE from one of them.

For example, with Emacs:

emacsclient -nw "$HISTFILE"

Of course, you can use any editor you like.

vim "$HISTFILE"

"${EDITOR:-vi}" "$HISTFILE"

will work as well.

Make the necessary changes, such as deleting unwanted history entries, and save the file.

Reload the History in Every Session After Editing

Simply editing the file does not remove the pre-edit history still held in memory by Bash processes that are already running.

Therefore, run the following again in every Bash session:

history -c
history -r "$HISTFILE"
set -o history

Each command has the following meaning.

history -c

clears the history currently held in memory by that Bash process.

Next,

history -r "$HISTFILE"

loads the edited $HISTFILE.

Finally,

set -o history

re-enables history recording.

This puts the sessions into the following state:

              edited $HISTFILE
                    │
          history -r│
          ┌─────────┼─────────┐
          ↓         ↓         ↓
       Bash A    Bash B    Bash C

All sessions will now operate using the edited history as their baseline.

Summary of the Procedure

1. Run in every Bash session

history -a
set +o history

2. Edit the history in one Bash session

"${EDITOR:-vi}" "$HISTFILE"

3. Run in every Bash session

history -c
history -r "$HISTFILE"
set -o history

That is the basic procedure.

Why Use `history -a` Instead of `history -w`?

At first glance, it may seem safer to run

history -w "$HISTFILE"

before editing.

However, caution is required when multiple Bash sessions exist.

history -w rewrites $HISTFILE using the history currently held in memory by the current Bash process.

For example, suppose you have:

Bash A history: A1 A2 A3
Bash B history: B1 B2 B3

Even if Bash B's history has already been written to $HISTFILE, Bash A may not have loaded it.

If you then run

history -w "$HISTFILE"

from Bash A, the file will be rewritten based on the history known to Bash A, potentially causing history originating from other sessions to be lost.

By contrast,

history -a

appends unsaved history entries.

Therefore, when collecting history from multiple sessions,

history -a

is more appropriate.

Even This Is Not "Perfect"

Following the procedure above makes the operation considerably safer, but strictly speaking, it is not foolproof.

The Bash history file is not a transactional database designed for concurrent updates from multiple Bash processes.

In other words, if a new command is executed in another session while you are running

history -a

in each session, or if writes to the history file overlap, timing-dependent problems can still occur.

Also, commands executed after

set +o history

will not be recorded in that session's normal history.

Therefore, it is best to avoid continuing normal work while editing the history.

The Most Reliable Approach Is to Close the Other Bash Sessions

If reliability is the priority, there is a simpler approach.

Close every Bash session except the one you will use to edit the history.

The fact that multiple processes are accessing the same $HISTFILE is itself the source of potential conflicts, so reducing

Bash A
Bash B
Bash C

Bash A

before editing the history substantially reduces the number of issues you need to account for.

In other words:

Want to keep multiple sessions open → write out the history from every session, disable recording, edit, and reload it in every session.
Prioritize reliability → close the other Bash sessions before editing.

Conclusion

If you want to edit $HISTFILE while keeping multiple Bash sessions open, the following procedure is practical.

Before editing, in every session:

history -a
set +o history

In one session:

"${EDITOR:-vi}" "$HISTFILE"

After editing, in every session:

history -c
history -r "$HISTFILE"
set -o history

The important point is not to stop after editing $HISTFILE itself.

Each Bash process independently keeps its own history in memory. Therefore, the underlying idea is to collect each session's unsaved history into $HISTFILE before editing, and then synchronize every session with the contents of the edited $HISTFILE afterward.

However, Bash history management does not provide strong mutual exclusion between multiple processes. If you need to edit the history with maximum reliability, the simplest approach is to close the other Bash sessions before doing so.

Bashの履歴ファイルを安全に手動編集する方法

Bash のコマンド履歴は通常 $HISTFILE（多くの環境では ~/.bash_history）に保存されています。

不要な履歴をまとめて削除したい場合など、このファイルを直接エディタで編集したくなることがあります。

ただし、複数の Bash セッションを同時に開いている環境では注意が必要です。単純に $HISTFILE を編集すると、別の Bash セッションが持っている履歴によって、後から編集内容が上書きされる可能性があります。

この記事では、複数の Bash セッションを開いたまま、履歴ファイルをできるだけ安全に編集する手順を整理します。

Bashの履歴には「メモリ」と「ファイル」がある

まず押さえておきたいのは、Bash の履歴が単純に $HISTFILE だけで管理されているわけではないことです。

実行中の各 Bash プロセスは、それぞれ独立して履歴をメモリ上に保持しています。

例えば3つのターミナルで Bash を起動している場合、

Bash A ── メモリ上の履歴
Bash B ── メモリ上の履歴
Bash C ── メモリ上の履歴
              ↓
         $HISTFILE

という状態になります。

そのため $HISTFILE を直接編集する場合は、ファイルだけではなく、各 Bash プロセスが持っている履歴も考慮する必要があります。

まず全セッションの履歴を書き出して記録を停止する

最初に、現在開いているすべての Bash セッションで次を実行します。

history -a
set +o history

history -a は、その Bash セッションでまだ履歴ファイルに保存されていない履歴を $HISTFILE に追記します。

つまり、全セッションで実行することで、

Bash A ─┐
Bash B ─┼─ history -a → $HISTFILE
Bash C ─┘

という形で、それぞれの未保存履歴をファイルに集められます。

続く

set +o history

は、その Bash セッションでの履歴記録を一時的に無効化します。

これも全セッションで実行するのがポイントです。

1つのセッションから履歴ファイルを編集する

すべての Bash セッションで

history -a
set +o history

を実行したら、1つのセッションから $HISTFILE を編集します。

例えば Emacs なら、

emacsclient -nw "$HISTFILE"

もちろんエディタは何でも構いません。

vim "$HISTFILE"

や

"${EDITOR:-vi}" "$HISTFILE"

でも構いません。

ここで不要な履歴を削除するなど、必要な編集を行って保存します。

編集後は全セッションの履歴を再読み込みする

ファイルを編集しただけでは、既に起動している Bash のメモリ上には編集前の履歴が残っています。

そこで、再びすべての Bash セッションで次を実行します。

history -c
history -r "$HISTFILE"
set -o history

それぞれの意味は次のとおりです。

history -c

現在の Bash がメモリ上に保持している履歴をクリアします。

続いて、

history -r "$HISTFILE"

編集済みの $HISTFILE を読み込みます。

最後に、

set -o history

で履歴記録を再び有効化します。

これによって各 Bash セッションは、

              編集済み $HISTFILE
                    │
          history -r│
          ┌─────────┼─────────┐
          ↓         ↓         ↓
       Bash A    Bash B    Bash C

という状態になり、全セッションが編集済みの履歴を基準に動作するようになります。

手順をまとめると

1. 全 Bash セッションで実行

history -a
set +o history

2. 1つの Bash セッションで履歴を編集

"${EDITOR:-vi}" "$HISTFILE"

3. 全 Bash セッションで実行

history -c
history -r "$HISTFILE"
set -o history

これが基本的な流れです。

なぜ `history -w` ではなく `history -a` なのか

一見すると、編集前に

history -w "$HISTFILE"

を実行した方が確実そうに見えます。

しかし、複数の Bash セッションが存在する場合には注意が必要です。

history -w は、現在の Bash がメモリ上に持っている履歴を使って $HISTFILE を書き直します。

例えば、

Bash A の履歴: A1 A2 A3
Bash B の履歴: B1 B2 B3

という状態で、Bash B の履歴が $HISTFILE に反映されていても、Bash A がそれを読み込んでいない可能性があります。

その状態で Bash A から

history -w "$HISTFILE"

すると、Bash A が知っている履歴を基準にファイルが書き直され、他セッション由来の履歴を失う可能性があります。

これに対して、

history -a

は未保存の履歴を追記します。

そのため複数セッションから履歴を集める用途では、

history -a

を使う方が適しています。

それでも「完全」ではない

ここまで行えばかなり安全ですが、厳密には完全な方法ではありません。

Bash の履歴ファイルは、複数の Bash プロセスから同時に更新するためのトランザクショナルなデータベースではありません。

つまり、

history -a

を各セッションで実行している最中に別セッションで新しいコマンドが実行されたり、履歴ファイルへの書き込みが競合したりすれば、タイミング依存の問題が発生する余地があります。

また、

set +o history

を実行した後のコマンドは、そのセッションの通常の履歴には記録されません。

したがって、履歴編集作業中に通常の作業を続けるのは避けた方がよいでしょう。

最も確実なのは他の Bash を終了すること

確実性を優先するなら、もっと単純な方法があります。

履歴を編集する Bash 以外のセッションを終了してしまうことです。

複数プロセスが同じ $HISTFILE を扱っていること自体が競合の原因なので、

Bash A
Bash B
Bash C

を

Bash A

だけにしてから履歴を編集すれば、考慮すべき問題は大幅に減ります。

つまり、

複数セッションを維持したい → 全セッションで履歴を書き出し、停止・再読み込みする
確実性を優先したい → 他の Bash セッションを終了してから編集する

という使い分けになります。

結論

複数の Bash セッションを開いたまま $HISTFILE を編集するなら、次の手順が実用的です。

編集前に全セッションで

history -a
set +o history

1セッションで

"${EDITOR:-vi}" "$HISTFILE"

編集後に全セッションで

history -c
history -r "$HISTFILE"
set -o history

重要なのは、$HISTFILE だけを編集して終わりにしないことです。

各 Bash プロセスはそれぞれ独立した履歴をメモリ上に保持しています。そのため、編集前には各セッションの未保存履歴を $HISTFILE に集約し、編集後には全セッションを編集済み $HISTFILE の内容に同期する、という考え方になります。

ただし Bash の履歴管理には複数プロセス間の強力な排他制御があるわけではありません。履歴を確実に編集する必要がある場合は、他の Bash セッションを終了してから作業する方法が最もシンプルです。

How to Squash Past Commits with Git Rebase

vast cow — Mon, 24 Aug 2026 08:20:38 +0000

Squashing commits with Git’s rebase command is useful when you want to clean up your commit history. Here’s a step-by-step guide.

1. Check Which Commits to Squash

First, review the commit log to decide which commits you want to combine:

git log --oneline

Example:

a1b2c3d Fix typo
d4e5f6g Add feature X
h7i8j9k WIP: implement feature X
...

Suppose you want to squash Add feature X and WIP: implement feature X.

2. Start an Interactive Rebase

Run git rebase -i using the commit before the ones you want to squash as the base:

git rebase -i <base_commit_id>

In this case, if a1b2c3d is the commit before, you would run:

git rebase -i a1b2c3d

3. Edit the Commit List

Your editor will open with something like this:

pick d4e5f6g Add feature X
pick h7i8j9k WIP: implement feature X

Change the second pick to squash (or just s):

pick d4e5f6g Add feature X
squash h7i8j9k WIP: implement feature X

4. Edit the Commit Message

Next, Git will prompt you to combine commit messages:

# This is a combination of 2 commits.
# The first commit’s message is:
Add feature X

# The following commit message will also be included:
WIP: implement feature X

Clean it up so the final message is concise:

Add feature X

5. Finish the Rebase

Save and close the editor. Git will apply the rebase and squash the commits into one.

6. Troubleshooting

If you hit conflicts: resolve them as usual, then run:

  git add <fixed_files>
  git rebase --continue

If you want to cancel the rebase:

  git rebase --abort

After rewriting history: if the branch is pushed to a remote you will need to force-push the rewritten history:

  git push --force-with-lease

(Prefer --force-with-lease over --force when collaborating.)

7. Squashing Including the Root Commit (`--root`)

By default git rebase -i <base> rebases starting after the specified base commit. If you want to include the very first (root) commit in an interactive rebase — for example to edit or squash the initial commit together with later commits — use the --root option:

git rebase -i --root

What this does

Lists the root (initial) commit as the first entry in the interactive todo.
Lets you pick, reword, edit, squash, or fixup the root commit just like any other commit.
Rewrites the root and all descendant commits (so every commit ID in the branch will change).

Common uses & examples

Squash all commits into a single initial commit If you want a single commit that contains the whole history, keep the root as pick and mark every other commit as squash (or s):

   pick a1b2c3d Initial commit
   squash d4e5f6g Add feature X
   squash h7i8j9k WIP: implement feature X
   ...

After saving, Git will open the combined commit-message editor so you can craft the final message.

Edit or reword the root commit message Change the first line to reword (or r) to update the initial commit message during the rebase:

   reword a1b2c3d Initial commit
   pick d4e5f6g Add feature X
   ...

The rebase will stop and prompt you to edit the root commit message.

Amend the root content Use edit on the root entry if you need to change the actual tree of the root commit (add/remove files). Rebase will stop at that commit; then you can modify files, git add them, and run git commit --amend before continuing the rebase:

   # interactive todo:
   edit a1b2c3d Initial commit
   pick d4e5f6g Add feature X
   ...
   # when rebase stops:
   # make changes to the working tree
   git add <files>
   git commit --amend --no-edit   # or edit message as needed
   git rebase --continue

Caveats

Rewriting the root rewrites the entire branch history. This is disruptive if the branch is shared — coordinate with collaborators or avoid rewriting published branches.
After a --root rebase you must force-push to update any remote branch (git push --force-with-lease).
git rebase -i --root behaves like a normal interactive rebase in terms of conflict resolution and aborting (git rebase --abort).

Summary

Use git rebase -i <base> to interactively squash commits after <base>.
Mark commits to squash with squash (or s).
Edit the commit message when prompted.
Complete the rebase and resolve conflicts with git rebase --continue.
To include the initial/root commit in your rebase (so you can squash or edit it), run git rebase -i --root. Be aware this rewrites the whole branch history and requires a force-push for published branches.

Git Rebaseで過去のコミットをSquashする方法

Gitのrebaseコマンドを使ってコミットをSquash（統合）すると、コミット履歴を整理したいときに便利です。以下に手順を説明します。

1. Squashするコミットを確認する

まず、コミットログを確認して、どのコミットをまとめるか決めます。

git log --oneline

例：

a1b2c3d タイポを修正
d4e5f6g 機能Xを追加
h7i8j9k WIP: 機能Xを実装
...

ここでは、機能Xを追加とWIP: 機能Xを実装をSquashするとします。

2. Interactive Rebaseを開始する

Squashしたいコミットの直前のコミットをベースとして、git rebase -iを実行します。

git rebase -i <base_commit_id>

この例で、a1b2c3dがその直前のコミットである場合は、次のように実行します。

git rebase -i a1b2c3d

3. コミット一覧を編集する

エディタが開き、次のような内容が表示されます。

pick d4e5f6g 機能Xを追加
pick h7i8j9k WIP: 機能Xを実装

2つ目のpickをsquash（または単にs）に変更します。

pick d4e5f6g 機能Xを追加
squash h7i8j9k WIP: 機能Xを実装

4. コミットメッセージを編集する

次に、Gitからコミットメッセージを統合するよう求められます。

# これは2個のコミットを組み合わせたものです。
# 1つ目のコミットメッセージ:
機能Xを追加

# 以下のコミットメッセージも含まれます:
WIP: 機能Xを実装

最終的なメッセージが簡潔になるよう整理します。

機能Xを追加

5. Rebaseを完了する

保存してエディタを閉じます。GitがRebaseを適用し、コミットを1つにSquashします。

6. トラブルシューティング

コンフリクトが発生した場合：通常どおりコンフリクトを解消してから、次を実行します。

  git add <fixed_files>
  git rebase --continue

Rebaseをキャンセルしたい場合：

  git rebase --abort

履歴を書き換えた後：ブランチをすでにリモートへPushしている場合は、書き換えた履歴をForce Pushする必要があります。

  git push --force-with-lease

（共同作業をしている場合は、--forceより--force-with-leaseを使用することを推奨します。）

7. ルートコミットを含めてSquashする（`--root`）

デフォルトでは、git rebase -i <base>は指定したベースコミットの次のコミットからRebaseを行います。最初のコミット（ルートコミット）もInteractive Rebaseの対象に含めたい場合（たとえば、初回コミットを編集したり、後続のコミットとSquashしたりする場合）は、--rootオプションを使用します。

git rebase -i --root

このコマンドの動作

ルート（初回）コミットがInteractive Rebaseのtodoリストの最初の項目として表示されます。
他のコミットと同様に、ルートコミットに対してpick、reword、edit、squash、fixupを指定できます。
ルートコミットと、それ以降のすべてのコミットが書き換えられます（そのため、ブランチ内のすべてのコミットIDが変更されます）。

一般的な用途と例

すべてのコミットを1つの初回コミットにSquashする 履歴全体を含む1つのコミットにしたい場合は、ルートコミットをpickのままにして、それ以外のすべてのコミットをsquash（またはs）に変更します。

   pick a1b2c3d 初回コミット
   squash d4e5f6g 機能Xを追加
   squash h7i8j9k WIP: 機能Xを実装
   ...

保存すると、Gitが統合後のコミットメッセージを編集するためのエディタを開くので、最終的なメッセージを作成できます。

ルートコミットのメッセージを編集・変更する Rebase中に初回コミットのメッセージを変更するには、最初の行をreword（またはr）に変更します。

   reword a1b2c3d 初回コミット
   pick d4e5f6g 機能Xを追加
   ...

Rebaseが一時停止し、ルートコミットのメッセージを編集するよう求められます。

ルートコミットの内容を修正する ルートコミットの実際のツリー（ファイルの追加・削除）を変更する必要がある場合は、ルートのエントリにeditを指定します。Rebaseはそのコミットで一時停止します。その後、ファイルを変更してgit addし、git commit --amendを実行してからRebaseを続行できます。

   # Interactive Rebaseのtodo:
   edit a1b2c3d 初回コミット
   pick d4e5f6g 機能Xを追加
   ...
   # Rebaseが停止したら:
   # ワーキングツリーに変更を加える
   git add <files>
   git commit --amend --no-edit   # 必要に応じてメッセージも編集
   git rebase --continue

注意点

ルートコミットを書き換えると、ブランチの履歴全体が書き換えられます。共有ブランチで行うと大きな影響があるため、共同作業者と調整するか、公開済みブランチの書き換えは避けてください。
--rootを使ってRebaseした後、リモートブランチを更新するにはForce Pushが必要です（git push --force-with-lease）。
git rebase -i --rootでも、コンフリクトの解消や中止（git rebase --abort）については通常のInteractive Rebaseと同様に動作します。

まとめ

git rebase -i <base>を使用すると、<base>より後のコミットを対話形式でSquashできます。
Squashするコミットをsquash（またはs）に変更します。
プロンプトが表示されたらコミットメッセージを編集します。
Rebaseを完了し、コンフリクトが発生した場合はgit rebase --continueで続行します。
初回／ルートコミットをRebaseの対象に含めてSquashや編集を行うには、git rebase -i --rootを実行します。この操作ではブランチの履歴全体が書き換えられ、公開済みブランチではForce Pushが必要になる点に注意してください。

Unlocking GNOME Keyring on a Remote Machine via X11 Forwarding

vast cow — Wed, 19 Aug 2026 09:42:29 +0000

A memo on unlocking the GNOME Keyring on a Linux server connected via SSH, using Seahorse through X11 Forwarding.

Also documented are how to unlock it with secret-tool, and how to use the SSH agent provided by GNOME Keyring / GCR from an SSH session.

Environment

Using SSH's X11 Forwarding, display the Seahorse and GNOME Keyring password prompts launched on the remote side on the local side.

First, establish the SSH connection.

ssh -XY server

After connecting, also reflect the X11 environment variables into the D-Bus / systemd user session.

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

Unlocking the GNOME Keyring

Using Seahorse

Launch Seahorse.

seahorse

Once Seahorse is displayed, select

Passwords → Login → Unlock

and enter the GNOME Keyring password.

This unlocks the Login keyring.

Using `secret-tool`

Instead of launching Seahorse, you can also request an unlock from secret-tool.

secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null

If the keyring is locked, a password prompt for unlocking will appear; enter the password there.

The search results themselves are not needed, so standard output is discarded to /dev/null.

To display the prompt via X11 Forwarding, run the following first.

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

Therefore, if you do not need to open the GUI Seahorse, just the following steps suffice.

ssh -XY server

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null

Using the SSH agent

To use the SSH agent on the GNOME Keyring / GCR side, point SSH_AUTH_SOCK to the GCR socket.

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

After setting this, verify the keys recognized by the agent.

ssh-add -l

A series of operations looks, for example, like this.

ssh -XY server

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

ssh-add -l

If using Seahorse, replace the unlock part as follows.

seahorse
# Passwords → Login → Unlock

If you use the GCR SSH agent every time, you may add the following to your shell's configuration file.

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

However, if you are also using another ssh-agent or agent forwarding, note that this will overwrite the existing SSH_AUTH_SOCK.

Why `dbus-update-activation-environment` is needed

When using SSH's X11 Forwarding, a DISPLAY like the following is set in the SSH session.

localhost:10.0

On the other hand, GUI prompts around GNOME Keyring may be launched via D-Bus or the systemd user session.

Therefore, even if DISPLAY is correctly set in the SSH shell, processes launched via D-Bus may not recognize the SSH X11 display.

So, run

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

to pass the current SSH session's DISPLAY and XAUTHORITY to the activation environment as well.

Procedure Summary

When using Seahorse.

ssh -XY server

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

seahorse
# Passwords → Login → Unlock

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

ssh-add -l

When using secret-tool.

ssh -XY server

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

ssh-add -l

Troubleshooting Notes

Check whether the GNOME Keyring daemon is running.

pgrep -af gnome-keyring-daemon

If the behavior is off, restart the user service.

systemctl --user stop gnome-keyring-daemon.service
systemctl --user start gnome-keyring-daemon.service

To watch the logs in real time, use the following.

journalctl --user-unit gnome-keyring-daemon -fe

Running this log in another terminal while operating Seahorse or secret-tool makes it easier to see what is happening on the daemon side.

For checking the SSH agent side, the following also works.

echo "$SSH_AUTH_SOCK"
ls -l "$XDG_RUNTIME_DIR/gcr/ssh"
ssh-add -l

The expected socket is:

$XDG_RUNTIME_DIR/gcr/ssh

Supplementary Notes

ssh -X is regular X11 Forwarding, while ssh -Y is trusted X11 Forwarding.

In this case, operation was confirmed with

ssh -XY server

Trusted X11 Forwarding grants remote applications broader permissions than regular -X, so it is assumed to be used only with trusted servers.

Also,

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

updates the activation environment of that user's D-Bus / systemd user session.

In environments where the same user is also using a local GUI session concurrently, be aware that this may affect where GUI applications are displayed.

Similarly,

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

switches the SSH agent used from the current shell to the GCR side.

If OpenSSH's ssh-agent or SSH agent forwarding is already in use, the GCR-side agent will be used instead of that socket.

Conclusion

To unlock the GNOME Keyring on a remote machine over SSH, first set up

ssh -XY server
dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

then either run

Passwords → Login → Unlock

from Seahorse, or request an unlock with

secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null

If you also want to use the GCR SSH agent, set

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"
ssh-add -l

If problems occur around the GNOME Keyring daemon, restarting it with systemctl --user and checking logs with journalctl proved effective.

リモートマシンのGNOME KeyringをX11 ForwardingでUnlockする

SSHで接続したLinuxサーバー上のGNOME Keyringを、X11 Forwarding経由でSeahorseを使ってUnlockしたときのメモ。

あわせて、secret-toolでUnlockする方法と、GNOME Keyring / GCRが提供するSSH agentをSSHセッションから利用する方法も記載する。

環境

SSHのX11 Forwardingを使い、リモート側で起動したSeahorseやGNOME Keyringのパスワードプロンプトをローカル側に表示する。

まずSSH接続する。

ssh -XY server

接続後、X11用の環境変数をD-Bus / systemd user session側にも反映する。

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

GNOME KeyringをUnlockする

Seahorseを使う方法

Seahorseを起動する。

seahorse

Seahorseが表示されたら、

Passwords → Login → Unlock

を選択し、GNOME Keyringのパスワードを入力する。

これでLogin keyringをUnlockできる。

`secret-tool`を使う方法

Seahorseを起動せず、secret-toolからUnlockを要求することもできる。

secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null

Keyringがロックされている場合はUnlock用のパスワードプロンプトが表示されるので、そこでパスワードを入力する。

検索結果そのものは不要なので、標準出力は/dev/nullへ捨てている。

X11 Forwarding経由でプロンプトを表示するため、先に以下を実行しておく。

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

したがって、GUIのSeahorseを開く必要がなければ、次の手順だけでもよい。

ssh -XY server

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null

SSH agentを使う

GNOME Keyring / GCR側のSSH agentを利用する場合は、SSH_AUTH_SOCKをGCRのソケットに向ける。

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

設定後、agentに認識されている鍵を確認する。

ssh-add -l

一連の操作は例えば以下になる。

ssh -XY server

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

ssh-add -l

Seahorseを使う場合は、Unlock部分を次のように置き換える。

seahorse
# Passwords → Login → Unlock

毎回GCRのSSH agentを使う場合は、利用しているshellの設定ファイルなどに次を追加しておいてもよい。

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

ただし、別のssh-agentやagent forwardingを併用している場合は、既存のSSH_AUTH_SOCKを上書きすることになるため注意する。

なぜ `dbus-update-activation-environment` が必要なのか

SSHのX11 Forwardingを使うと、SSHセッションには例えば以下のようなDISPLAYが設定される。

localhost:10.0

一方、GNOME Keyring周辺のGUIプロンプトはD-Busやsystemdのuser session経由で起動されることがある。

そのため、SSHシェル上ではDISPLAYが正しく設定されていても、D-Bus経由で起動されたプロセス側ではSSHのX11 displayを認識できない場合がある。

そこで、

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

を実行して、現在のSSHセッションのDISPLAYとXAUTHORITYをactivation environment側にも渡しておく。

手順まとめ

Seahorseを使う場合。

ssh -XY server

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

seahorse
# Passwords → Login → Unlock

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

ssh-add -l

secret-toolを使う場合。

ssh -XY server

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

ssh-add -l

不具合時のメモ

GNOME Keyring daemonが動いているか確認する。

pgrep -af gnome-keyring-daemon

挙動がおかしい場合は、user serviceを再起動する。

systemctl --user stop gnome-keyring-daemon.service
systemctl --user start gnome-keyring-daemon.service

ログをリアルタイムで確認する場合は以下。

journalctl --user-unit gnome-keyring-daemon -fe

別ターミナルでこのログを流しながらSeahorseやsecret-toolを操作すると、daemon側で何が起きているか確認しやすい。

SSH agent側の確認には以下も使える。

echo "$SSH_AUTH_SOCK"
ls -l "$XDG_RUNTIME_DIR/gcr/ssh"
ssh-add -l

期待するソケットは以下。

$XDG_RUNTIME_DIR/gcr/ssh

補足

ssh -Xは通常のX11 Forwarding、ssh -Yはtrusted X11 Forwardingになる。

今回は、

ssh -XY server

で動作を確認した。

trusted X11 Forwardingは通常の-Xよりリモートアプリケーションに広い権限を与えるため、信頼できるサーバーに対して使用するのが前提。

また、

dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

は、そのユーザーのD-Bus / systemd user sessionのactivation environmentを更新する。

同じユーザーでローカルのGUIセッションも並行して利用している環境では、GUIアプリケーションの表示先に影響する可能性があるため注意する。

同様に、

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"

は現在のshellから利用するSSH agentをGCR側に切り替える設定になる。

すでにOpenSSHのssh-agentやSSH agent forwardingを利用している場合、そのソケットではなくGCR側のagentを利用することになる。

結論

SSH越しにリモートマシンのGNOME KeyringをUnlockする場合は、まず

ssh -XY server
dbus-update-activation-environment --systemd DISPLAY XAUTHORITY

とした上で、Seahorseから

Passwords → Login → Unlock

を実行するか、

secret-tool search --unlock --all xdg:schema org.freedesktop.Secret.Generic >/dev/null

でUnlockを要求する。

さらにGCRのSSH agentを利用する場合は、

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/gcr/ssh"
ssh-add -l

を設定する。

GNOME Keyring daemon周辺で問題が起きた場合は、systemctl --userでの再起動とjournalctlでのログ確認が有効だった。

How to Use a Tool to Remove a Specific App from Windows “File Associations”

vast cow — Tue, 18 Aug 2026 08:41:19 +0000

On Windows, uninstalled applications or portable applications can sometimes leave behind only their file-association information in the registry.

For example, when you display “Open with” for files such as .epub or .pdf, an application you no longer use may remain listed as an option.

This section explains how to use a Python tool that examines file associations registered under HKEY_CLASSES_ROOT and deletes registry keys associated with a specified executable file.

What This Tool Does

This tool examines the keys directly under HKEY_CLASSES_ROOT, abbreviated as HKCR.

For each key, it checks:

HKEY_CLASSES_ROOT\<key name>\shell\open\command

and retrieves the executable filename from the command set as the default value.

For example, suppose the following entry exists:

"C:\Program Files\Calibre2\ebook-viewer.exe" "%1"

If the specified executable filename is ebook-viewer.exe, this association is detected as a target.

When run normally, the tool deletes the target registry key. If you add --dry-run, it only displays the targets without deleting them.

Requirements

This script is for Windows only.

It uses only the following Python standard-library modules:

argparse
ctypes
os
winreg

Therefore, no additional packages need to be installed.

It can be used on a Windows system with Python 3 installed.

First, Save the Script

Save the code under a filename such as:

remove_association.py

Open Command Prompt or PowerShell and move to the directory where you saved the file.

Example:

cd C:\Tools

Always Check with `--dry-run` First

Because this tool deletes registry keys, it is safer not to delete anything immediately. First, use --dry-run to review the targets.

The syntax is:

python remove_association.py <executable filename> --dry-run

For example, to check entries associated with calibre.exe, run:

python remove_association.py calibre.exe --dry-run

If targets are found, the output will look like this:

Found 2 association(s).

HKEY_CLASSES_ROOT\Calibre...
  command = "C:\Program Files\Calibre2\calibre.exe" "%1"

HKEY_CLASSES_ROOT\...
  command = "C:\Program Files\Calibre2\calibre.exe" "%1"

dry-run: No keys were deleted.

If the final line says:

dry-run: No keys were deleted.

then the registry has not been modified.

Actually Deleting the Entries

After reviewing the --dry-run results and confirming that only unnecessary associations were detected, run the command again without --dry-run.

python remove_association.py calibre.exe

If deletion succeeds, the tool displays:

DELETED: HKEY_CLASSES_ROOT\...

If multiple associations are found, the detected keys are deleted one by one.

Specify Only the Executable Filename

As a general rule, specify only the executable filename as the argument, not the full path.

For example, instead of:

C:\Program Files\Calibre2\calibre.exe

specify:

calibre.exe

The tool parses the command registered in the registry according to Windows command-line rules, extracts only the filename of the executable at the beginning of the command, and compares that filename.

The comparison is case-insensitive. Therefore:

CALIBRE.EXE

and:

calibre.exe

are treated as the same filename.

Why It Does Not Use a Simple String Search

An association command does not necessarily contain only the executable path.

For example, it may look like:

"C:\Program Files\Example\viewer.exe" "%1"

or:

"C:\Program Files\Example\viewer.exe" --open "%1"

In addition, Windows command lines have their own rules for handling quotation marks and spaces.

For this reason, the tool parses the command string using the Windows API function:

CommandLineToArgvW

It then extracts the executable filename from the first parsed argument using:

os.path.basename(parts[0])

This structure is less prone to false positives than a simple substring check such as:

if "calibre.exe" in command:

Support for `REG_EXPAND_SZ`

The tool also supports commands stored not only as ordinary REG_SZ strings, but also as REG_EXPAND_SZ values containing environment variables.

For example:

"%ProgramFiles%\Example\viewer.exe" "%1"

In this case, the tool expands the environment variables using:

os.path.expandvars(value)

before parsing the command.

How Associations Are Searched

The core of the search process is find_associations().

def find_associations(target_exe: str):

This function sequentially enumerates the keys directly under HKEY_CLASSES_ROOT using winreg.EnumKey().

For each key, it reads:

<key>\shell\open\command

and, if the executable filename matches the specified name, returns it as a deletion candidate with:

yield key_name, command

In other words, this tool searches the shell\open\command entry under each key directly beneath HKCR.

Note that it is not a tool that comprehensively searches every type of file-association information that may exist in Windows.

Deletion Includes Subkeys

A registry key cannot be deleted directly if it contains subkeys.

For that reason, delete_registry_tree() recursively deletes child keys before deleting the parent key.

Conceptually, if the structure looks like this:

Target key
├─ DefaultIcon
├─ shell
│  └─ open
│     └─ command
└─ other entries

the tool deletes entries from the bottom of the hierarchy upward, then finally deletes the “Target key” itself.

Therefore, when this tool deletes a detected key, it removes not only shell\open\command, but the entire association key.

This is an important point.

If You Get a Permission Error

During deletion, you may see:

ACCESS DENIED: HKEY_CLASSES_ROOT\...

This can occur when the current user does not have permission to modify the registry key.

If necessary, run the command from PowerShell or Command Prompt opened with “Run as administrator.”

However, a permission error does not mean you should automatically delete the key with administrator privileges.

First, review the --dry-run output and confirm that the key is truly unnecessary.

If No Target Is Found

If no matching association exists, the tool displays a message such as:

No associations matching 'calibre.exe' were found.

In this case, nothing is deleted.

However, there may also be cases where the association is visible in Windows but is not detected by this tool.

Windows stores file-association information in multiple locations, and this tool checks only registrations in the following form:

HKEY_CLASSES_ROOT\<key>\shell\open\command

Usage Example

To only check associations linked to foo.exe, run:

python remove_association.py foo.exe --dry-run

After reviewing the results, to delete them, run:

python remove_association.py foo.exe

For example, suppose the detected result is:

Found 1 association(s).

HKEY_CLASSES_ROOT\Foo.Document
  command = "C:\OldApps\Foo\foo.exe" "%1"

If you run the tool normally in this state, the deletion target is not simply:

HKEY_CLASSES_ROOT\Foo.Document\shell\open\command

Instead, the entire tree under:

HKEY_CLASSES_ROOT\Foo.Document

is deleted.

Therefore, if Foo.Document contains other registered information, that information will also be lost.

Precautions

This tool directly deletes registry keys. It does not provide a function to restore deleted keys.

One especially important point is that when it finds a shell\open\command matching the specified EXE name, it recursively deletes not just that command key, but the association key itself directly under HKCR.

For that reason, the following workflow is recommended:

Confirm the target EXE filename.
Search using --dry-run.
Review every registry key that is displayed.
If necessary, export the target key from Registry Editor to create a backup.
Only after confirming there is no problem, run the tool normally.

It is particularly advisable to avoid targeting built-in Windows applications or applications that are currently in use.

Summary

This tool examines Windows HKEY_CLASSES_ROOT, searches for associations where the specified executable is registered under:

<key>\shell\open\command

and deletes those keys.

The basic usage is simple.

To only check:

python remove_association.py calibre.exe --dry-run

To actually delete:

python remove_association.py calibre.exe

Because the tool directly modifies the registry, the most important step is to review the targets with --dry-run first.

It can be useful for cleaning up old file associations left behind after uninstalling applications or associations for applications you no longer need, but because it deletes the entire association key, review the contents carefully and use it with caution.

import argparse
import ctypes
import os
import winreg
from ctypes import wintypes


shell32 = ctypes.WinDLL("shell32", use_last_error=True)
kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)

shell32.CommandLineToArgvW.argtypes = [
    wintypes.LPCWSTR,
    ctypes.POINTER(ctypes.c_int),
]
shell32.CommandLineToArgvW.restype = ctypes.POINTER(wintypes.LPWSTR)

kernel32.LocalFree.argtypes = [wintypes.HLOCAL]
kernel32.LocalFree.restype = wintypes.HLOCAL


def split_windows_command(command: str) -> list[str]:
    argc = ctypes.c_int()

    argv = shell32.CommandLineToArgvW(command, ctypes.byref(argc))
    if not argv:
        raise ctypes.WinError(ctypes.get_last_error())

    parts = [argv[i] for i in range(argc.value)]
    kernel32.LocalFree(argv)

    return parts


def get_open_command(root, key_name: str) -> str | None:
    subkey = rf"{key_name}\shell\open\command"

    try:
        with winreg.OpenKey(root, subkey, 0, winreg.KEY_READ) as key:
            value, value_type = winreg.QueryValueEx(key, "")

            if value_type in (winreg.REG_SZ, winreg.REG_EXPAND_SZ):
                if value_type == winreg.REG_EXPAND_SZ:
                    value = os.path.expandvars(value)
                return value

    except (FileNotFoundError, PermissionError, OSError):
        pass

    return None


def executable_name_from_command(command: str) -> str | None:
    try:
        parts = split_windows_command(command)
    except (ValueError, OSError):
        return None

    if not parts:
        return None

    return os.path.basename(parts[0])


def find_associations(target_exe: str):
    target_exe = target_exe.casefold()

    root = winreg.HKEY_CLASSES_ROOT
    index = 0

    while True:
        try:
            key_name = winreg.EnumKey(root, index)
        except OSError:
            break

        index += 1

        command = get_open_command(root, key_name)
        if command is None:
            continue

        executable_name = executable_name_from_command(command)
        if executable_name is None:
            continue

        if executable_name.casefold() == target_exe:
            yield key_name, command


def delete_registry_tree(root, subkey: str):
    try:
        with winreg.OpenKey(
            root,
            subkey,
            0,
            winreg.KEY_READ | winreg.KEY_WRITE,
        ) as key:
            while True:
                try:
                    child = winreg.EnumKey(key, 0)
                except OSError:
                    break

                delete_registry_tree(root, rf"{subkey}\{child}")

        winreg.DeleteKey(root, subkey)

    except FileNotFoundError:
        pass


def main():
    parser = argparse.ArgumentParser(
        description=(
            r"Checks the executable name in HKCR\<key>\shell\open\command and "
            "deletes keys associated with the specified exe."
        )
    )

    parser.add_argument(
        "exe",
        help="Executable filename to search for. Example: calibre.exe",
    )

    parser.add_argument(
        "--dry-run",
        action="store_true",
        help="List only the target keys without deleting them",
    )

    args = parser.parse_args()

    matches = list(find_associations(args.exe))

    if not matches:
        print(f"No associations matching {args.exe!r} were found.")
        return

    print(f"Found {len(matches)} association(s).")
    print()

    for key_name, command in matches:
        print(fr"HKEY_CLASSES_ROOT\{key_name}")
        print(f"  command = {command}")

    if args.dry_run:
        print()
        print("dry-run: No keys were deleted.")
        return

    print()
    print("Deleting.")

    for key_name, command in matches:
        full_name = fr"HKEY_CLASSES_ROOT\{key_name}"

        try:
            delete_registry_tree(winreg.HKEY_CLASSES_ROOT, key_name)
            print(f"DELETED: {full_name}")
        except PermissionError:
            print(f"ACCESS DENIED: {full_name}")
        except OSError as e:
            print(f"ERROR: {full_name}: {e}")


if __name__ == "__main__":
    main()

Windowsの「関連付け」から特定アプリを削除するツールの使い方

Windowsでは、アンインストール済みのアプリやポータブル版のアプリが、ファイルの関連付け情報だけをレジストリに残してしまうことがあります。

たとえば .epub や .pdf などのファイルで「プログラムから開く」を表示したとき、すでに使っていないアプリが候補として残るケースです。

ここでは、HKEY_CLASSES_ROOT に登録されているファイル関連付けを調べ、指定した実行ファイルに紐付いているレジストリキーを削除するPythonツールの使い方を説明します。

このツールがすること

このツールは HKEY_CLASSES_ROOT、略して HKCR の直下にあるキーを調べます。

各キーについて、

HKEY_CLASSES_ROOT\<キー名>\shell\open\command

を確認し、既定値に設定されているコマンドの実行ファイル名を取得します。

たとえば次のような登録があったとします。

"C:\Program Files\Calibre2\ebook-viewer.exe" "%1"

指定した実行ファイル名が ebook-viewer.exe なら、この関連付けを対象として検出します。

通常実行すると対象のレジストリキーを削除し、--dry-run を付けると削除せず対象だけを表示します。

動作環境

このスクリプトはWindows専用です。

Pythonの標準ライブラリである、

argparse
ctypes
os
winreg

だけを使用しているため、追加パッケージのインストールは必要ありません。

Python 3をインストールしたWindows環境で使用できます。

まずはスクリプトを保存する

コードを、たとえば次の名前で保存します。

remove_association.py

コマンドプロンプトまたはPowerShellを開き、ファイルを保存したディレクトリへ移動してください。

例:

cd C:\Tools

最初は必ず `--dry-run` で確認する

レジストリキーを削除するツールなので、最初から削除を実行するのではなく、まず --dry-run を使って対象を確認するのが安全です。

書式は次のとおりです。

python remove_association.py <実行ファイル名> --dry-run

たとえば calibre.exe に関連付けられた項目を調べる場合は、

python remove_association.py calibre.exe --dry-run

と実行します。

対象が見つかると、次のような形式で表示されます。

Found 2 association(s).

HKEY_CLASSES_ROOT\Calibre...
  command = "C:\Program Files\Calibre2\calibre.exe" "%1"

HKEY_CLASSES_ROOT\...
  command = "C:\Program Files\Calibre2\calibre.exe" "%1"

dry-run: No keys were deleted.

最後に

dry-run: No keys were deleted.

と表示されている場合、レジストリは変更されていません。

実際に削除する

--dry-run の結果を確認し、本当に不要な関連付けだけが検出されていることを確認したら、--dry-run を外して実行します。

python remove_association.py calibre.exe

削除に成功すると、

DELETED: HKEY_CLASSES_ROOT\...

と表示されます。

複数の関連付けが見つかった場合は、検出されたキーが順番に削除されます。

実行ファイル名だけを指定する

引数に指定するのは、基本的には実行ファイルのフルパスではなくファイル名です。

たとえば、

C:\Program Files\Calibre2\calibre.exe

ではなく、

calibre.exe

を指定します。

このツールはレジストリに登録されたコマンドをWindowsのルールに従って分解し、その先頭にある実行ファイルのファイル名だけを取り出して比較しています。

比較では大文字・小文字を区別しません。そのため、

CALIBRE.EXE

と

calibre.exe

は同じものとして扱われます。

なぜ単純な文字列検索をしていないのか

関連付けのコマンドは、単純に実行ファイルのパスだけが保存されているとは限りません。

たとえば、

"C:\Program Files\Example\viewer.exe" "%1"

や、

"C:\Program Files\Example\viewer.exe" --open "%1"

のような形式があります。

さらにWindowsのコマンドラインでは、引用符や空白の扱いに独自の規則があります。

そこでこのツールでは、

CommandLineToArgvW

というWindows APIを使ってコマンド文字列を解析しています。

解析後の最初の引数から、

os.path.basename(parts[0])

で実行ファイル名を取り出しています。

そのため、単純に

if "calibre.exe" in command:

のような部分一致で判定するより、誤検出が起こりにくい構造になっています。

`REG_EXPAND_SZ` にも対応

レジストリのコマンドが通常の文字列 REG_SZ だけでなく、環境変数を含む REG_EXPAND_SZ だった場合にも対応しています。

たとえば、

"%ProgramFiles%\Example\viewer.exe" "%1"

のような値です。

この場合は、

os.path.expandvars(value)

によって環境変数を展開してから解析します。

削除はサブキーも含めて行われる

レジストリキーは、その下にサブキーが存在すると単純には削除できません。

そのため delete_registry_tree() では、子キーを再帰的に削除してから親キーを削除しています。

概念的には、

対象キー
├─ DefaultIcon
├─ shell
│  └─ open
│     └─ command
└─ その他

という構造があった場合、下の階層から順番に削除し、最後に「対象キー」そのものを削除します。

したがって、このツールで検出されたキーを削除すると、shell\open\command だけではなく その関連付けキー全体が削除されます。

これは重要なポイントです。

権限エラーが出た場合

削除時に、

ACCESS DENIED: HKEY_CLASSES_ROOT\...

と表示されることがあります。

これは、そのレジストリキーを書き換えるための権限が現在のユーザーにない場合などに発生します。

必要であれば「管理者として実行」したPowerShellやコマンドプロンプトから実行します。

ただし、権限エラーが出たからといって、無条件に管理者権限で削除すべきとは限りません。

まず --dry-run の出力を見て、そのキーが本当に不要なものか確認してください。

対象が見つからない場合

一致する関連付けが存在しない場合は、

No associations matching 'calibre.exe' were found.

のように表示されます。

この場合、何も削除されません。

ただし、目的の関連付けがWindows上に表示されているにもかかわらず検出されないこともあります。

Windowsのファイル関連付けは複数の場所に保存されており、このツールが調べているのは、

HKEY_CLASSES_ROOT\<key>\shell\open\command

という形式の登録だけだからです。

使用例

foo.exe に紐付く関連付けを確認するだけなら、

python remove_association.py foo.exe --dry-run

確認後、削除するなら、

python remove_association.py foo.exe

です。

たとえば検出結果が、

Found 1 association(s).

HKEY_CLASSES_ROOT\Foo.Document
  command = "C:\OldApps\Foo\foo.exe" "%1"

だったとします。

この状態で通常実行すると、削除対象は単に、

HKEY_CLASSES_ROOT\Foo.Document\shell\open\command

だけではありません。

HKEY_CLASSES_ROOT\Foo.Document

以下のツリー全体です。

そのため、Foo.Document に別の情報も登録されている場合、それらも失われます。

使用上の注意

このツールはレジストリを直接削除します。削除したキーを元に戻す機能はありません。

特に注意すべきなのは、指定したEXE名に一致した shell\open\command を見つけると、その command キーだけでなく HKCR直下の関連付けキーそのものを再帰的に削除する ことです。

そのため、基本的には次の順序で使うことを推奨します。

対象となるEXE名を確認する
--dry-run で検索する
表示されたすべてのレジストリキーを確認する
必要ならレジストリエディターで対象キーをエクスポートしてバックアップする
問題がないことを確認してから通常実行する

特にWindows標準アプリや現在使用中のアプリを対象にするのは避けたほうがよいでしょう。

まとめ

このツールは、Windowsの HKEY_CLASSES_ROOT を調べて、

<キー>\shell\open\command

に指定した実行ファイルが登録されている関連付けを探し、そのキーを削除するためのものです。

基本的な使い方はシンプルです。

確認だけなら、

python remove_association.py calibre.exe --dry-run

実際に削除するなら、

python remove_association.py calibre.exe

です。

レジストリを直接操作するため、最初に --dry-run で対象を確認することが最も重要です。

アンインストール後も残っている古いファイル関連付けや、不要になったアプリの関連付けを整理するときに使えるツールですが、削除対象は関連付けキー全体なので、内容を確認したうえで慎重に使用してください。

import argparse
import ctypes
import os
import winreg
from ctypes import wintypes


shell32 = ctypes.WinDLL("shell32", use_last_error=True)
kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)

shell32.CommandLineToArgvW.argtypes = [
    wintypes.LPCWSTR,
    ctypes.POINTER(ctypes.c_int),
]
shell32.CommandLineToArgvW.restype = ctypes.POINTER(wintypes.LPWSTR)

kernel32.LocalFree.argtypes = [wintypes.HLOCAL]
kernel32.LocalFree.restype = wintypes.HLOCAL


def split_windows_command(command: str) -> list[str]:
    argc = ctypes.c_int()

    argv = shell32.CommandLineToArgvW(command, ctypes.byref(argc))
    if not argv:
        raise ctypes.WinError(ctypes.get_last_error())

    parts = [argv[i] for i in range(argc.value)]
    kernel32.LocalFree(argv)

    return parts


def get_open_command(root, key_name: str) -> str | None:
    subkey = rf"{key_name}\shell\open\command"

    try:
        with winreg.OpenKey(root, subkey, 0, winreg.KEY_READ) as key:
            value, value_type = winreg.QueryValueEx(key, "")

            if value_type in (winreg.REG_SZ, winreg.REG_EXPAND_SZ):
                if value_type == winreg.REG_EXPAND_SZ:
                    value = os.path.expandvars(value)
                return value

    except (FileNotFoundError, PermissionError, OSError):
        pass

    return None


def executable_name_from_command(command: str) -> str | None:
    try:
        parts = split_windows_command(command)
    except (ValueError, OSError):
        return None

    if not parts:
        return None

    return os.path.basename(parts[0])


def find_associations(target_exe: str):
    target_exe = target_exe.casefold()

    root = winreg.HKEY_CLASSES_ROOT
    index = 0

    while True:
        try:
            key_name = winreg.EnumKey(root, index)
        except OSError:
            break

        index += 1

        command = get_open_command(root, key_name)
        if command is None:
            continue

        executable_name = executable_name_from_command(command)
        if executable_name is None:
            continue

        if executable_name.casefold() == target_exe:
            yield key_name, command


def delete_registry_tree(root, subkey: str):
    try:
        with winreg.OpenKey(
            root,
            subkey,
            0,
            winreg.KEY_READ | winreg.KEY_WRITE,
        ) as key:
            while True:
                try:
                    child = winreg.EnumKey(key, 0)
                except OSError:
                    break

                delete_registry_tree(root, rf"{subkey}\{child}")

        winreg.DeleteKey(root, subkey)

    except FileNotFoundError:
        pass


def main():
    parser = argparse.ArgumentParser(
        description=(
            r"Checks the executable name in HKCR\<key>\shell\open\command and "
            "deletes keys associated with the specified exe."
        )
    )

    parser.add_argument(
        "exe",
        help="Executable filename to search for. Example: calibre.exe",
    )

    parser.add_argument(
        "--dry-run",
        action="store_true",
        help="List only the target keys without deleting them",
    )

    args = parser.parse_args()

    matches = list(find_associations(args.exe))

    if not matches:
        print(f"No associations matching {args.exe!r} were found.")
        return

    print(f"Found {len(matches)} association(s).")
    print()

    for key_name, command in matches:
        print(fr"HKEY_CLASSES_ROOT\{key_name}")
        print(f"  command = {command}")

    if args.dry_run:
        print()
        print("dry-run: No keys were deleted.")
        return

    print()
    print("Deleting.")

    for key_name, command in matches:
        full_name = fr"HKEY_CLASSES_ROOT\{key_name}"

        try:
            delete_registry_tree(winreg.HKEY_CLASSES_ROOT, key_name)
            print(f"DELETED: {full_name}")
        except PermissionError:
            print(f"ACCESS DENIED: {full_name}")
        except OSError as e:
            print(f"ERROR: {full_name}: {e}")


if __name__ == "__main__":
    main()

DEV Community: vast cow

Controlling CPU Fan Speed on Mac mini 5,2 with Ubuntu 24.04

1. First, check applesmc

2. Manually change the rotation speed

Return to automatic control

3. Recommended: Use mbpfan to link to temperature

4. Monitor temperature and RPM in real time

macmini5,2 ubuntu24.04でcpuファンスピードをコントロールしたい

1. まず applesmc を確認

2. 手動で回転数を変更する

自動制御に戻す

3. おすすめ：mbpfan で温度連動

4. 温度とRPMをリアルタイム監視

Macmini5,2 なら私ならこうします

Checking if a Used Core i7-6700 is Genuine Without Benchmarks

The Core i7-6700 We're Checking

What is FPO?

What is ATPO?

Reading a 2D Matrix with a Smartphone

Finding the Partial ATPO

Can the Heat Spreader and Substrate be Directly Matched?

How to Check for "A Fake with an i7-6700 Heat Spreader Placed on a Different CPU"?

Results This Time

Summary of How to Check a Used Intel CPU

Caution: It's Best Not to Publish the ATPO

Summary

中古のCore i7-6700が本物か、ベンチマークを使わずに確認してみた

今回確認するCore i7-6700

FPOとは？

ATPOとは？

2D Matrixをスマートフォンで読み取る

Partial ATPOを探す

ヒートスプレッダと基板は直接照合できるのか？

「別CPUにi7-6700のヒートスプレッダを載せた偽物」はどう確認する？

今回の結果

中古Intel CPUを確認するときの手順まとめ

注意：ATPOは公開しない方がよい

まとめ

How to Remove Specific Files from Git Commit History

1. Find the Commits Related to the Target File

2. Rebase from the Oldest Commit Related to the Target File

3. Change the Target Commit to drop or edit

If the Commit Only Changes That File

If the Commit Includes Changes to Other Files

4. Remove Changes to the Target File from the edit Commit

If the File Was Newly Added

If an Existing File Was Modified

5. Continue the Rebase

Finally, Check the History

Caution: If You Have Already Pushed

Summary

Gitのコミット履歴から特定のファイルだけ「なかったこと」にする方法

1. 対象ファイルに関係するコミットを探す

2. 一番古い対象コミットからrebaseする

3. 対象コミットをdropまたはeditに変更する

そのファイルだけを変更しているコミットの場合

他のファイルの変更も含まれている場合

4. editしたコミットから対象ファイルの変更を取り除く

ファイルを新規追加していた場合

既存ファイルを変更していた場合

5. rebaseを続行する

最後に履歴を確認する

注意：すでにpushしている場合

まとめ

How to Use a Japanese Keyboard (JIS Layout) in GRUB: Rocky Linux / RHEL Compatible

How to Use a Japanese Keyboard (JIS Layout) in GRUB: Rocky Linux / RHEL Compatible

Linux Keyboard Settings and GRUB Keyboard Settings Are Different

Packages Required for Rocky Linux / RHEL

Create a Japanese Keymap for GRUB

Temporarily Change to JIS Layout Only During GRUB Boot

If keymap jp Cannot Be Loaded

Make the JIS Layout Permanent

Regenerate grub.cfg

Notes for UEFI Environments

Is terminal_input at_keyboard Necessary?

Temporary Change vs. Permanent Change

Can I Change to the JIS Layout in GRUB Without Creating a .gkb File?

Summary

GRUBで日本語キーボード（JIS配列）を使う方法：Rocky Linux / RHEL系対応

Linuxのキーボード設定とGRUBのキーボード設定は別物

1. First, check `applesmc`

3. Recommended: Use `mbpfan` to link to temperature

1. まず `applesmc` を確認

3. おすすめ：`mbpfan` で温度連動

3. Change the Target Commit to `drop` or `edit`

4. Remove Changes to the Target File from the `edit` Commit

If `keymap jp` Cannot Be Loaded

Is `terminal_input at_keyboard` Necessary?

Can I Change to the JIS Layout in GRUB Without Creating a `.gkb` File?

`keymap jp` で読み込めない場合

`terminal_input at_keyboard` は必要か

`.gkb`を作らずGRUBだけでJIS配列へ変更できるか

`.gitconfig`

`credential.useHttpPath = true` is Important

Reset Existing Credential Helpers with `helper =`

Why Not Use `gh auth git-credential` Directly?

`.gitconfig`

`credential.useHttpPath = true` が重要

`helper =` で既存credential helperをリセットする

なぜ`gh auth git-credential`をそのまま使わないのか