CLI・シェル環境 on AIによる技術記事備忘録

EmacsでC-h（ヘルプ）を誤打したときに画面を元の状態へ戻す手順

Sun, 25 Oct 2026 22:21:46 +0900

Emacsの操作中に C-h を誤って押してしまい、意図せずヘルプ機能に入ってしまうケースは珍しくありません。この状況で混乱が生じやすい根本的な理由は、Emacsが現在 キー入力の待機中 なのか、それともすでに ヘルプ画面が展開された後 なのかによって、復帰に必要な操作のレイヤーが異なる点にあります。現在の状態を正しく判別できれば、迷わず元の編集状態へ復帰できます。

キー入力待ちの状態から中断する

C-h を押した直後、画面最下部のミニバッファに C-h- と表示されて後続のキー入力を待っている段階では、ヘルプのウィンドウ自体はまだ開かれていません。この状態はEmacsがコマンドの追加入力を受け付けている途中にすぎないため、キーシーケンスの中断コマンドを実行します。

ここで使用するのが C-g （keyboard-quit）です。C-g を入力すると進行中のコマンド受付が直ちに破棄され、ミニバッファに Quit と表示されて元のバッファの編集状態に復帰します。

ヘルプ画面が表示された後に元の配置へ戻す

C-h に続いて何らかのキーを押してしまい、ウィンドウが2分割されて *Help* バッファが展開された場合は、キー入力の中断ではなくウィンドウのレイアウトを戻す処理が必要になります。この段階では、カーソル（ポイント）がどちらのウィンドウに存在するかによって選択する操作が変わります。

ヘルプバッファ側にカーソルがある場合: q （quit-window）を押します。ヘルプ表示用のモードでは q にウィンドウを閉じて直前の配置に戻す動作が割り当てられているため、1ストロークで元の状態に復帰します。
元の編集バッファ側にカーソルがある場合: C-x 1 （delete-other-windows）を押します。現在カーソルが置かれているウィンドウ以外の分割画面が一括で非表示となり、編集画面が再び単一の全画面表示に戻ります。
編集側からヘルプバッファを経由して閉じたい場合: ウィンドウ間を移動する C-x o （other-window）でヘルプ側へカーソルを移してから q を入力することでも同様に復帰できます。

状態の識別と混乱を防ぐ要点

操作に迷いが生じる原因は、キーシーケンスの破棄である 入力の中断 と、画面レイアウトの復元である ウィンドウの破棄 という2つの異なる処理を混同しやすい点にあります。

画面が分割される前の入力待ちであれば C-g 、画面が分割された後であれば q または C-x 1 というように、Emacsの画面状態に応じたキーを選択することが確実な復帰に繋がります。

rsyncで「IO error encountered — skipping file deletion」が発生した原因と対処法

Sun, 30 Aug 2026 12:37:13 +0900

rsyncを利用して定期的なローカルバックアップスクリプトを運用している際、転送処理中にエラーが発生して一部のファイル同期および削除処理がスキップされるトラブルに遭遇しました。今回はその原因の特定と、安全にスクリプトを修正して正常終了させるまでの手順をまとめます。

エラーの発生状況と原因

バックアップスクリプトを実行したところ、転送の途中で以下のようなメッセージが出力されました。

IO error encountered -- skipping file deletion
rsync: [sender] opendir "/path/to/app1/data/db" failed: Permission denied (13)
rsync: [sender] opendir "/path/to/app2/db-data" failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23)

この現象には2つの連動した原因があります。

直接的な原因は、コンテナ等で稼働しているアプリケーション（データベースなど）のデータディレクトリに対して、一般ユーザー権限で実行していたrsyncがアクセスできず、Permission denied となったことです。コンテナ内のプロセスが専用のUIDでディレクトリを作成しているため、一般ユーザーの読み取り権限が制限されていました。

間接的なエラーである IO error encountered -- skipping file deletion は、rsyncが備えている安全機能によるものです。同期元でアクセスエラーや読み込み不可のファイルが発生した場合、rsyncはファイルが削除されたのか、単に読み込めないだけなのかを判別できません。そのため、同期先のファイルを誤って消去してしまわないよう、--delete オプションによる削除処理を自動的に中断します。

対処法：DBデータディレクトリの除外

稼働中のデータベースが持つ生データディレクトリをそのままファイル単位でrsync同期することは、データの整合性が崩れるリスクが高いため推奨されません。データベースのバックアップはダンプファイルを別途出力してそれを同期するのが安全です。

そのため、今回は読み取り権限のないデータベース関連のディレクトリを --exclude オプションで明示的に除外する方針をとりました。

修正前のスクリプトでは、ドライブ直下のシステム用ディレクトリである lost+found のみを除外していましたが、コンテナのデータディレクトリも除外対象へ追加しました。

#!/bin/bash

rsync -avh --delete --exclude="lost+found" /path/to/source_disk1/ /path/to/backup_disk/disk1/
rsync -avh --delete --exclude="lost+found" /path/to/source_disk2/ /path/to/backup_disk/disk2/
rsync -avh --delete --exclude="lost+found" /path/to/user_data/ /path/to/backup_disk/share/
rsync -avh --delete \
 --exclude="lost+found" \
 --exclude="app1/data/db" \
 --exclude="app2/db-data" \
 /path/to/applications/ /path/to/backup_disk/applications/

除外パスの指定は、同期元（/path/to/applications/）からの相対パスで記述します。

修正後の動作確認

スクリプト修正後に再度実行したところ、アクセス権限エラーや削除スキップの警告は出力されなくなりました。

実行直後に echo $? で終了ステータスを確認し、正常終了を示す 0 が返ってくることを確認して作業完了としました。

権限エラーを無理やり無視する --ignore-errors などのオプションに頼るのではなく、不要なディレクトリや整合性の担保できないデータディレクトリを適切に除外することが、堅牢なバックアップ運用につながります。

Emacsを常にターミナル内（-nw）で起動させる設定とsudo実行時の対策

Sat, 22 Aug 2026 17:28:18 +0900

GUI環境が整っている端末であっても、エディタはターミナル内部で軽快に動かしたいという場面は多くあります。Emacsをターミナル内で起動するには通常 -nw オプションを付与しますが、コマンドを実行するたびに入力するのは手間がかかります。そこで、常にターミナル内で開くための設定と、sudo を付与した際にもその挙動を維持する方法、さらに安全に管理者権限で編集するための代替アプローチを整理します。

常にターミナル内でEmacsを起動するエイリアス設定

コマンド入力を省略する最もシンプルな手段は、利用しているシェルの設定ファイル（Bashであれば ~/.bashrc、Zshであれば ~/.zshrc）にエイリアスを登録することです。

設定ファイルへ以下のように記述します。

alias emacs='emacs -nw'

記述後に source ~/.bashrc や source ~/.zshrc を実行して設定を再読み込みすれば、以降は emacs と入力するだけで自動的に -nw が付与された状態で起動するようになります。なお、稀にGUIウィンドウでEmacsを立ち上げたい状況が発生した場合は、コマンドの先頭にバックスラッシュを付与して \emacs と実行することで、登録したエイリアスを一時的に無効化して起動できます。

sudo実行時にエイリアスを展開させる工夫

一般ユーザー権限ではエイリアスによって意図通りに動作しますが、システムファイルの編集などで sudo emacs を実行した途端、ふたたびGUI版が立ち上がってしまう問題に直面します。これは、sudo コマンドがデフォルトではシェルのエイリアスを展開せず、後続の引数をそのまま実行ファイル名として解釈するためです。

この仕様を回避するには、シェル設定ファイルに以下のエイリアスを追加します。

alias sudo='sudo '

ポイントは、末尾に半角スペースを含めている点です。多くのシェルには「エイリアス展開後の文字列が空白で終わっている場合、続く次の単語に対してもエイリアス展開を試みる」という仕様が備わっています。これを利用することで、sudo emacs と入力した際にも直後の emacs が emacs -nw へと正常に展開されるようになります。

安全に管理者権限で編集するsudoeditの活用

sudo emacs でエイリアスを効かせる方法のほかに、セキュリティの観点から推奨される手段として sudoedit（または sudo -e）の利用が挙げられます。sudo emacs はEmacsプロセス全体をroot権限で動作させるため、万一エディタ内で意図しない処理が走った際のリスクが高まります。対して sudoedit は、対象ファイルの複製を一時ファイルとして一般ユーザー権限のエディタで編集し、保存・終了時にのみ管理者権限で元のファイルへ上書きする仕組みをとっています。

sudoedit で起動するエディタをEmacsのCUIモードにするには、シェルの設定ファイルで環境変数を指定します。

export EDITOR='emacs -nw'
export VISUAL='emacs -nw'

設定反映後は、sudoedit /path/to/file のようにファイルを指定して編集します。root権限でのエディタ直接実行を避けつつ、普段と同じターミナル環境のEmacsで安全にシステムファイルを更新できます。

macOS 14.8.3におけるスクリーンショット保存先とファイル形式のJPG変更手順

Sat, 31 Jan 2026 16:55:41 +0900

macOSの標準機能であるスクリーンショットは、初期設定において「デスクトップ」を保存先とし、ファイル形式には「PNG」が採用されている。本記事では、保存先の変更とファイル形式の変更について記述する。

環境

項目	内容
OSバージョン	macOS 14.8.3
使用ツール	ターミナル (Terminal.app)、スクリーンショットアプリ
目的	ファイルサイズの軽量化およびディレクトリ管理の整理

スクリーンショットアプリによる直感的な保存場所の変更

macOSには標準でスクリーンショットを管理するための専用インターフェースが備わっており、GUI操作のみで保存場所の変更が可能である。

キーボードの Command + Shift + 5 を同時に押下し、画面下部にスクリーンショットツールバーを表示させる。このツールバー内に存在する「オプション」メニューをクリックすることで、保存先の候補が表示される。

ターミナルを利用したファイル形式のJPG化と詳細設定

ファイル形式をPNGからJPGへ変更し、さらに保存場所をコマンドラインから厳密に指定するには、ターミナルでの操作が最も確実である。まず、LaunchpadやSpotlightから「ターミナル」を起動する。ファイル形式をJPGに変更するには、以下のコマンドを入力し、実行する。

defaults write com.apple.screencapture type jpg

このコマンドは、システムの環境設定ファイルを書き換えるものであり、type の後には png、pdf、tiff、gif など任意の拡張子を指定できる。次に、保存場所もコマンドで指定したい場合は、以下の書式を用いる。

defaults write com.apple.screencapture location ~/Pictures/Screenshots

ここで使用している ~/Pictures/Screenshots は一例であり、ユーザの環境に合わせて任意のパスに変更することが可能である。

defaults コマンドを使用して設定を書き換えただけでは、システムに即座に変更が反映されない場合がある。設定を有効化するためには、macOSのUI管理プロセスである SystemUIServer を再起動させる必要がある。以下のコマンドを実行することで、Mac本体を再起動させることなく新しい設定を適用できる。

killall SystemUIServer

コマンドの実行後、実際に Command + Shift + 3 （全画面撮影）や Command + Shift + 4 （範囲指定撮影）を行い、動作を検証する。指定した保存先にファイルが出力されていること、およびファイルの拡張子が .jpg になっていることを情報ウィンドウ（Command + I）で確認する。

もし設定を元に戻したい場合は、形式を png に指定し、同様の手順で killall コマンドを実行すればよい。

Webブラウザでシェルにアクセスする Shell In A Box のセットアップ備忘録

Mon, 15 Dec 2025 12:34:40 +0900

目的と再現環境

Webブラウザを経由してサーバーまたはローカルマシンにセキュアにアクセスできるターミナル環境を構築することは、リモートワークフローや簡易的なサーバー管理において利便性が高い。本記事は、WebベースのSSHクライアントである Shell In A Box (SIA) をmacOS上にセルフホストし、LAN内の他のPCからアクセス可能にするまでの具体的な手順を記録することを目的とする。

前提となる再現環境

本記事で解説する手順は、以下の環境を前提とし、Macをホストマシンとして使用する。

ホストOS: macOS (Homebrewがインストールされていること)
クライアント環境: LAN内の任意のPCにインストールされたWebブラウザ
ツール: Shell In A Box (SIA)

この手順は、特別な外部サービスを必要とせず、Homebrewが利用できる環境であればすぐに再現できる。

Shell In A Boxのインストールと基本的な起動

Shell In A Box を使用可能にする最初のステップは、MacのパッケージマネージャーであるHomebrewを利用したツールのインストールである。HomebrewはmacOS上でUNIXツールやパッケージを簡単に管理するためのデファクトスタンダードであり、この手順を大幅に簡略化する。

Homebrewが導入されていることを確認した後、ターミナルで以下のコマンドを実行し、Shell In A Boxをインストールする。

Bash

brew install shellinabox

インストール完了後、Shell In A Box デーモン（shellinaboxd）を起動する。LAN内での利用を想定する場合、アクセス制御とセキュリティのため、簡易テスト用の -t オプションではなく、ログインプロンプトを表示するデフォルトモードで起動することが推奨される。

Bash

shellinaboxd

このコマンドを実行すると、Shell In A BoxはデフォルトでTCPポート 4200 を使用して接続待ちの状態となる。この際、ターミナルには特にメッセージが表示されないことが多い。この状態でMac上のWebブラウザ（例: Chrome, Safari）を開き、http://localhost:4200/ にアクセスすることで、ログインプロンプトが表示されることを確認できる。ログイン認証には、ホストマシン（Mac）のユーザー名とパスワードを使用する。これにより、ブラウザ内でMacのターミナルを操作する準備が整う。この基本的な起動により、ローカルマシンでの動作が確認でき、次のステップであるLAN内アクセスへの布石となる。

LAN内アクセスを可能にする設定と手順

Shell In A Boxは、デフォルトでMacのすべてのネットワークインターフェースからの接続を待ち受ける設定になっている。そのため、LAN内の他のPCからアクセスを可能にするために必要なのは、ホストであるMacのローカルIPアドレスを確認することのみである。これにより、MacのWebブラウザだけでなく、ネットワークを介した任意のデバイスからシェルにアクセスすることが可能となる。

まず、Shell In A BoxにアクセスするためのホストとなるMacのプライベートIPアドレスを確認する。これは「システム設定」や「システム環境設定」の「ネットワーク」セクションから確認可能である。例えば、IPアドレスが 192.168.1.10 であると仮定する。このIPアドレスは、LAN内でのみ有効なアドレスであり、外部インターネットからのアクセスには使用されない。

次に、LAN内の他のPCのWebブラウザを開き、以下の形式のURLを入力してアクセスする。

http://[MacのIPアドレス]:4200/

具体例として、IPアドレスが 192.168.1.10 の場合、アクセスURLは http://192.168.1.10:4200/ となる。このURLにアクセスすると、ブラウザにShell In A Boxのログイン画面が表示される。ここで、ホストMacのユーザー名とパスワードを入力することで、LAN内の任意のPCからMacのシェル環境を操作することが可能となる。この方法は、Webベースのサービスとしてシェルを提供するため、クライアント側に追加のSSHクライアントソフトウェアをインストールする必要がないという利点がある。このプロセス全体を通じて、セキュリティを確保するため、パスワード認証が必須となることに留意すべきである。

PC起動時の自動起動設定

Shell In A Boxの利便性を最大化するには、ホストマシン（Mac）の起動時に自動的にサービスを開始させることが重要である。macOSでは、ユーザーログイン後にサービスを自動起動させるために、標準機能である launchd とその設定ファイル（.plist ファイル）を利用する。これにより、手動で毎回ターミナルで起動コマンドを実行する手間を省くことができる。

まず、以下の構造を持つプロパティリスト（plist）ファイルをホームディレクトリ内の適切な場所に作成する。ファイル名は慣例に従い、com.shellinabox.server.plist とする。保存場所はユーザーごとのサービス定義を格納するディレクトリである ~/Library/LaunchAgents/ である。

XML

# ~/Library/LaunchAgents/com.shellinabox.server.plist
<dict>
 <key>Label</key>
 <string>com.shellinabox.server</string>
 <key>ProgramArguments</key>
 <array>
 <string>/usr/local/bin/shellinaboxd</string>
 </array>
 <key>RunAtLoad</key>
 <true/>
 <key>KeepAlive</key>
 <true/>
 <key>UserName</key>
 <string>（Macのユーザー名）</string>
 <key>StandardErrorPath</key>
 <string>/tmp/shellinabox.err</string>
 <key>StandardOutPath</key>
 <string>/tmp/shellinabox.out</string>
</dict>

注意点として、<key>UserName</key> の値には、実際にShell In A Boxを実行するMacのユーザー名を正確に記述する必要がある。

ファイルを作成した後、ターミナルに戻り、launchctl コマンドを使用してサービスをシステムに登録し、ロード（起動）する。

Bash

launchctl load ~/Library/LaunchAgents/com.shellinabox.server.plist

この操作により、Shell In A Boxのサービスが即座に起動し、かつ、次回以降のMacの再起動時やログイン時に自動的に実行されるようになる。この設定によって、Webブラウザを開くだけで、常にLAN内からMacのシェル環境にアクセスできる状態が維持され、特にWordPress管理CLIの実行などの用途において、シームレスな作業環境が提供されるのである。

bashでターミナル間の履歴を共有する方法

Thu, 27 Nov 2025 14:50:56 +0900

bash の履歴は通常、各ターミナルが独立して管理しており、複数のウィンドウを開いて作業していると、過去に実行したコマンドが別のターミナルに反映されず不便である。この問題は、bash が履歴ファイル（一般に ~/.bash_history）を読み書きするタイミングが限られていることに起因する。

デフォルトでは、ターミナル終了時に履歴が書き込まれる仕様であり、そのためリアルタイムの共有は行われない。本稿では、この挙動を変更し、どのターミナルからも最新履歴を利用できる環境を構築する方法について解説する。

履歴共有の仕組み

bash に対して「履歴をリアルタイムに書き込み、かつ常に読み込む」ことを明示的に指示する。bash には PROMPT_COMMAND という特別な環境変数が存在し、これはプロンプトが表示される直前に bash が必ず実行するコマンド列を定義する。

履歴同期のためには、この仕組みを利用して、直前のコマンドを履歴ファイルに追記する history -a を実行し、他ターミナルが書き込んだ履歴を読み込む history -n を実行するという二段構えが必要になる。また、履歴ファイルの内容を上書きせず追記する histappend を有効にすることで、複数ターミナルが同時に履歴を書いても衝突が起こらない。

実装方法

履歴共有の設定は .bashrc に記述することで有効になる。.bashrc はログインシェルでなくとも読み込まれるため、複数ターミナルで開く通常の対話型シェルの設定として適切である。以下に示す設定を追記すれば、ターミナルを跨いで履歴が共有される。

shopt -s histappend
export PROMPT_COMMAND="history -a; history -n"

この設定を追加したら、source ~/.bashrc を実行して反映させる。

強制同期が必要な場合（オプション）

履歴の衝突や順序の乱れが気になるような環境では、より強制的な同期方法として history -c を併用する設定がある。これは一度メモリ上の履歴を全消去し、その後ファイルから再度読み込むため、最新状態が常に正確に再現される。設定は以下のとおりである。

export PROMPT_COMMAND="history -a; history -c; history -n"

ただし、この手法は履歴の並びが不自然になりやすいなどの副作用があるため、常用するというよりは、履歴を厳密に同期させたい特定の場面でのみ利用すべきである。

動画ダウンロードの定番──yt-dlpという万能ツール

Wed, 05 Nov 2025 08:11:15 +0900

動画サイトの海を自由に泳ぎたい者にとって、yt-dlpは最強の羅針盤である。YouTubeをはじめ、無数の配信サイトから動画や音声を自在に取得できるその力は、まるで多言語を理解する通訳のように万能だ。だが、いくら名ツールでも、その使い方を知らなければただの宝の持ち腐れである。本稿では、yt-dlpの基本的な操作法を一通り押さえ、使いこなすための筋道を記す。

導入という第一歩

yt-dlpはPython製のツールであり、インストールも簡潔だ。ターミナルで次の一行を叩くだけで始まる。

pip install -U yt-dlp

この瞬間、あなたのマシンに強力なダウンローダーが宿る。macOSやLinuxを使っているなら、Homebrew経由での導入も選べる。

brew install yt-dlp

更新も容易であり、常に最新版を保つことが推奨される。

yt-dlp -U

コマンドラインに抵抗を覚える者もいるが、一度慣れればGUIのような視覚的ツールよりもはるかに迅速で正確だ。

基本動作──URLひとつで完結する魔法

yt-dlpの核心はシンプルな命令にある。対象となる動画URLを指定すれば、それだけでダウンロードが始まる。

yt-dlp https://www.youtube.com/watch?v=XXXXXXXXXXX

特別なオプションを付けなくとも、自動で最高画質を選択して保存してくれる。まるでソムリエが最適なワインを差し出すように、ユーザーの手を煩わせない。

音だけを抜き出すという美学

動画のすべてを欲する必要はない。ときに音声だけで十分なこともある。音楽、講演、ラジオ──それらを純粋な音として残したいなら、次のコマンドが適切だ。

yt-dlp -x --audio-format mp3 https://www.youtube.com/watch?v=XXXXXXXXXXX

-xは音声抽出を意味し、--audio-formatで形式を指定できる。mp3のほか、m4aやwavなども選択可能だ。映像を削ぎ落とし、声や音だけを抽出する行為には、ある種の潔さがある。

整理整頓という技術

複数の動画を扱うとき、ファイル名の管理は混沌に陥りがちだ。そこで役立つのが出力指定オプションである。

yt-dlp -o "%(title)s.%(ext)s" https://www.youtube.com/watch?v=XXXXXXXXXXX

%(title)sは動画タイトル、%(ext)sは拡張子を示す。保存先フォルダを指定したければ、パスを追加することもできる。この設定ひとつで、ライブラリ全体が整然と並ぶ。細部へのこだわりが、長期的な快適さを生むのだ。

フォーマットを選ぶ自由

映像のフォーマットや画質を厳密に選びたい場面もある。そのときは、まず利用可能な形式を一覧で確認する。

yt-dlp -F https://www.youtube.com/watch?v=XXXXXXXXXXX

一覧には画質、コーデック、サイズなどの情報が並ぶ。そこから望むフォーマットIDを指定して実行すればよい。

yt-dlp -f 22 https://www.youtube.com/watch?v=XXXXXXXXXXX

コマンドひとつで、容量を抑えたい場合も、高画質を追求したい場合も自在に選べる。この自由度こそがyt-dlpの真髄である。

プレイリストを一括で手に入れる

YouTubeのプレイリストURLを指定すれば、連続した動画をまとめてダウンロードできる。

yt-dlp https://www.youtube.com/playlist?list=XXXXXXXXXXX

講義シリーズやミュージックアルバムのような連番構成の動画には特に有効だ。時間を節約し、統一感ある保存が叶う。

結語──コマンドラインに宿る洗練

yt-dlpの魅力は、単なる便利さを超えている。短い命令の中に、精密な制御と柔軟な設計が共存しているからだ。クリック操作では到達できないレベルの自由がここにある。コマンドラインは不器用な人のための道具ではなく、考える者のための筆記具である。

動画をダウンロードするという単純な行為の背後には、情報をどう扱い、どう保存するかという哲学が潜んでいる。その第一歩として、yt-dlpを知ることは、デジタル時代のリテラシーの一端を手にすることに等しい。

Linux/WSLでghqをインストールする方法

Mon, 27 Oct 2025 18:22:58 +0900

ghqは、リポジトリを一元的に管理するためのCLIツールである。GitHubやGitLabのリポジトリを一貫したパスで管理し、開発環境を整理するのに非常に有効である。
WSL上ではLinux環境として動作するため、Go製のツールであるghqを直接ビルド・配置するのが最も適している。

前提条件

項目	内容
OS	Windows 10 / 11
WSL バージョン	2
Linux ディストリビューション	Ubuntu 22.04 以降
Go言語	1.19 以上（`go install`コマンド対応バージョン）

Goが未インストールの場合は、先にGoのインストール手順（前記事参照）を実施する。

推奨方法：`go install`で直接インストールする

最も標準的で再現性が高い方法は、Go公式ツールチェーンを用いたインストールである。

go install github.com/x-motemen/ghq@latest

インストール後、~/go/bin にバイナリが配置されるため、パスを通す。

echo 'export PATH=$PATH:$(go env GOPATH)/bin' >> ~/.bashrc
source ~/.bashrc

動作確認を行う。

ghq --version

これでghqが利用可能となる。
Goのモジュール管理機能を用いるため、バージョン指定（例：@v1.5.0）も柔軟に対応できる。

代替方法：APT経由（非推奨）

Ubuntuリポジトリにもghqパッケージが存在するが、更新が遅くバージョンが古い。
そのため、最新版を利用したい場合には不向きである。

sudo apt update
sudo apt install ghq

この方法は環境構築を自動化したい場合（例：AnsibleやDockerfileなど）には有効だが、開発者自身の利用には推奨されない。

ソースからのビルド（特殊用途向け）

カスタマイズが必要な場合や、ghqの開発版を試したい場合は、手動でビルドできる。

git clone https://github.com/x-motemen/ghq.git
cd ghq
make install

デフォルトでは$GOPATH/binにバイナリが生成される。
この方法は、Go開発環境の内部構造を理解している場合にのみ選択すべきである。

まとめ

方法	特徴	推奨度
`go install github.com/x-motemen/ghq@latest`	最新版を簡単に導入できる	★★★★★
`apt install ghq`	システム管理に統合されるが古い	★★☆☆☆
ソースからビルド	開発・検証向け	★★★☆☆

補足：環境変数設定の確認

ghqは内部でgitコマンドを利用するため、gitがインストールされていることを確認する。

git --version

また、デフォルトのリポジトリ保存パスは ~/.ghq である。
変更したい場合は環境変数で指定する。

echo 'export GHQ_ROOT=~/dev/src' >> ~/.bashrc
source ~/.bashrc

この構成を採用すれば、WSL上でもLinux環境と同様にghqが安定動作し、GitHubリポジトリの管理を効率化できる。

第3回　Python補完の実践 ― Emacsに頭脳を宿す

Wed, 22 Oct 2025 18:12:52 +0900

ここまでで、LSPとは何か、そしてEmacsがそれをどう扱うかを理解した。

あわせて読みたい

第2回\u3000EmacsがLSPを話す ― クライアントの世界

/第2回\u3000emacsがlspを話す-―-クライアントの世界/

最終回では、実際にPython補完を動かすための構築手順を示す。
目的は単純だ。「なんとなく動いた」ではなく、「なぜそうなるか」を理解したうえで、確信をもって環境を作ることである。
Emacsは設定が複雑なようでいて、理屈が分かれば極めて論理的な道具である。

Python用LSPサーバの選択肢

LSPサーバは、言語ごとに独立した解析プロセスである。
Python用には主に次の二つが使われている。

サーバ	実装	特徴
python-lsp-server（pylsp）	Python製	標準的で扱いやすく、拡張が豊富。Emacsとの親和性が高い。
pyright	TypeScript製（Microsoft）	高速で型解析が強力。静的型を多用するコードベース向け。

どちらもLSP仕様に従うため、クライアント（lsp-mode/eglot）から見れば等価である。
決めるべきは、「柔軟なPython的挙動を重視するか」「型安全性と速度を取るか」だ。

サーバの導入

仮想環境を使っている場合は、その中にインストールするのが望ましい。
グローバルに導入する場合は以下のようにする。

pylspの場合

pip install "python-lsp-server[all]"

これで pylsp コマンドが使えるようになる。
[all] オプションはflake8やmccabeなどLint系のプラグインもまとめて導入する。

pyrightの場合

npm install -g pyright

こちらはNode.js環境が必要である。型チェックを多用するプロジェクト向けだ。

Emacs側の準備

ここからは、LSPクライアントとして lsp-mode を例にとる。
eglot を使う場合も設定は簡略化されるだけで、概念は同じだ。

基本設定例（use-package使用）

(use-package lsp-mode
 :hook (python-mode . lsp-deferred)
 :commands (lsp lsp-deferred)
 :config
 (setq lsp-prefer-flymake nil)) ; flycheckを使う場合

(use-package lsp-ui
 :commands lsp-ui-mode)

(use-package company
 :config
 (global-company-mode))

これでPythonファイルを開いた時に自動でLSPサーバが起動し、
補完・定義ジャンプ・ドキュメント表示などが可能になる。
裏ではlsp-modeがpylspプロセスを立ち上げ、JSON-RPCで通信している。

動作確認

Emacsで任意の.pyファイルを開き、数行書いてみる。
import os の後に os. と打てば、補完候補が即座に表示されるはずだ。
もし表示されない場合は、M-x lsp-describe-session でサーバの状態を確認できる。
通信が確立していれば、そこに pylsp または pyright のプロセス情報が出る。

周辺ツールの統合

LSPは補完だけではなく、周辺ツールとも密接に連携する。
特にPython環境では以下の3つが鉄板である。

自動整形：blacken

(use-package blacken
 :hook (python-mode . blacken-mode))

保存時に black でコードを整形する。

構文チェック：flycheck

(use-package flycheck
 :init (global-flycheck-mode))

エラーをリアルタイムで表示。pylspにも統合されているが、外付けで使うと制御しやすい。

仮想環境切替：pyvenv

(use-package pyvenv
 :config
 (pyvenv-tracking-mode 1))

プロジェクトごとに異なる環境を自動で反映する。

これらを組み合わせることで、補完だけでなく実行環境全体が整う。

`eglot` を使う場合

Emacs 29以降であれば、eglot は標準で使える。
設定は驚くほど少ない。

(use-package eglot
 :hook (python-mode . eglot-ensure))

以上で完了だ。
補完はEmacs標準の completion-at-point に統合され、company も自然に動作する。
構造的には lsp-mode と同じ三層だが、設定と依存が極端に少ない。
LSPという機構そのものを理解する目的なら、まずはeglotで始めるのが良い。

実際の動作の理解

Python補完が動くとき、背後では次のやり取りが行われている。

Emacs → pylsp: "この位置の補完候補をくれ"
pylsp → Emacs: "print, property, process, ..."

単純だが、これがすべての基本である。
サーバが変わってもこの会話形式は変わらない。
だからこそ、EmacsでもVSCodeでも同じ補完が得られる。
LSPという共通言語が、エディタの枠を越えた知能を可能にしている。

まとめ

Python補完を動かすには、

LSPサーバ（pylsp or pyright）を導入し、
Emacsクライアント（lsp-mode or eglot）で通信を確立し、
UI層（company, flycheck, blackenなど）で結果を扱う。

この三層を理解しておけば、どんな構成にも柔軟に対応できる。
Emacsは「設定地獄」と呼ばれがちだが、それは自由の裏返しである。
自分で理屈を掴み、構造を選び、道具を組み立ててこそEmacsである。

終わりに

この三部作を通じて伝えたかったのは、「LSPを理解すれば、Emacsは現代的IDEと同じ地平に立てる」という事実だ。
LSPはEmacsを変えるものではなく、Emacsの自由さを外の世界へ拡張する手段である。
設定例を丸写しにするのではなく、どう動くかを知り、自分の思想に合わせて構築してほしい。
Emacsは道具であり、思想である。
そしてLSPは、その思想を現代に接続するための共通語にすぎない。

第2回　EmacsがLSPを話す ― クライアントの世界

Wed, 22 Oct 2025 18:07:59 +0900

前回、LSP（Language Server Protocol）とは何かを整理した。

あわせて読みたい

第1回\u3000EmacsでPython補完を考える前に ― LSPとは何か

/第1回\u3000emacsでpython補完を考える前に-―-lspとは何か/

今回は、EmacsがそのLSPをどう扱うかを掘り下げる。
EmacsはLSPを直接理解しているわけではなく、クライアントとしてLSPサーバと通信する層を持っている。
その中核となるのが lsp-mode と eglot という二つの実装である。
両者は同じLSPをしゃべるが、思想と構造が根本的に異なる。
この違いを理解することが、自分に合った環境を選ぶ鍵になる。

EmacsにおけるLSPクライアントの役割

LSPクライアントとは、要するに「エディタの代わりにサーバと話す通訳」である。
Emacsが自分で補完や解析を行うわけではない。
代わりに、クライアントがJSON-RPCでLSPサーバに要求を送り、結果を受け取る。
たとえば、ユーザーが関数名の途中まで入力したとき、Emacsはこう動く。

company などの補完UIが「候補を出せ」と要求
lsp-mode（またはeglot）がサーバに textDocument/completion を送信
サーバが解析結果（候補リスト）を返す
クライアントが結果をUI層へ渡す

この通信を隠蔽し、自然な操作感を実現するのがクライアントの仕事である。
つまりLSPクライアントは「通信」と「Emacs統合」の境界に立つ存在である。

`lsp-mode` ― 機能主義と総合化の道

lsp-mode はEmacsにおける最古参かつ最強のLSPクライアントである。
設計思想は明確だ。

「Emacsを現代的IDEの水準に引き上げる」

lsp-mode はLSP仕様のほぼ全てのメソッドを実装している。
補完だけでなく、定義ジャンプ、リネーム、コードアクション、ドキュメント表示、フォーマットなどを統合的に扱う。
さらに、lsp-ui, lsp-treemacs, lsp-ivy などの拡張で、VSCode的な体験を再現できる。
一方で、設定項目が膨大で、依存パッケージも多い。
IDE的快適さを求める代わりに、軽量さと単純さを犠牲にしている。

構造的には、LSPの上にUIや便利関数を積み上げる形だ。
「フル装備の戦車」とでも言うべきクライアントである。

`eglot` ― 簡潔主義とEmacs的統合の道

対する eglot は正反対の思想を持つ。

「Emacsはすでに優れている。LSPはそれを邪魔せず溶け込むべきだ」

eglot は2018年に登場し、Emacs 29で公式に同梱された。
基本コマンドは M-x eglot ひとつ。
特別な設定をほとんど要せず、仮想環境やプロジェクトを自動認識してLSPサーバを起動する。
UI拡張はほぼ持たず、既存の xref（定義ジャンプ）、eldoc（関数ドキュメント）、flymake（警告表示）と自然に統合する。
このシンプルさが「Emacsらしさ」を保つ理由である。

結果、eglot は軽量で安定しており、コードの可読性も高い。
だが、VSCode的な華やかなUIや細かなチューニングはない。
「Emacsそのものを信頼している」派のための実装である。

両者の比較と選択の軸

項目	`lsp-mode`	`eglot`
目的	IDE的統合	Emacs標準との自然な融合
開発母体	独立コミュニティ	GNU Emacs本体
拡張性	高い（UI拡張多数）	控えめ
設定難度	高い	低い
動作の軽さ	中〜重	軽
更新頻度	非常に高い	安定重視

両者の差は、便利さを取るか、純粋さを取るかに尽きる。
自分のEmacsを“戦車”にしたいなら lsp-mode、
“機敏な道具”として維持したいなら eglot を選ぶとよい。

クライアントとUIの分離 ― Emacs哲学の体現

Emacsでは、LSPクライアントとUIは厳密に分離されている。
理由は単純で、自由度と再利用性を保つためである。

company-mode, corfu, icomplete など、補完UIの選択肢は無数にある。
LSPクライアントが特定のUIに依存すると、ユーザーの自由を奪う。
そのためクライアントは「候補を返す」までで止まり、
表示は既存の補完システムに任せるよう設計されている。
この設計は、Emacsの原則――「すべては組み合わせ可能（composable）」――の延長線上にある。

まとめ

EmacsがLSPを扱う際、中心となるのは lsp-mode と eglot という二つのクライアントである。
どちらを選ぶかは「何を求めるか」によって決まる。

IDE的な利便性を求めるなら lsp-mode
Emacsの一体感を重視するなら eglot

重要なのは、どちらを選んでもLSPという共通言語を通じて同じサーバを使えるという事実だ。
道具は違えど、話している言葉は同じ。
次回は、そのサーバ側――すなわち PythonのLSPサーバ実装（pylspとpyright） の実践編に進む。

次の第3回では、実際にEmacsでPython補完を動かし、lsp-mode または eglot と組み合わせて設定する過程を解説する。

第1回　EmacsでPython補完を考える前に ― LSPとは何か

Wed, 22 Oct 2025 17:57:28 +0900

EmacsでPythonを書くとき、最初にぶつかる壁が「補完」である。
関数名や変数名を自動で提示してくれる機能だが、Emacsにおける補完の仕組みは複雑である。単に候補を出すだけではなく、背後に構文解析や通信プロトコルが存在する。
本稿では、設定やプラグインの話をする前に、その背後にある「LSP（Language Server Protocol）」という概念を理解することを目的とする。

LSP以前 ― 言語ごとに分裂していた時代

かつて、Emacsの補完は言語ごとの独自実装に依存していた。
Pythonならjedi.el、C++ならrtags、Javaならeclimといった具合である。
各パッケージが独自に解析を行い、独自のプロトコルで補完情報を渡していた。
結果として、言語が増えるたびに新しいElisp実装が必要になり、保守は煩雑を極めた。
「C言語での定義ジャンプと、Pythonでの補完が全く別物」という状況は当たり前であった。

LSPの登場 ― 共通言語の誕生

その混乱を整理したのがLSP（Language Server Protocol）である。2016年頃、Visual Studio Codeの開発チームが「どの言語でも同じ方法で補完や解析を行える共通プロトコル」を設計した。LSPはエディタと解析サーバのあいだの通信仕様であり、JSON-RPCを使ってやりとりを行う。

LSPを導入したエディタは、もう言語ごとの補完ロジックを持つ必要がない。
エディタは「クライアント」として統一プロトコルを喋り、解析は「サーバ」が行う。
たとえばEmacs・Vim・VSCodeがすべて同じPython解析サーバ（例：pylsp） を使える。
これにより、「解析エンジンは共通、UIは各エディタ流儀」という分業が成立した。

エディタとサーバの関係

LSPでは、以下のような通信が行われる。

Emacs → LSPサーバ：
 textDocument/completion を要求
LSPサーバ → Emacs：
 ["print", "printf", "println"] を返す

これが補完の実体である。
エディタはただ「この位置の候補をくれ」と依頼し、サーバは解析結果を返す。
LSPはその共通の会話の文法を定めたものであり、特定エディタには依存しない。

LSPの三層構造

LSPを理解するうえで重要なのが三層構造である。

UI層 … 候補を画面に出す。company-modeやcorfuが該当する。
クライアント層 … サーバと通信し、データを受け取る。lsp-modeやeglotがここ。
サーバ層 … 実際に言語を解析する。pylspやpyrightなど。

Emacsではこれらが独立しており、ユーザーは好きな組み合わせを選べる。
UIを変えてもサーバは同じ、サーバを変えてもUIはそのまま――この柔軟さこそがEmacs的である。

オープンな標準としてのLSP

LSPはMicrosoft発祥ではあるが、現在はEclipse FoundationのLSP Working Groupによりオープンに策定されている。
仕様はGitHub上で公開され、誰でも提案・修正が可能である。
確かに企業の影響は残るが、プロトコル自体はフリーであり、ロックインされない。
Emacsにおいても、lsp-modeやeglotがこのプロトコルを実装し、純粋に「通信仕様」として扱っている。

まとめ

LSPとは、エディタと解析サーバをつなぐ共通語であり、
従来の「言語ごと・エディタごと」の個別実装を終わらせるものである。
これを理解すれば、EmacsがVSCodeと同じ補完精度を実現できる理由が見えてくるだろう。
次回は、このLSPをEmacsがどう扱うのか、つまりクライアント層の構造と思想を掘り下げていく。

この稿は、次の第2回「EmacsがLSPを話す ― クライアントの世界」へ続く。

あわせて読みたい

第2回\u3000EmacsがLSPを話す ― クライアントの世界

/第2回\u3000emacsがlspを話す-―-クライアントの世界/

macOS launchctl の bootstrap と bootout コマンドの使い方

Wed, 08 Oct 2025 17:21:45 +0900

macOS では、バックグラウンドで動作するサービス（デーモンやエージェント）を管理するために launchd という仕組みが用いられており、これを制御するコマンドが launchctl である。従来は load と unload というサブコマンドが使われていたが、macOS 10.11 El Capitan 以降、これらは「レガシーサブコマンド」として扱われ、代わりに bootstrap と bootout が推奨されるようになった。ただし実際には、2025年現在も多くの記事やスクリプトで従来の load/unload が使われ続けているのが現状である。

本記事では、公式に推奨されている bootstrap と bootout の使い方について解説する。なお、この記事で扱う内容は macOS 10.11 以降を前提としている。

bootstrap と bootout の基本

bootstrap と bootout は、それぞれ従来の load と unload に相当するコマンドである。最大の違いは、ドメインを明示的に指定する必要があるという点だ。

bootstrap: サービスをドメインに登録して起動する（load の代替）
bootout: サービスを停止してドメインから削除する（unload の代替）

従来の方式では、plist ファイルのパスから暗黙的にドメインが判別されていたが、新しい方式では明示的に指定することで、より正確な制御が可能になるという設計思想である。

ドメインの種類と意味

launchd におけるドメインとは、サービスがどのレベル・どのユーザーのために動作するかを表す概念である。主なドメインは以下の3種類だ。

system ドメイン

システム全体で動作するデーモンのためのドメインである。root 権限で実行され、すべてのユーザーに影響する。通常、/Library/LaunchDaemons/ に配置された plist ファイルがこのドメインで動作する。

gui/UID ドメイン

特定のユーザーがグラフィカルログイン（GUI セッション）している間だけ動作するエージェントのためのドメインである。UID はユーザー ID を表す数値で、macOS では最初に作成されたユーザーは通常 501 となる。自分の UID は id -u コマンドで確認できる。~/Library/LaunchAgents/ や /Library/LaunchAgents/ に配置されたエージェントは、基本的にこのドメインで動作する。

user/UID ドメイン

特定のユーザー権限で動作するが、ログインの有無に関わらず常駐するバックグラウンドサービスのためのドメインである。GUI は使用できないが、PC 起動中は常に動き続ける。このドメインは macOS 10.11 以降で追加された比較的新しい概念である。

基本的な使い方

システムデーモンの登録と削除

システム全体で動作するデーモンを扱う場合、system ドメインを指定する。root 権限が必要なため、sudo を付けて実行する必要がある。

# 登録（起動）
sudo launchctl bootstrap system /Library/LaunchDaemons/com.example.daemon.plist

# 削除（停止）
sudo launchctl bootout system /Library/LaunchDaemons/com.example.daemon.plist

ユーザーエージェントの登録と削除

ログイン中のユーザーのために動作するエージェントを扱う場合、gui/UID ドメインを指定する。まず自分の UID を確認してから、その値を使ってコマンドを実行する。

# UID を確認
id -u
# 例: 501 と表示される

# 登録（起動）
launchctl bootstrap gui/501 ~/Library/LaunchAgents/com.example.agent.plist

# 削除（停止）
launchctl bootout gui/501 ~/Library/LaunchAgents/com.example.agent.plist

スクリプト内で動的に UID を取得する場合は、以下のように記述できる。

#!/bin/bash

# 現在ログイン中のユーザーの UID を取得
USER_ID=$(id -u)

# 登録
launchctl bootstrap gui/$USER_ID ~/Library/LaunchAgents/com.example.agent.plist

# 削除
launchctl bootout gui/$USER_ID ~/Library/LaunchAgents/com.example.agent.plist

サービスの状態確認

登録されているサービスの一覧を確認するには、launchctl list コマンドを使う。特定のサービスを grep で絞り込むことも可能だ。

# すべてのサービスを表示
launchctl list

# 特定のサービスを検索
launchctl list | grep com.example

より詳細な情報を得るには、launchctl print コマンドを使う。

# システムドメインの情報を表示
sudo launchctl print system

# 特定のユーザードメインの情報を表示
launchctl print gui/501

# 特定のサービスの詳細を表示
launchctl print gui/501/com.example.agent

ただし、print コマンドの出力形式は公式には構造化されておらず、バージョン間で変更される可能性があるため、スクリプトでのパース処理には依存しないことが推奨されている。

実行中のサービスの再起動

既に動作しているサービスを再起動したい場合、bootout してから bootstrap し直す方法もあるが、より簡単な方法として kickstart コマンドが用意されている。

# サービスを再起動（-k オプションで既存のインスタンスを終了してから起動）
launchctl kickstart -k gui/501/com.example.agent

-k オプションを付けると、既に動作中のインスタンスを終了してから新しいインスタンスを起動する。オプションなしで実行すると、既に動作中の場合はエラーとなる。

enable と disable の使い分け

bootstrap/bootout とは別に、enable と disable というサブコマンドも存在する。これらはサービスを有効化・無効化するためのもので、次回のブート時やログイン時にサービスを自動起動するかどうかを制御する。

# サービスを無効化（次回から自動起動しない）
sudo launchctl disable system/com.example.daemon

# サービスを有効化（次回から自動起動する）
sudo launchctl enable system/com.example.daemon

注意点として、disable でサービスを無効化した後は、単に bootstrap しようとしてもエラーになる。再度有効にするには、まず enable を実行してから bootstrap する必要がある。

従来の load/unload との対応関係

従来の方式と新しい方式の対応関係をまとめると、以下のようになる。

従来の方式	新しい方式
`launchctl load /Library/LaunchDaemons/service.plist`	`sudo launchctl bootstrap system /Library/LaunchDaemons/service.plist`
`launchctl unload /Library/LaunchDaemons/service.plist`	`sudo launchctl bootout system /Library/LaunchDaemons/service.plist`
`launchctl load ~/Library/LaunchAgents/agent.plist`	`launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/agent.plist`
`launchctl unload ~/Library/LaunchAgents/agent.plist`	`launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/agent.plist`

従来の方式では plist ファイルのパスから自動的にドメインが判別されていたが、新しい方式ではドメインを明示的に指定する必要がある。この変更により、より正確な制御が可能になったとされているが、実際には記述量が増え、コマンドも覚えにくくなったという側面もある。

よくある問題とトラブルシューティング

Permission denied エラー

システムドメインのサービスを操作する際に sudo を付け忘れると、権限エラーが発生する。

# エラー例
launchctl bootstrap system /Library/LaunchDaemons/service.plist
# → Permission denied

# 正しい実行方法
sudo launchctl bootstrap system /Library/LaunchDaemons/service.plist

Operation now in progress エラー

サービスが既に登録されている状態で再度 bootstrap を実行すると、このエラーが発生する。この場合は、まず bootout で削除してから再度 bootstrap する必要がある。

# 一度削除してから再登録
sudo launchctl bootout system /Library/LaunchDaemons/service.plist
sudo launchctl bootstrap system /Library/LaunchDaemons/service.plist

あるいは、前述の kickstart -k コマンドを使うことで、より簡潔に再起動できる。

Bootstrap failed: 5: Input/output error

サービスを disable した後に bootstrap しようとすると、このエラーが発生することがある。この場合は、まず enable で有効化してから bootstrap する必要がある。

# 正しい手順
sudo launchctl enable system/com.example.daemon
sudo launchctl bootstrap system /Library/LaunchDaemons/com.example.daemon.plist

SIP によるエラー

System Integrity Protection（SIP）が有効な場合、システムが管理する一部の plist ファイルは変更できない。このような場合、以下のようなエラーメッセージが表示される。

Operation not permitted while System Integrity Protection is engaged

この場合、基本的には操作を諦めるか、SIP を無効化する必要がある（ただし SIP の無効化はセキュリティリスクを伴うため推奨されない）。

まとめ

bootstrap と bootout は、macOS 10.11 以降で推奨されている launchd サービスの管理コマンドである。従来の load/unload と比べて、ドメインを明示的に指定する必要があるため、より正確な制御が可能になった反面、コマンドが冗長になり覚えにくくなったという側面もある。

実際には、2025年現在も多くの記事やスクリプトで従来の load/unload が使われ続けており、これらのコマンドも依然として動作する。ただし、公式には bootstrap/bootout の使用が推奨されているため、新しく書くスクリプトではこちらを使うのが望ましいとされている。

システムの根幹に関わる launchd の操作は慎重に行う必要がある。特に /Library/LaunchDaemons/ や /System/Library/ 以下のファイルを扱う際は、誤った操作がシステム全体に影響を及ぼす可能性があるため、十分に注意して作業を進めることが重要である。

出典

Stack Overflow: launchd: Confusion on the sematics of bootstrap/bootout for controlling services on macOS
Ask Different: launchd: Confusion on semantics of bootstrap and bootout etc. after reading manual pages
Alan Siu’s Blog: launchctl “new” subcommand basics for macOS
SS64.com: launchctl Man Page - macOS
The Terminal Blogger: Dear Launchctl, We’re All Using You Wrong
Babo D’s Corner: Launchctl 2.0 Syntax

ghqで高速リポジトリ移動を実現する最小設定

Tue, 16 Sep 2025 03:03:42 +0900

ghqを使ってGitリポジトリを管理している際、複数のリポジトリ間を素早く移動したい場面は日常的に発生する。複雑な設定や多機能なツールの組み合わせではなく、最小限の設定で最大の効果を得る方法を紹介する。

前提環境

ghqがインストールされていること
fzfがインストールされていること
Bash または Zsh を使用していること

fzfのインストールは以下のコマンドで実行できる：

# macOS (Homebrew)
brew install fzf

# Ubuntu/Debian
sudo apt install fzf

# CentOS/RHEL
sudo yum install fzf

最小構成での設定方法

シェルの設定ファイル（.bashrc または .zshrc）に以下の1行を追加するだけで、高速なリポジトリ移動が可能になる：

alias g='cd $(ghq root)/$(ghq list | fzf)'

この設定により、g コマンドを実行するとfzfの絞り込み画面が表示され、リポジトリ名を入力して絞り込み、Enterキーで該当するリポジトリのディレクトリに移動できる。

設定後は以下のコマンドで設定を反映させる：

source ~/.zshrc # Zshの場合
source ~/.bashrc # Bashの場合

実際の使用例

例えば、以下のようなリポジトリ構成があるとする：

~/ghq/github.com/
├── user/my-blog
├── user/api-server
├── user/frontend-app
└── company/internal-tool

g コマンドを実行すると、fzfの絞り込み画面が表示される。ここで「blog」と入力すると user/my-blog が絞り込まれ、Enterキーを押すことで即座に該当ディレクトリに移動する。部分一致での検索が可能なため、「front」と入力すれば user/frontend-app にマッチする。

このような直感的な操作により、従来の cd コマンドで長いパスを入力する必要がなくなり、開発効率が大幅に向上する。

他の選択肢との比較

リポジトリ移動を効率化する方法として、pecoを使用する選択肢もある。pecoは日本で人気のあるツールで、基本的な絞り込み機能を提供する。しかし、現在ではfzfの方が機能的に優れており、より活発に開発されている状況である。

fzfとpecoの主な違いは、fzfがプレビュー機能や複数選択機能を標準で備えている点にある。また、GitHubでのスター数を見ると、fzfが60,000以上のスターを獲得している一方で、pecoは7,000程度となっており、コミュニティの規模と活発度に大きな差がある。

将来的な拡張性を考慮した場合、fzfを選択しておくことで、プレビュー機能やその他の高度な機能を後から追加できる余地が残される。

macOSでtacコマンドを使えるようにする設定方法

Tue, 16 Sep 2025 02:23:36 +0900

pecoなどのCLIツールを使用する際に、Linuxでは標準的なtacコマンドがmacOSでは利用できずエラーが発生することがある。この記事では、macOSでtacコマンドを使えるようにするための設定手順を記録する。

検証環境

macOS
Homebrew導入済み
bash または zsh

tacコマンドとは

tacコマンドは、ファイルの内容を行単位で逆順に出力するLinuxの標準コマンドである。catコマンドの逆の動作を行うため、“tac”（catの逆綴り）という名前が付けられている。主にログファイルの最新エントリから順に表示したい場合や、履歴検索ツールでの逆順処理に使用される。

macOSでのtacコマンド不在問題

macOSでpecoなどのツールを使用する際に、以下のようなエラーが発生する場合がある：

-bash: tac: command not found

これは、macOSのBSD系ユーティリティにはGNU系のtacコマンドが含まれていないことが原因である。多くのLinux環境で当然のように使用されているコマンドであるため、LinuxからmacOSに移行した際によく遭遇する問題となっている。

coreutilsパッケージによる解決

最も確実で標準的な解決方法は、GNU coreutilsパッケージをHomebrewでインストールすることである。GNU coreutilsは、Linux環境で使用されている基本的なコマンド群をmacOSでも利用できるようにするパッケージである。

brew install coreutils

このインストールにより、GNU版の各種コマンドがgプレフィックス付きで利用可能になる。tacコマンドの場合はgtacとして使用できるようになる。

インストール後の動作確認：

echo -e "first\nsecond\nthird" | gtac
# 出力：
# third
# second
# first

エイリアスによる透過的な利用

gtacコマンドが使用できるようになったが、既存のスクリプトや設定でtacとして呼び出される場合に対応するため、エイリアスを設定する必要がある。使用しているシェルの設定ファイルにエイリアスを追加することで、tacコマンドをgtacに自動的に変換できる。

bashを使用している場合は~/.bashrcまたは~/.bash_profileに、zshを使用している場合は~/.zshrcに以下の設定を追加する：

alias tac='gtac'

設定を反映させるため、設定ファイルを再読み込みするか、新しいターミナルセッションを開始する：

# bashの場合
source ~/.bashrc

# zshの場合
source ~/.zshrc

設定の確認

エイリアス設定後、tacコマンドが正常に動作することを確認する：

# tacコマンドのテスト
echo -e "line1\nline2\nline3" | tac

# 期待される出力：
# line3
# line2
# line1

また、エイリアスが正しく設定されているかはaliasコマンドで確認できる：

alias | grep tac
# 出力: alias tac='gtac'

pecoでの履歴検索への適用

この設定により、pecoを使用した履歴検索でtacコマンドが正常に動作するようになる。一般的なpeco設定では、コマンド履歴を逆順で表示するためにtacが使用されており、以下のような設定が機能するようになる：

# 例：pecoを使った履歴検索の設定
function peco-select-history() {
 local tac
 if which tac > /dev/null; then
 tac="tac"
 elif which tail > /dev/null; then
 tac="tail -r"
 fi
 BUFFER=$(history -n 1 | eval $tac | peco --query "$LBUFFER")
 CURSOR=$#BUFFER
 zle clear-screen
}

まとめ

macOSでのtacコマンド不在問題は、GNU coreutilsパッケージのインストールとエイリアス設定により解決できる。この設定により、Linux環境で作成されたスクリプトやツール設定をmacOSでもそのまま利用できるようになる。特にpecoやその他のCLIツールを使用する開発環境において、この設定は必須といえる。同様の手法は、GNU系の他のコマンド（gls、ggrepなど）にも適用でき、Linux環境との互換性を高めることができる。

macOSでBash起動時のロケール警告を解決する方法

Tue, 16 Sep 2025 01:54:34 +0900

macOSでシェルをfishからbashに変更した際、ターミナル起動時に以下のような警告が表示されることがある。

-bash: 警告: setlocale: LC_COLLATE: cannot change locale (): No such file or directory

この警告は機能上の問題を引き起こすわけではないが、毎回表示されるため作業の邪魔になる。本記事では、この警告を解消する対症療法的な解決方法を記録する。

環境

macOS（Homebrewでbashをインストール済み）
シェルをfishからbashに変更後
/opt/homebrew/bin/bashを使用

問題の原因分析

現在のロケール設定の確認

まず、現在のロケール設定を確認する。

locale

問題がある場合、以下のような出力になることが多い。

LANG=""
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

環境変数の確認も行う。

env | grep -E "(LANG|LC_)"

このコマンドで表示される内容とlocaleコマンドの出力に不一致がある場合、設定の競合が発生している可能性が高い。

根本原因の推定

警告メッセージのcannot change locale ():の括弧内が空になっているのは、どこかでロケール関連の環境変数が空文字列に設定されているためである。これは以下のような要因で発生する可能性がある。

以前使用していたシェル（fish等）の設定残骸
システムアップデート時の設定の不整合
複数のツールによる環境変数の競合

解決方法

基本的な対症療法

個人用の設定ファイルを作成し、明示的にロケールを設定する。これにより、不完全な設定を上書きできる。

echo 'export LANG=en_US.UTF-8' > ~/.bash_profile

設定を即座に反映させる。

source ~/.bash_profile

設定内容の選択指針

ロケール設定には以下の選択肢がある。

英語環境での自然な並び順を優先する場合（推奨）

export LANG=en_US.UTF-8

この設定により、lsコマンドやファイルソートで大文字小文字を考慮した辞書順になる。具体的には、Apple、apple、Banana、bananaの順序で表示される。

純粋なASCII順序を優先する場合

export LANG=C

この設定では、ASCII値順（数字→大文字→小文字）でソートされる。プログラマー向けの厳密な順序だが、一般的な用途では直感的でない順序になることがある。

設定の確認

設定後、新しいターミナルを開いて以下を確認する。

locale

すべてのLC_*項目が設定したロケール（例：en_US.UTF-8）になっていれば成功である。また、警告メッセージが表示されなくなることを確認する。

追加の対処法

ターミナルアプリ固有の設定確認

一部のターミナルアプリケーションは独自の設定ファイルを持つ場合がある。

cat "/etc/bashrc_$TERM_PROGRAM" 2>/dev/null || echo "Terminal-specific bashrc not found"

利用可能なロケールの確認

システムでサポートされているロケールを確認したい場合は以下を実行する。

locale -a | grep -E "(en_US|ja_JP|C$)"

注意事項

この方法は対症療法であり、根本的な原因（どこで空文字列が設定されているか）を解決するものではない。しかし、実用上は十分な解決策となる。

長期間使用しているシステムでは、様々なツールのインストール・アンインストールにより設定の断片が残存することがある。完全な解決を求める場合は、クリーンインストールが最も確実な方法である。

参考資料

Giteaへの既存コードpushでrejectedエラーを解決する方法

Thu, 11 Sep 2025 17:45:22 +0900

既存のローカルプロジェクトをGiteaサーバーにpushしようとした際、「Updates were rejected because the remote contains work that you do not have locally」エラーが発生した。このエラーの原因と解決方法について記録する。

再現環境

ローカル環境：macOS
Git：既存のローカルリポジトリ（masterブランチ）
リモート：Giteaサーバー（プライベートネットワーク内）
接続方式：SSH

エラーの発生状況

実行したコマンド

# リモートリポジトリを追加
git remote add origin user@xxx.xxx.xxx.xxx:org/repository-name.git

# pushを実行
git push -u origin master

発生したエラー

To xxx.xxx.xxx.xxx:org/repository-name.git
 ! [rejected] master -> master (fetch first)
error: failed to push some refs to 'xxx.xxx.xxx.xxx:org/repository-name.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

エラーの原因分析

このエラーが発生する主な原因は、リモートリポジトリとローカルリポジトリの履歴が一致していないことである。具体的には以下のケースが考えられる。

最も一般的な原因

Giteaでリポジトリを作成する際に「Initialize with README」オプションを有効にしたため、リモートリポジトリに初期コミット（README.md）が存在していた。一方、ローカルでは既存のプロジェクトを独立してgit管理していたため、両者に共通の祖先コミットが存在しない状態となった。

その他の原因

他の開発者が既にコミットをプッシュしている
複数の場所から同じリポジトリにプッシュを試行している
リモートリポジトリが予期せず変更されている

解決方法

手順1: リモートの変更を確認

まず、リモートにどのような変更があるかを確認する。

git fetch origin
git log origin/master --oneline

手順2: 無関係な履歴をマージしてpull

以下のコマンドを実行して、無関係な履歴を統合する。

git pull origin master --allow-unrelated-histories --no-rebase

手順3: 競合の解決（必要な場合）

README.mdなどでマージ競合が発生した場合は、手動で解決する。

# 競合ファイルを編集後
git add .
git commit -m "Resolve merge conflicts"

手順4: 最終的なpush

競合を解決できたら、改めてpushを実行する。

git push origin master

予防方法

既存コードをpushする予定がある場合は、Giteaでリポジトリを作成する際に以下の自動生成オプションを無効にする。

README.mdの自動生成
.gitignoreの自動生成
ライセンスファイルの自動生成

新規プロジェクトを開始する場合は、以下の手順を推奨する。

Giteaで空のリポジトリを作成
ローカルでgit cloneを実行
cloneしたディレクトリ内で開発を開始

この方法により、最初から履歴が一致した状態で開発を進められる。

技術的背景

–allow-unrelated-historiesオプションについて

Gitは通常、共通の祖先を持たないブランチ同士のマージを拒否する。--allow-unrelated-historiesオプションは、この制限を解除して無関係な履歴同士をマージすることを可能にする。

プルストラテジーの選択

git pullコマンド実行時に以下のエラーが発生する場合がある。

hint: You have divergent branches and need to specify how to reconcile them.

この場合は、マージ戦略を明示的に指定する必要がある。

# マージ戦略を使用（推奨）
git pull origin master --allow-unrelated-histories --no-rebase

# またはリベース戦略を使用
git pull origin master --allow-unrelated-histories --rebase

マージ戦略を選択することで、両方の履歴が保持されたマージコミットが作成される。

まとめ

このエラーは、Git初心者が既存コードをリモートリポジトリにpushする際によく遭遇する問題である。根本的な原因は履歴の不一致であり、--allow-unrelated-historiesオプションを使用することで解決できる。

今後は、リポジトリ作成時の設定に注意を払い、適切なワークフローを選択することで、このような問題を予防できる。特に、既存プロジェクトをGitで管理し始める際は、リモートリポジトリを完全に空の状態で作成することが重要である。

WSL環境でMac風のpbcopy/pbpasteを実現する方法

Sun, 17 Aug 2025 13:47:19 +0900

前提環境

この記事は以下の環境での動作を前提としている。

Windows 10/11
WSL2（Windows Subsystem for Linux 2）
Ubuntu 20.04以降（他のディストリビューションでも同様の手順で可能）
Bash または Zsh シェル

背景と課題

Macユーザーであれば、コマンドラインからクリップボードを操作する際にpbcopyとpbpasteコマンドを使用することに慣れているだろう。これらのコマンドは非常に便利で、パイプを使ってテキストをクリップボードにコピーしたり、クリップボードの内容を取得したりできる。

一方、WSL環境では標準でこのような機能は提供されていない。Linux用のクリップボードツールであるxclipをインストールしても、これはX Window System内でのクリップボード操作に留まり、Windowsのシステムクリップボードとは連携しない。つまり、WSL内でxclipを使ってコピーした内容を、Windows側のアプリケーションで貼り付けることはできないのである。

WindowsのネイティブなクリップボードAPI

実は、Windowsにはclip.exeというコマンドラインツールが標準で付属している。このツールを使用することで、パイプ経由でテキストをクリップボードに書き込むことが可能である。

echo "Hello World" | clip.exe

上記のコマンドを実行すると、「Hello World」がWindowsのクリップボードにコピーされ、任意のWindowsアプリケーションで貼り付けることができる。

ただし、clip.exeは書き込み専用であり、クリップボードの内容を読み取る機能は提供されていない。そのため、Macのpbpasteに相当する機能を実現するには別の方法が必要となる。

PowerShellを活用したクリップボード読み取り

Windowsでクリップボードの内容を取得するには、PowerShellのGet-Clipboardコマンドレットを使用する。WSL内からPowerShellを呼び出すことで、この機能を利用できる。

powershell.exe -command "Get-Clipboard"

このコマンドを実行すると、現在のクリップボードの内容がターミナルに出力される。なお、-commandパラメータは省略可能であり、以下のように短縮して記述することも可能である。

powershell.exe "Get-Clipboard"

エイリアスによる利便性の向上

毎回長いコマンドを入力するのは非効率的であるため、エイリアスを設定してMacと同様の使い勝手を実現する。使用しているシェルの設定ファイル（Bashの場合は~/.bashrc、Zshの場合は~/.zshrc）に以下の行を追加する。

alias pbcopy='clip.exe'
alias pbpaste='powershell.exe -command "Get-Clipboard"'

設定を反映するために、シェルを再起動するか、以下のコマンドを実行する。

# Bashの場合
source ~/.bashrc

# Zshの場合 
source ~/.zshrc

実際の使用例

エイリアスを設定した後は、Macと同様の感覚でクリップボード操作が可能になる。以下に実用的な使用例を示す。

基本的な使用方法

# テキストをクリップボードにコピー
echo "テスト文字列" | pbcopy

# クリップボードの内容を表示
pbpaste

ファイルの内容をクリップボードにコピー

# SSH公開鍵をクリップボードにコピー（GitHubへの登録などに便利）
cat ~/.ssh/id_rsa.pub | pbcopy

# 設定ファイルの内容をクリップボードにコピー
cat ~/.vimrc | pbcopy

Gitとの連携

# 最新5件のコミット履歴をクリップボードにコピー
git log --oneline -5 | pbcopy

# 現在のブランチ名をクリップボードにコピー
git branch --show-current | pbcopy

# 現在のリモートURLをクリップボードにコピー
git remote get-url origin | pbcopy

ディレクトリパスの活用

# 現在のディレクトリパスをクリップボードにコピー
pwd | pbcopy

# 特定のファイルの絶対パスをクリップボードにコピー
readlink -f example.txt | pbcopy

パフォーマンスと制限事項

このアプローチにはいくつかの注意点がある。まず、powershell.exeの起動には若干の時間がかかるため、pbpasteの実行速度は純粋なLinuxコマンドと比較して遅くなる。ただし、日常的な使用においては実用上問題となることは少ない。

また、非常に大きなテキストをクリップボードに格納する場合、PowerShellの制限によって一部のデータが切り取られる可能性がある。通常の開発作業で扱うテキストサイズであれば問題ないが、大容量のデータを扱う場合は注意が必要である。

さらに、この方法はWSLからWindowsの実行ファイルを呼び出すため、WSL2の場合はネットワークを介した通信が発生する。セキュリティ設定によっては、この通信が制限される可能性もある。

まとめ

WSL環境においても、Windowsの標準機能とPowerShellを組み合わせることで、Macのpbcopy/pbpasteと同等の機能を実現できる。エイリアスを設定することで、Macからの移行時も違和感なく使用できるようになる。

この方法の最大の利点は、追加のソフトウェアをインストールすることなく、Windowsの標準機能のみで実現できることである。WSLでの開発効率を向上させる簡単で実用的な設定として、ぜひ活用していただきたい。

LinuxでmacOS風クリップボード操作を実現するxclipの設定方法

Sat, 09 Aug 2025 20:03:51 +0900

この記事の内容は、X11ウィンドウシステムを使用するLinux環境で動作確認している。Wayland環境ではwl-clipboardパッケージを使用する必要があるため、事前に使用環境を確認してほしい。また、記事中のコマンド例は、Debian/Ubuntu系ディストリビューションでの実行を前提としている。

LinuxでのCLIクリップボード操作の必要性

Linuxでコマンドライン作業をしていると、コマンドの出力結果をブラウザやテキストエディタに貼り付けたい場面が頻繁にある。しかし、標準的なLinux環境では、ターミナル出力を直接システムクリップボードに送る機能が用意されていない。一方、macOSではpbcopyとpbpasteコマンドが標準で提供されており、パイプを使って簡単にクリップボード操作ができる。Linuxでも同様の機能を実現するためのツールがxclipである。

xclipは、X11環境でコマンドライン出力をシステムクリップボードに送ったり、クリップボードの内容をターミナルに出力したりできる軽量なユーティリティである。このツールを適切に設定することで、macOSと同じような感覚でクリップボード操作を行うことができる。

xclipのインストール手順

xclipのインストール方法は、使用しているLinuxディストリビューションによって異なる。主要なディストリビューションでの手順を以下に示す。

Debian系（Ubuntu、Linux Mint等）では、aptパッケージマネージャーを使用してインストールできる。まずパッケージリストを更新してから、xclipパッケージをインストールする。

sudo apt update
sudo apt install xclip

Red Hat系（CentOS、RHEL、Fedora等）では、使用しているバージョンに応じてyumまたはdnfを使用する。Fedoraの場合は以下のコマンドでインストールできる。

sudo dnf install xclip

CentOS 7やRHEL 7の場合は、EPELリポジトリを有効にしてからインストールする必要がある。

sudo yum install epel-release
sudo yum install xclip

Arch Linuxでは、pacmanパッケージマネージャーを使用してインストールできる。

sudo pacman -S xclip

インストールが完了したら、簡単なテストを行ってxclipが正常に動作することを確認する。

echo "test message" | xclip -selection clipboard

このコマンドを実行後、テキストエディタやブラウザでCtrl+Vを押して「test message」が貼り付けられれば、インストールは成功している。

xclipの基本的な使用方法

xclipを使用してクリップボード操作を行う場合、主に-selection clipboardオプションを使用する。このオプションを指定することで、一般的なアプリケーションでCtrl+C/Ctrl+Vで使用するクリップボードにアクセスできる。

コマンド出力をクリップボードにコピーする場合は、パイプを使ってxclipに出力を渡す。例えば、現在のディレクトリの詳細なファイル一覧をクリップボードにコピーしたい場合は、以下のコマンドを使用する。

ls -la | xclip -selection clipboard

ファイルの内容をクリップボードにコピーしたい場合は、リダイレクションを使用する。

xclip -selection clipboard < file.txt

クリップボードの内容を表示したい場合は、-oオプション（出力オプション）を使用する。

xclip -selection clipboard -o

-selection clipboardは頻繁に使用するため、-sel clipと短縮形で記述することも可能である。

macOS風エイリアスの設定方法

MacとLinuxの両方を使用している場合、同じコマンドでクリップボード操作ができると非常に便利である。macOSのpbcopyとpbpasteコマンドと同じ感覚で使用できるように、bashまたはzshの設定ファイルにエイリアスを追加する。

bashを使用している場合は、ホームディレクトリの.bashrcファイルに以下の行を追加する。

alias pbcopy='xclip -selection clipboard'
alias pbpaste='xclip -selection clipboard -o'

zshを使用している場合は、.zshrcファイルに同じ内容を追加する。設定を手動で編集するか、以下のコマンドで一括追加できる。

echo 'alias pbcopy="xclip -selection clipboard"' >> ~/.bashrc
echo 'alias pbpaste="xclip -selection clipboard -o"' >> ~/.bashrc
source ~/.bashrc

設定後は、macOSと全く同じコマンドでクリップボード操作が可能になる。

実際の活用例

エイリアス設定後の具体的な活用例をいくつか紹介する。これらの例は、日常的な開発作業で頻繁に使用する場面である。

ファイルの内容をクリップボードにコピーする場合：

pbcopy < config.json

コマンド実行結果をクリップボードにコピーする場合：

git log --oneline --graph | pbcopy

システム情報をクリップボードにコピーする場合：

uname -a | pbcopy

クリップボードの内容をファイルに保存する場合：

pbpaste > output.txt

SSH公開鍵をクリップボードにコピーする場合：

pbcopy < ~/.ssh/id_rsa.pub

これらの例のように、パイプやリダイレクションと組み合わせることで、様々な場面でクリップボード操作を活用できる。特に、長いコマンド出力やファイル内容を他のアプリケーションに貼り付ける際に、マウス操作によるコピー&ペーストよりも効率的である。

その他のクリップボードツールとの比較

X11環境でのクリップボード操作ツールとしては、xclip以外にもxselがある。xselも同様の機能を提供するが、xclipの方が一般的に広く使用されており、ドキュメントやコミュニティサポートが充実している。また、パッケージマネージャーでの提供状況もxclipの方が良好である。

Wayland環境を使用している場合は、wl-clipboardパッケージのwl-copyとwl-pasteコマンドを使用する必要がある。使用方法はxclipと類似しているが、オプションの指定方法が異なるため注意が必要である。

現在の環境がX11かWaylandかを確認するには、以下のコマンドを実行する。

echo $XDG_SESSION_TYPE

出力が「x11」であればxclipを、「wayland」であればwl-clipboardを使用することを推奨する。

この設定により、LinuxとmacOSの間での作業環境の切り替えが円滑になり、クリップボード操作に関する認知的負荷を軽減できる。特に、複数のOSを使い分けている開発者にとっては、コマンドの統一性が作業効率の向上に大きく貢献する。

AWKを使った簡単な合計計算の方法

Thu, 19 Dec 2024 11:02:34 +0900

AWKはテキスト処理に非常に便利なツールであり、数値の合計を簡単に計算する方法を備えています。本記事では、AWKを使用して数値の合計を求める方法について解説します。

背景

シェルスクリプトやコマンドラインで処理するデータには、数値が複数行にわたって出力されることがよくあります。例えば、以下のような出力があるとします：

これらの数値の合計を求める必要がある場合、AWKを使うことで簡単に処理できます。

基本コマンド

以下のコマンドを使用すると、入力データの合計を計算できます：

awk '{sum += $1} END {print sum}'

コマンドの仕組み

{sum += $1}

各行の1列目（$1）を変数sumに加算します。
sumは最初に自動的に0で初期化されます。

END {print sum}

すべての行を処理し終えた後にENDブロックが実行され、合計値sumを出力します。

実例

データの例

以下のような数値データを持つファイルdata.txtがあるとします：

このファイルの合計を計算するには、以下のコマンドを実行します：

cat data.txt | awk '{sum += $1} END {print sum}'

出力結果

`find`コマンドとの組み合わせ

複数のJSONファイルに対してPythonスクリプトを実行し、その結果の合計を求めるケースを考えます。

以下のコマンドを使用します：

find . -name "*.json" -exec python a.py {} \; | awk '{sum += $1} END {print sum}'

findコマンドで.jsonファイルを検索。
各ファイルに対してpython a.pyを実行。
AWKで出力結果を集計し、合計値を出力。

出力例

応用例

AWKのsum変数を応用して、さまざまな計算が可能です：

平均値の計算

awk '{sum += $1; count++} END {print sum / count}'

最大値と最小値の計算

awk 'NR == 1 || $1 > max {max = $1} NR == 1 || $1 < min {min = $1} END {print "Max:", max, "Min:", min}'

まとめ

AWKはシンプルな構文で強力なテキスト処理を可能にするツールです。特に数値データの合計計算は、短いコマンドで簡単に実現できます。ぜひ活用してみてください！

[Linux] 一時的にスワップファイルを作成する

Wed, 20 Nov 2024 18:18:16 +0900

ビルド時や一時的な高負荷作業でメモリ不足が発生する場合、スワップファイルを一時的に追加することで問題を回避できます。本記事では、一時的なスワップファイルを作成して使用し、作業終了後に削除する手順と、それを効率化するスクリプトをご紹介します。

スワップファイルとは？

スワップファイルは、物理メモリが不足した際にディスク上の領域を仮想メモリとして利用する仕組みです。ただし、ディスクはメモリよりも遅いため、スワップの使用頻度が高いとパフォーマンスに影響を及ぼす可能性があります。そのため、一時的にスワップを増やして高負荷作業を乗り切り、作業終了後に削除する運用が適しています。

一時的なスワップファイルを作成する手順

1. 一時的なスワップファイルを作成

以下のコマンドで、4GBのスワップファイルを作成します（サイズは用途に応じて変更可能）。

sudo fallocate -l 4G /tmp/swapfile_temp

💡 fallocateが使用できない場合は、以下のコマンドを使用します:

sudo dd if=/dev/zero of=/tmp/swapfile_temp bs=1M count=4096

2. ファイルの権限を設定

スワップファイルのセキュリティを確保するため、600の権限を設定します。

sudo chmod 600 /tmp/swapfile_temp

3. スワップファイルを有効化

スワップファイルをスワップ領域としてフォーマットし、有効化します。

sudo mkswap /tmp/swapfile_temp
sudo swapon /tmp/swapfile_temp

4. スワップ状況を確認

現在のスワップ領域を確認して、追加されたスワップが有効になっているか確認します。

swapon --show

5. 作業を実行

ビルドや高負荷の処理を実行します。スワップが有効になっていることで、メモリ不足によるプロセスの停止を回避できます。

6. スワップファイルを無効化

作業が終了したら、以下のコマンドでスワップファイルを無効化します。

sudo swapoff /tmp/swapfile_temp

7. スワップファイルを削除

スワップファイルを削除してディスク容量を解放します。

sudo rm /tmp/swapfile_temp

一時的なスワップファイルを効率化するスクリプト

毎回コマンドを入力するのが手間な場合、スクリプトを作成することで効率化できます。以下のスクリプトは、一時的なスワップを追加・削除する機能を提供します。

スクリプト: `temporary_swap.sh`

#!/bin/bash

SWAPFILE="/tmp/swapfile_temp"
SIZE="4G"

if [ "$1" == "add" ]; then
 echo "Adding temporary swap file..."
 sudo fallocate -l $SIZE $SWAPFILE
 sudo chmod 600 $SWAPFILE
 sudo mkswap $SWAPFILE
 sudo swapon $SWAPFILE
 echo "Temporary swap file added."
elif [ "$1" == "remove" ]; then
 echo "Removing temporary swap file..."
 sudo swapoff $SWAPFILE
 sudo rm $SWAPFILE
 echo "Temporary swap file removed."
else
 echo "Usage: $0 {add|remove}"
fi

スクリプトの使い方

スクリプトを作成して実行権限を付与します。

chmod +x temporary_swap.sh

スワップファイルを追加するには、以下のコマンドを実行します。

./temporary_swap.sh add

スワップファイルを削除するには、以下を実行します。

./temporary_swap.sh remove

まとめ

一時的なスワップファイルを作成して高負荷作業を安全に乗り切ることができます。
作業が終了したらスワップファイルを削除することで、ディスク容量を無駄にせずに運用できます。
スクリプトを活用することで、日々の作業を効率化できます。

一時的なスワップファイルの運用は、VPSのようにリソースが限られた環境で特に有効です。ぜひお試しください！

VSCodeでリモートサーバーのコードをSSH経由で編集する方法

Wed, 20 Nov 2024 16:36:45 +0900

リモートサーバー上のコードをVSCodeで直接編集したいとき、「Remote - SSH」拡張機能を使えば簡単に設定できます。この記事では、その手順を初心者向けにわかりやすく解説します。

📌 前提条件

VSCodeがインストールされていること。
SSHでリモートサーバーにアクセスできること（公開鍵認証またはパスワード認証）。
インターネット接続があること。

📖 手順

1. 「Remote - SSH」拡張機能をインストール

VSCodeを起動します。
左側の「拡張機能」アイコン（四角が飛び出すマーク）をクリックします。
検索バーに「Remote - SSH」と入力。
Microsoft製の「Remote - SSH」拡張機能をインストールします。

2. SSH設定ファイルの準備

SSH接続には、~/.ssh/configファイルを使用します。この設定ファイルでリモートサーバーへの接続を定義します。

ターミナルを開き、以下のコマンドを実行して設定ファイルを作成または編集します:

nano ~/.ssh/config

以下のように、リモートサーバーの情報を記述します:

Host my-remote-server
 HostName 192.168.1.100 # サーバーのIPまたはホスト名
 User my-username # リモートサーバーのユーザー名
 IdentityFile ~/.ssh/id_rsa # SSH鍵のパス（鍵認証を使用する場合）

ファイルを保存して閉じます。

💡 ヒント: Hostの値（例: my-remote-server）は任意の名前でOK。後で接続時にこの名前を使用します。

3. リモートサーバーに接続

VSCode左下の緑色の「リモートアイコン」をクリック。
「Connect to Host」を選択。
先ほど設定したエイリアス名（例: my-remote-server）を選択。
初回接続時に「このホストのSSHキーを信頼するか」と聞かれるので「Yes」を選択。

リモートサーバーに接続されると、VSCodeのウィンドウが再起動し、リモート環境として動作します。

4. リモートフォルダを開く

接続後、リモートサーバー上の作業ディレクトリを開きます。

左側のエクスプローラーで「Open Folder」をクリック。
リモートサーバー上のディレクトリ（例: /home/my-username/project）を選択。

これで、リモートサーバー上のコードがVSCodeで編集可能になります！

5. リモート環境での開発

リモート環境に必要な拡張機能（例: Python、Node.js関連）をインストールする際は、「Install in SSH: [Host名]」を選択してください。
ターミナルを開くには、Ctrl +（バッククォート） ``を押します。リモートサーバーのターミナルが利用できます。

🛠 トラブルシューティング

Q1. SSH接続エラーが発生する

SSH設定ファイル（~/.ssh/config）の記述を再確認。
ターミナルで以下を実行してSSH接続が可能か確認:

ssh my-remote-server

Q2. 拡張機能がインストールされない

拡張機能画面で「Install in SSH」を選択しているか確認。

Q3. 権限エラーが発生

リモートサーバー上のファイル・フォルダの権限設定を確認します:

chmod -R u+w /path/to/directory

これで、リモートサーバーでの開発作業が快適になるはずです！
VSCodeと「Remote - SSH」を使って、効率的なリモート開発を楽しんでください。

JPGなど画像ファイルを圧縮したCBZ,ZIPファイルをPDFに変換する

Wed, 25 Sep 2024 12:50:58 +0900

電子書籍や漫画のフォーマットとしてよく使われるCBZファイルは、実際にはZIP形式で圧縮されたJPEG画像の集まりです。今回は、このCBZファイルを簡単にPDFに変換する方法を紹介します。

手順は非常にシンプルで、無料のコマンドラインツールを使って効率よく変換できます。ぜひ試してみてください。

必要なツール

以下のツールが必要です。

unzip（通常のZIPファイル解凍に使います）
img2pdf（画像をPDFにまとめるためのツール）

img2pdfはPythonベースのツールで、簡単にインストールできます。まだインストールしていない場合、次のコマンドを使用してインストールしましょう。

pip install img2pdf

手順

CBZファイルを解凍する

まず、.cbzファイルをunzipコマンドで解凍し、中のJPEG画像を取り出します。次のようにコマンドを実行してください。

unzip your_file.cbz -d extracted_images

your_file.cbzは変換したいCBZファイルの名前、extracted_imagesは画像を解凍するディレクトリです。

画像をPDFに変換する

次に、解凍されたJPEG画像を1つのPDFファイルにまとめます。img2pdfコマンドを使って、指定したディレクトリ内のJPEG画像をPDF形式に変換します。

img2pdf extracted_images/*.jpg -o output.pdf

これで、output.pdfという名前のPDFファイルが作成されます。

スクリプト化

次のようなBashスクリプトを作成すれば、.cbzファイルをPDFに変換し、同じファイル名のPDFを出力し、途中で生成された不要なファイルを削除できます。

#!/bin/bash

# CBZファイルを引数として受け取る
if [ -z "$1" ]; then
 echo "Usage: $0 filename.cbz"
 exit 1
fi

# ファイル名とディレクトリを分離
cbz_file="$1"
filename=$(basename "$cbz_file" .cbz)
directory=$(dirname "$cbz_file")

# 一時ディレクトリを作成
temp_dir=$(mktemp -d)

# CBZファイルを解凍
unzip "$cbz_file" -d "$temp_dir"

# 画像ファイルをPDFに変換
img2pdf "$temp_dir"/*.jpg -o "$directory/$filename.pdf"

# 一時ディレクトリを削除
rm -rf "$temp_dir"

echo "Conversion completed: $filename.pdf"

まとめ

以上で、CBZファイルを簡単にPDFに変換できる手順を紹介しました。特別なソフトウェアは必要なく、コマンドラインだけでサクッと変換できるので、ぜひこの方法を活用してください。漫画や電子書籍をPDF化して整理したい方にぴったりの方法です。

一度コミットしたファイルを .gitignore に追加して追跡から外す手順

Sat, 21 Sep 2024 10:05:06 +0900

プロジェクトの開発中に、一時的なファイルやビルドアーティファクトを誤って Git にコミットしてしまうことがあります。通常、これらのファイルは .gitignore に追加してリポジトリに含めないようにするのが一般的ですが、既にコミットされている場合、追跡から外す必要があります。

手順

`.gitignore` にファイルやフォルダを追加する

まず、追跡したくないファイルやフォルダを .gitignore に追加します。たとえば、ビルドアーティファクトや一時ファイルを無視する場合は、以下のように記述します。

# 追跡しないファイルやフォルダを指定
build/
temp/
.env

.gitignore に追加することで、今後これらのファイルやフォルダは新たに Git の追跡対象から外されますが、既にコミットされたものは追跡されたままです。

既に追跡されているファイルやフォルダをインデックスから削除

既にコミットされているファイルやフォルダを Git の追跡から外すには、以下のコマンドを実行してインデックスから削除します。

git rm -r --cached <ファイル名またはフォルダ名>

<ファイル名またはフォルダ名> の部分には、追跡から外したいファイルやフォルダのパスを指定します。--cached オプションを付けることで、ローカルのファイルは削除されず、Git の追跡からのみ外れます。

例として、ビルドディレクトリ build/ を追跡から外す場合は次のようにします。

git rm -r --cached build/

変更をコミット

インデックスから削除したファイルやフォルダの変更をコミットします。

git commit -m "Remove build directory from tracking"

これで、指定したファイルやフォルダは Git で追跡されなくなります。

リモートにプッシュ

最後に、変更をリモートリポジトリにプッシュします。

git push origin <your-branch>

<your-branch> の部分には作業中のブランチ名を指定します。

まとめ

誤ってコミットしてしまった一時ファイルやビルドアーティファクトを Git の追跡から外す際は、次の手順を覚えておくと便利です。

.gitignore に無視するファイルやフォルダを追加
git rm --cached コマンドでインデックスから削除
変更をコミットしてリモートにプッシュ

ファイル名に数字の部分があったら、桁数を引数で指定してゼロ埋めするbashスクリプト

Mon, 12 Aug 2024 16:08:18 +0900

この記事では、ファイル名に含まれる数字部分を指定した桁数でゼロ埋めするBashスクリプトを紹介し、その技術的な詳細を解説します。このスクリプトは、数字部分を柔軟に処理し、デフォルトで4桁、引数を指定することで任意の桁数でゼロ埋めすることができます。MacやLinux環境で動作し、ファイル名の管理や整理を効率的に行えます。

スクリプトの概要

このスクリプトは、ディレクトリ内のすべてのファイルを対象にして、ファイル名に含まれる数字部分を指定された桁数でゼロ埋めします。ゼロ埋めの桁数は、スクリプトの引数として指定することができ、引数が指定されない場合はデフォルトで4桁になります。

スクリプト全文

#!/bin/bash

# ゼロ埋めする桁数を引数から取得、デフォルトは4桁
pad_length=${1:-4}

# ディレクトリ内のすべてのファイルを処理する
for file in *; do
 # ファイル名を変数に格納
 original_name="$file"
 modified_name=""
 number=""

 # ファイル名の各部分をチェック
 while IFS= read -r -n1 char; do
 if [[ "$char" =~ [0-9] ]]; then
 number="$number$char"
 else
 if [[ -n "$number" ]]; then
 # 8進数の解釈を避けるため、整数として扱う
 number=$((10#$number))
 if [[ ${#number} -le $pad_length ]]; then
 modified_name="${modified_name}$(printf "%0${pad_length}d" "$number")"
 else
 modified_name="${modified_name}$number"
 fi
 number=""
 fi
 modified_name="$modified_name$char"
 fi
 done <<< "$original_name"

 # 末尾に数字があった場合、それをゼロ埋めする
 if [[ -n "$number" ]]; then
 number=$((10#$number))
 if [[ ${#number} -le $pad_length ]]; then
 modified_name="${modified_name}$(printf "%0${pad_length}d" "$number")"
 else
 modified_name="${modified_name}$number"
 fi
 fi

 # 名前が変更されていればファイル名を変更
 if [ "$original_name" != "$modified_name" ]; then
 mv "$original_name" "$modified_name"
 echo "Renamed: $original_name -> $modified_name"
 fi
done

技術的な解説

引数による桁数の指定

pad_length=${1:-4}

この部分は、スクリプトに渡された引数を pad_length という変数に代入しています。引数が指定されなかった場合には、デフォルトで4桁が使用されます。これにより、ユーザーは必要に応じて任意の桁数でゼロ埋めが可能です。

ファイル名の処理

スクリプトは、for file in *; do ループを使って、現在のディレクトリ内にあるすべてのファイルを順番に処理します。ファイル名の各文字を1文字ずつチェックし、数字部分を検出してゼロ埋めを行います。

8進数の解釈を回避

number=$((10#$number))

printf コマンドは、数字の先頭にゼロがついていると、それを8進数として解釈しようとします。このため、先頭のゼロを取り除いてから処理を行う必要があります。この行で number 変数を整数に変換し、8進数の誤解釈を回避しています。

`printf` を使ったゼロ埋め

modified_name="${modified_name}$(printf "%0${pad_length}d" "$number")"

この部分で、printf コマンドを使用して、指定された桁数で数字をゼロ埋めしています。${pad_length} によってゼロ埋めする桁数が動的に決定されます。

ファイル名の変更

mv "$original_name" "$modified_name"

最後に、元のファイル名とゼロ埋めされた新しいファイル名を比較し、異なる場合はmvコマンドを使用してファイル名を変更します。これにより、ファイルが適切にリネームされ、処理が完了します。

使用例

このスクリプトを利用する際の基本的な実行例を以下に示します。

デフォルトで4桁ゼロ埋めを行う場合：

./rename_files.sh

6桁でゼロ埋めを行いたい場合：

./rename_files.sh 6

このようにして、任意の桁数で数字部分をゼロ埋めすることができます。ファイル名に含まれる複数の数字部分にも対応しており、ファイル管理の際に役立つツールとなるでしょう。

まとめ

このスクリプトは、Bashでのファイル名処理を強力かつ柔軟に行うための便利なツールです。MacやLinuxの環境でスムーズに動作し、シンプルなコマンドでファイル名の数字部分を整形することができます。ぜひ、ご自身のプロジェクトで活用してみてください。

ディレクトリベースで複数のGitHubアカウントを管理する方法

Thu, 04 Jul 2024 18:56:23 +0900

この記事では、個人用と仕事用のGitHubアカウントを、プロジェクトディレクトリごとに自動的に切り替えて使用する方法を詳しく解説します。具体的には、~/projects/personal ディレクトリ下のプロジェクトでは個人のGitHubアカウントを使用し、~/projects/work ディレクトリ下では仕事用のアカウントを使用する状況を想定します。コマンドラインでのGit操作だけでなく、VSCodeなどのIDEでも適用されるようにします。

前提条件

Gitの基本的な知識があること。
アカウントごとにSSHキーを生成しており、それぞれのGitHubアカウントに登録していること。
基本的なGit操作に慣れていること。
Git 2.13以降であること。

Git設定の基本

.gitconfigファイルはGitの設定を管理するための中心的なファイルで、ユーザ名やメールアドレス、エイリアス、スクリプトの実行設定などを含みます。全体的なユーザー設定（グローバル設定）は通常、ユーザのホームディレクトリに位置する.gitconfigファイルに記述されます。

ディレクトリごとのGit設定

Git 2.13以上では、includeIfディレクティブを使用して、特定のディレクトリに基づいてGit設定を動的に適用することができます。これを利用して、異なるプロジェクトディレクトリで異なるGitHubアカウントを使い分ける設定を行います。

基本的な`.gitconfig`設定

ホームディレクトリの.gitconfigに以下の設定を追加します。

[user]
 name = default_name
 email = default_email@example.com

[includeIf "gitdir:~/projects/personal/"]
 path = ~/.gitconfig-personal
[includeIf "gitdir:~/projects/work/"]
 path = ~/.gitconfig-work

各ディレクトリ用の`.gitconfig`ファイル

~/.gitconfig-personalファイルには次のように記述します：

[user]
 name = personal_username
 email = personal_email@example.com
[core]
 sshCommand = "ssh -i ~/.ssh/id_rsa_personal -F /dev/null"

~/.gitconfig-workファイルには次のように記述します：

[user]
 name = work_username
 email = work_email@example.com
[core]
 sshCommand = "ssh -i ~/.ssh/id_rsa_work -F /dev/null"

まとめ

ディレクトリベースでGitHubアカウントを管理することで、複数のアカウントを効率的かつ安全に運用することが可能です。設定は初めに少し時間がかかりますが、一度設定してしまえば、その後は自動で適切なアカウントが使用されるため、非常に便利です。

カレントディレクトリ以下のすべてのpng,jpgをwebpに変換するシェルスクリプト

Mon, 25 Mar 2024 16:23:39 +0900

この記事の目的は、シェルスクリプトでカレントディレクトリ以下にあるjpgやpngといった画像ファイルを、すべてwebpに変換することです。サブディレクトリ内のデータも含みます。また、高速化のために並列処理をします。

実行環境

Machine: M2 Pro Mac mini (2023)
macOS Sonoma 14.3.1
GNU bash 5.2.26
ImageMagick 7.1.1-29

スクリプトの提示

以下に、この自動化された並列処理を実行するためのbashスクリプトを示します。このスクリプトは、指定したディレクトリ以下の画像ファイル（PNG、JPG、JPEG）を検索し、それらをwebpフォーマットに変換後、元のファイルを削除します。変換プロセスは並列で実行されるため、作業の完了にかかる時間が大幅に短縮されます。

#!/bin/bash

convert_image() {
 img="$1"
 name=$(basename "$img" .${img##*.})
 dir=$(dirname "$img")
 new_path="$dir/$name.webp"
 convert "$img" "$new_path" && rm "$img"
}

export -f convert_image

find . -type f \( -iname \*.png -o -iname \*.jpg -o -iname \*.jpeg \) -print0 | parallel -0 convert_image

このスクリプトは、すべてのPNG、JPG、およびJPEGファイルを現在のディレクトリおよびそのサブディレクトリから検索し、それぞれをwebpフォーマットに変換した後、元のファイルを削除します。この自動化されたプロセスにより、手動で行う場合と比べて大幅な時間短縮が可能になります。

スクリプトの実行方法

このセクションでは、前述のbashスクリプトを実行するために必要な環境設定と、スクリプトの具体的な使用方法について詳しく説明します。スクリプトを効果的に活用するには、いくつかの前提条件を満たし、適切な手順で実行することが重要です。

前提条件は以下です。

ImageMagickのインストール: このスクリプトはconvertコマンドを使用して画像をwebpフォーマットに変換します。convertコマンドは、ImageMagickソフトウェアスイートの一部です。ImageMagickは多くのLinuxディストリビューション、macOS、およびWindowsで利用可能です。お使いのシステムにImageMagickがインストールされていない場合は、公式のImageMagickダウンロードページからインストールすることができます。
GNU parallelのインストール: このスクリプトはGNU parallelを使用して、画像変換プロセスを並列で実行します。これにより、複数の画像を同時に処理することができ、全体の処理時間が大幅に短縮されます。GNU parallelはLinuxディストリビューションのパッケージマネージャーやGNU parallelの公式ページを通じてインストールできます。

スクリプトの主要部分解説

このセクションでは、先に紹介したbashスクリプトの構成要素を詳しく説明し、各部分がどのように機能するかを解説します。スクリプトは大きく分けて三つの主要な処理ステップによって構成されています。画像ファイルの検索、画像の並列変換、および元の画像ファイルの削除です。

1. 画像ファイルの検索

スクリプトはfindコマンドを使用して、指定したディレクトリ以下のすべてのPNG、JPG、JPEGファイルを検索します。この検索は再帰的に行われ、サブディレクトリ内のファイルも対象となります。

find . -type f \( -iname \*.png -o -iname \*.jpg -o -iname \*.jpeg \) -print0

.は現在のディレクトリを表します。
-type fはファイルタイプが「ファイル」であるものを検索対象とします。
-inameは大文字小文字を区別せずに名前が一致するファイルを検索します。ここでは、.png、.jpg、.jpegの各拡張子を持つファイルを対象としています。
-print0は検索結果をNULL文字で区切って出力します。これはparallelコマンドでの処理に必要です。

2. 画像の並列変換

検索した画像ファイルはparallelコマンドを通じて並列に処理されます。このステップでは、各画像ファイルがwebpフォーマットに変換されます。

parallel -0 convert_image

-0オプションは、入力がNULL文字で区切られていることをparallelに指示します。
convert_imageは画像を変換するために定義された関数です。

GNU parallelは、複数のプロセスを並列で実行するための強力なツールです。このスクリプトでは、parallelコマンドを用いて、検索された各画像ファイルに対してconvert_image関数を同時に実行させています。これにより、画像の変換タスクがCPUの複数のコアに分散され、タスクの完了速度が向上します。

3. 画像変換関数 `convert_image`

この関数は、個々の画像ファイルをwebpフォーマットに変換し、成功したら元のファイルを削除します。

convert_image() {
 img="$1"
 name=$(basename "$img" .${img##*.})
 dir=$(dirname "$img")
 new_path="$dir/$name.webp"
 convert "$img" "$new_path" && rm "$img"
}

img="$1"は関数に渡された最初の引数（ここでは画像ファイルのパス）を変数imgに代入します。
basenameとdirnameコマンドを使用して、ファイル名（拡張子なし）とディレクトリのパスを取得します。
convertコマンドは画像をwebpフォーマットに変換します。変換が成功した場合（&&の後）、rmコマンドによって元のファイルが削除されます。

このスクリプトによって、大量の画像ファイルを効率的にwebpフォーマットに変換するプロセスが自動化されます。並列処理の採用により、この変換作業を大幅に高速化することができます。

トラブルシューティング

実際にスクリプトを使用する際には、いくつかの一般的な問題に遭遇する可能性があります。このセクションでは、最も一般的な問題とその解決策をいくつか紹介します。

1. GNU parallelが見つからない

問題: スクリプトを実行しようとすると、「parallel: command not found」というエラーメッセージが表示されます。

解決策:

GNU parallelがインストールされているかどうかを確認してください。インストールされていない場合は、お使いのシステムのパッケージマネージャーを使用してインストールします。例えば、Ubuntuではsudo apt-get install parallelを実行します。

2. ImageMagickのconvertコマンドが機能しない

問題: convertコマンドを実行しようとするとエラーが発生するか、期待される出力が得られない。

解決策:

ImageMagickが正しくインストールされているかを確認してください。インストールされていない、またはバージョンが古い場合は、最新版を公式ウェブサイトからダウンロードしてインストールします。
特にMac OSの場合、ImageMagickの最新バージョンではconvertコマンドがmagick convertに置き換えられている可能性があります。その場合は、スクリプト内のconvertコマンドをmagick convertに変更してください。

3. スクリプトが特定の画像ファイルを見つけられない

問題: スクリプトを実行しても、一部の画像ファイルが処理されない。

解決策:

findコマンドのパターンが正しいか確認してください。大文字小文字の違いが原因でファイルが見落とされることがあります。-inameオプションは大文字小文字を区別しないため、これを使用していることを確認してください。
スクリプトが実行されているディレクトリと、処理したい画像ファイルが格納されているディレクトリが一致しているかを確認してください。必要に応じて、findコマンドの検索パスを調整します。

参考資料

この記事では、大量の画像ファイルを効率的にwebp形式に変換し、そのプロセスを並列で実行するbashスクリプトの作成と使用について詳しく説明しました。このスクリプトを使用することで、画像処理タスクの時間を大幅に短縮し、ウェブサイトのパフォーマンスを向上させることができます。また、GNU parallelとImageMagickを活用することで、マルチコアプロセッサの能力を最大限に引き出し、作業の効率を向上させる方法も紹介しました。

カレントディレクトリの.rarファイルを展開する(Bash, Fish)

Wed, 03 Jan 2024 09:21:21 +0900

.rar ファイルを Bash や Fish シェルで展開するためには、unrar または rar コマンドを使用します。これらのコマンドは .rar 形式のファイルを処理するための標準的なツールです。まず、これらのコマンドがシステムにインストールされているか確認し、インストールされていなければ適切な手順でインストールしてください。

Bash での .rar ファイルの展開

Bash シェルを使用して .rar ファイルを展開するには、以下のコマンドを実行します：

for file in *.rar; do unrar x "$file"; done

このコマンドは、カレントディレクトリに存在する全ての .rar ファイルを検索し、unrar x コマンドを使ってそれぞれを展開します。

Fish での .rar ファイルの展開

Fish シェルで .rar ファイルを展開する場合、コマンドは少し異なりますが、基本的なプロセスは同じです。以下が Fish でのコマンドです：

for file in *.rar; unrar x $file; end

このコマンドも、カレントディレクトリの全ての .rar ファイルに対して unrar コマンドを実行します。

注意点

unrar コマンドがシステムにインストールされている必要があります。Linux や Unix 系の OS では、パッケージマネージャを通じてインストールできます。例えば、Debian 系のディストリビューションでは sudo apt-get install unrar コマンドでインストールできます。
Macの場合は MacでRARファイルをコマンドラインで解凍する(unrar) #Mac - Qiita より $ brew install carlocab/personal/unrarでインストールできます。
展開したいファイルが保存されているディレクトリに移動してからコマンドを実行してください。
ファイル名にスペースや特殊文字が含まれている場合は、ファイル名をダブルクォートで囲むことで、正しく処理されるようにしてください。

カレントディレクトリの.lzhファイルをBashとFishで展開する方法

Wed, 03 Jan 2024 09:01:58 +0900

コンピュータを使った作業では、様々なファイルを扱いますが、特にアーカイブファイルはその中でも重要な役割を果たしています。アーカイブファイルには多くの種類がありますが、今回は.lzh形式のファイルに注目します。.lzhはかつて日本で広く使われていた圧縮形式で、今でも歴史的なデータや特定のコンテンツを扱う際に見かけることがあります。

このブログ記事では、.lzhファイルを効率的に展開する方法を、BashとFishという二つの異なるシェルを使って紹介します。BashはLinuxやUnix系のオペレーティングシステムで最も一般的に使われるシェルで、その強力なスクリプト機能は多くのユーザーに愛されています。一方で、Fishはより最近のシェルで、そのユーザーフレンドリーな設計と直感的な構文が特徴です。

Bashでの.lzhファイルの展開

Bashシェルは、LinuxやUnix系のオペレーティングシステムで広く採用されているコマンドラインインターフェースです。その強力なスクリプティング機能と柔軟性により、多くの開発者やシステム管理者にとって欠かせないツールとなっています。ここでは、Bashを使用して.lzhファイルを効率的に展開する方法を紹介します。

まず、.lzhファイルの展開にはlhaコマンドが必要です。このコマンドは多くのLinuxディストリビューションやUnix系OSで利用可能ですが、インストールされていない場合は、パッケージマネージャを通じてインストールする必要があります。例えば、Debian系のLinuxディストリビューションでは、次のコマンドでlhaをインストールできます：

sudo apt-get install lha

インストールが完了したら、カレントディレクトリにあるすべての.lzhファイルを展開するためのコマンドを実行します。以下がそのコマンドです：

for file in *.lzh; do lha x "$file"; done

このコマンドは、カレントディレクトリに存在するすべての.lzhファイルに対して、ループを用いて一つずつlha xコマンドを実行します。forループの中で、*.lzhはカレントディレクトリ内の全ての.lzhファイルにマッチします。各ファイル名はfile変数に格納され、lha x "$file"コマンドによってそれぞれのファイルが展開されます。ダブルクォーテーションは、ファイル名にスペースや特殊文字が含まれている場合に備えて、ファイル名を正しく処理するために使用します。

Fishでの.lzhファイルの展開

Fishシェルは、使いやすさと直感的な機能を重視した近代的なコマンドラインシェルです。Bashと比較して、より洗練されたユーザーインターフェースとシンプルな構文を提供しています。ここでは、Fishを使用して.lzhファイルを効率的に展開する方法を紹介します。

Bashと同様に、Fishでの展開にもlhaコマンドが必要です。lhaがまだインストールされていない場合は、システムのパッケージマネージャを使ってインストールしてください。インストールが完了したら、以下のコマンドを実行して、カレントディレクトリにある全ての.lzhファイルを展開します：

for file in *.lzh; lha x $file; end

このコマンドは、カレントディレクトリ内の全ての.lzhファイルに対してlhaコマンドを使用します。forループは、指定されたパターンにマッチする各ファイルに対してコマンドを実行します。ここでの*.lzhは、カレントディレクトリの全ての.lzhファイルを指します。lha x $fileコマンドはそれぞれのファイルを展開し、endキーワードでループが終了します。

Fishシェルの特徴の一つは、その構文の簡潔さです。Bashに比べてコマンドが短く、読みやすいため、シェルスクリプティングの初心者にも理解しやすいかもしれません。また、Fishには、コマンドの自動補完やシンタックスハイライトなどの便利な機能が標準で備わっており、日々の作業をより効率的にします。

注意点

.lzh ファイルを Bash や Fish で展開する際には、いくつかの重要な注意点があります。これらを理解し、適切に対処することで、ファイルの展開をスムーズかつ安全に行うことができます。

`lha` コマンドのインストールと確認

最初に、.lzh ファイルを扱うためには lha コマンドが必須です。このコマンドはすべてのシステムに標準でインストールされているわけではありません。自分のシステムに lha がインストールされているかを確認し、なければ適切なパッケージマネージャ（例えば、Linux の場合は apt や yum）を使用してインストールしてください。

ディレクトリの確認

コマンドを実行する前に、カレントディレクトリが正しいかを確認することが大切です。pwd コマンドを使用して現在のディレクトリを確認し、必要に応じて cd コマンドで移動してください。これは、意図しないディレクトリのファイルを誤って操作することを防ぐためです。

ファイルのバックアップ

特に大切なデータを扱う場合、コマンドを実行する前にファイルのバックアップを取ることを強くお勧めします。これにより、万が一の事態が発生した場合でもデータを保護することができます。

ファイル名の特殊文字

ファイル名にスペースや特殊文字が含まれている場合、これらを適切に処理するためにはファイル名をダブルクォートで囲むことが重要です。これは、シェルがファイル名を正しく解釈するために必要です。

これらの注意点を頭に入れておくことで、.lzh ファイルの展開を安全かつ効率的に行うことができます。次のセクションでは、今回学んだ内容をまとめ、日常的なタスクの自動化の観点からこれらのコマンドの利用価値を評価します。

まとめ

この記事では、BashおよびFishシェルを用いてカレントディレクトリにある全ての.lzhファイルを効率的に展開する方法について学びました。Bashはその強力なスクリプティング能力で広く利用されており、Fishはユーザーフレンドリーな構文と使い勝手の良さで注目されています。どちらのシェルも、.lzhファイルのような特定のファイルタイプを扱う際に、効率的で強力なツールです。

BashとFishの比較

Bash: 従来からのLinuxユーザーにとって馴染み深い。スクリプティングにおける複雑なタスクを処理するのに適しており、広範囲にわたる機能を提供します。
Fish: シンプルで直感的な構文を持つ新しいシェル。自動補完やシンタックスハイライトなどの便利な機能が標準で備わっており、シェルスクリプティング初心者にも扱いやすいです。

自動化と効率化

このようなシェルコマンドを使うことで、日常的に発生する繰り返しのタスクを自動化し、作業効率を大幅に向上させることが可能です。特に多くのアーカイブファイルを扱う場合、これらのコマンドを使うことで、手作業による時間の浪費を避け、より重要なタスクに集中することができます。

結論

BashとFishを使った.lzhファイルの展開方法は、日々の作業をスムーズに進めるための有効な手段です。シェルスクリプティングは、単なるコマンドライン操作以上の可能性を秘めており、これを習得することは、あらゆるIT専門家にとって価値のあるスキルです。

この記事が、BashとFishの使い方を理解し、より効率的なワークフローを構築する一助となれば幸いです。

direnvを活用したAWSアカウントの自動切り替え方法

Sun, 10 Dec 2023 00:39:39 +0900

クラウドリソースを頻繁に使用する場合、異なるプロジェクトやクライアントごとに異なるAWSアカウントを切り替える必要があることは珍しくありません。この記事では、開発環境におけるAWSアカウントの自動切り替えを実現するためにdirenvというツールの使用方法に焦点を当てます。

direnvは、シェル環境においてディレクトリごとに環境変数を自動で切り替えることができる非常に便利なツールです。これにより、プロジェクトや作業環境に応じて、AWSプロファイルや他の環境設定を簡単に切り替えることが可能になります。この記事では、direnvの基本的なインストール方法から、AWSアカウントの切り替え設定までをステップバイステップで説明していきます。

direnvのインストールと設定

開発環境のカスタマイズにおいて、direnvは非常に重要なツールの一つです。direnvを使用すると、異なるディレクトリに移動した際に自動的に環境変数を切り替えることができ、特に複数のAWSアカウントを使い分ける際に大いに役立ちます。ここでは、direnvのインストールと基本的な設定方法について説明します。

direnvのインストール

direnvは多くのUnix系オペレーティングシステムで利用可能です。以下は、主要なOSにおけるdirenvのインストール方法です：

macOS: Homebrewを使用して簡単にインストールできます。

brew install direnv

Ubuntu/Debian: aptパッケージマネージャを利用します。

sudo apt-get install direnv

Fedora: dnfを使用してインストールします。

sudo dnf install direnv

シェルにdirenvをフックする

インストール後、direnvを使用するためにはシェルにフックする必要があります。これは、使用しているシェルの設定ファイルに特定の行を追加することで行います。以下は、いくつかの一般的なシェルの設定方法です：

Bash (.bashrc or .bash_profile) :

eval "$(direnv hook bash)"

Zsh (.zshrc) :

eval "$(direnv hook zsh)"

Fish (.config/fish/config.fish) :

eval (direnv hook fish)

これらの設定を適用した後、シェルを再起動するか、新しいターミナルウィンドウを開いて設定を有効にします。

基本的な使用法

direnvを使うための最初のステップは、環境変数や設定を含む.envrcファイルを作成することです。このファイルは、特定のディレクトリに配置され、direnvによって自動的に読み込まれます。.envrcファイルには、AWSプロファイルの設定や他の必要な環境変数を指定できます。

セキュリティ上の理由から、新しい.envrcファイルはdirenvによってデフォルトで無視されます。ファイルを承認するためには、次のコマンドを使用します：

direnv allow .

このコマンドは、.envrcファイルが安全であることをdirenvに伝え、そのディレクトリでの変更を有効にします。

direnvを使用したAWSアカウントの実践例とトラブルシューティング

direnvを活用することで、AWSアカウントの切り替えをスムーズに行うことができます。このセクションでは、実際の使用例と一般的な問題の解決方法について説明します。

実際の使用例

想定するシナリオは、異なるAWSアカウントを使用する複数のプロジェクトに取り組んでいる状況です。それぞれのプロジェクトディレクトリに.envrcファイルを作成し、適切なAWSプロファイル名を設定します。

例えば、プロジェクトAとプロジェクトBがあり、それぞれ異なるAWSアカウントを使用するとします。プロジェクトAのディレクトリの.envrcには以下のように書きます：

export AWS_PROFILE=projectA-profile

同様に、プロジェクトBの.envrcには：

export AWS_PROFILE=projectB-profile

これにより、各プロジェクトディレクトリに移動するだけで、direnvが自動的にAWSプロファイルを適切なものに切り替えます。

トラブルシューティングのヒント

問題：.envrcが読み込まれない
解決策：direnv allowコマンドを使用して、.envrcファイルを承認します。また、シェルの設定ファイル（例：.bashrc、.zshrc、.config/fish/config.fish）でdirenvが正しくフックされていることを確認してください。
問題：AWSプロファイルが切り替わらない
解決策：AWS_PROFILE変数が正しく設定されているか確認します。また、AWS CLIがインストールされていること、および~/.aws/credentialsと~/.aws/configに正しい認証情報が設定されていることを確認してください。
問題：セキュリティ上の懸念
解決策：.envrcファイルに機密情報（例：アクセスキー、シークレットキー）を直接書かないようにします。代わりに、プロファイル名のみを使用し、認証情報は~/.aws/credentialsに安全に保存します。

まとめ

direnvを使用したAWSプロファイルの自動切り替えの方法について詳しく説明しました。この手法は、複数のAWSアカウントを扱う際の生産性を高め、エラーの可能性を減らすのに役立ちます。

主なポイントの再確認:
direnvをインストールし、シェルにフックする。
.envrcファイルを使用して、ディレクトリごとに異なるAWSプロファイルを設定する。
direnv allowを実行して、新しい.envrcファイルを承認する。
応用例: この手法はAWSプロファイルに限らず、他の環境変数や設定（例えば、データベース接続設定やAPIキー）の管理にも応用できます。
セキュリティ上の注意: .envrcファイルに機密情報を直接記述することは避け、安全な方法で認証情報を管理することが重要です。

参考記事

direnv公式ドキュメント: direnv公式ウェブサイトには、インストール方法、使用方法、さまざまな設定オプションに関する詳細情報があります。
AWS CLI公式ドキュメント: AWS CLIの使用方法に関する詳細情報は、AWS公式ドキュメントで提供されています。
関連ブログ記事やフォーラム: コミュニティの経験やベストプラクティスを共有する多くのブログ記事やフォーラムが存在します。これらは、具体的なシナリオや高度な使用例を理解するのに役立つかもしれません。

Macで自動化する：launchdを使ってスクリプトを起動時に実行する方法

Sun, 26 Nov 2023 21:30:13 +0900

導入

Mac OSでは、launchdという強力なシステムが組み込まれています。これは、さまざまなタスクを自動化するためのツールで、特にシステムの起動時や特定の条件下でプログラムやスクリプトを自動的に実行するのに適しています。launchdはMacのバックグラウンドで動作し、ユーザーが意識することなく様々なプロセスを管理します。

この記事では、launchdを使用して、Macが起動するたびに特定のスクリプトを自動的に実行する方法について詳しく説明します。

定期実行はこちら

あわせて読みたい

macOSのlaunchdでスクリプトを定期実行するplistのメモ

/macos-launchd-schedule/

スクリプトの準備

自動化の旅を始める前に、まずは実行したいスクリプトを用意する必要があります。このステップでは、単純なシェルスクリプトを作成し、それをMacの起動時に実行する方法に焦点を当てます。シェルスクリプトは、簡単で理解しやすいので、自動化の基本を学ぶのに最適です。

以下は、非常に基本的なシェルスクリプトの例です。このスクリプトは、「Hello, World!」というメッセージをログファイルに書き込みます。

#!/bin/bash
echo "Hello, World!" > /path/to/your/logfile.log

このスクリプトをテキストエディタで作成し、「myscript.sh」という名前で保存します。保存場所は、例えばホームディレクトリ内のScriptsフォルダなど、容易にアクセスできる場所が適しています。

作成したスクリプトは、実行可能でなければなりません。これを行うには、ターミナルで次のコマンドを使用します。

chmod +x ~/Scripts/myscript.sh

このコマンドにより、myscript.shに実行権限が付与されます。これでスクリプトはlaunchdによって起動時に実行される準備が整いました。

.plistファイルの作成と設定

launchdを使用する際の重要な要素が.plist（プロパティリスト）ファイルです。このXML形式のファイルは、launchdに対して、どのスクリプトをいつ実行するか、そしてどのように実行するかを指示します。正しく設定された.plistファイルは、スクリプトを自動的に、そして安全に実行するための鍵となります。

ここでは、先に作成したmyscript.shを起動時に実行するための.plistファイルの例を示します。以下のコードをテキストエディタで作成し、適切な名前（例：com.yourusername.myscript.plist）で保存します。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>com.yourusername.myscript</string>
 <key>ProgramArguments</key>
 <array>
 <string>/Users/yourusername/Scripts/myscript.sh</string>
 </array>
 <key>RunAtLoad</key>
 <true/>
</dict>
</plist>

このファイルでは、Labelはユニークな識別子を提供し、ProgramArgumentsは実行するスクリプトのパスを指定します。RunAtLoadがtrueに設定されていると、Macが起動するたびにスクリプトが実行されます。

作成した.plistファイルを~/Library/LaunchAgents/ディレクトリに保存します。この場所にファイルを置くことで、ユーザーがログインした際に自動的にlaunchdによって読み込まれ、スクリプトが実行されるようになります。

.plistファイルの作成と設定（引数を含むスクリプトの場合）

スクリプトが引数を必要とする場合、それらの引数を.plistファイルに正しく組み込むことが重要です。例として、引数を受け取りログファイルに出力するシンプルなスクリプトを考えてみましょう。

#!/bin/bash
echo "Passed argument: $1" > /path/to/your/logfile.log

このスクリプトは引数$1を取り、それをログファイルに出力します。

引数を含むスクリプトを自動実行するための.plistファイルは、以下のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>com.yourusername.myscriptwithargs</string>
 <key>ProgramArguments</key>
 <array>
 <string>/Users/yourusername/Scripts/myscript.sh</string>
 <string>Argument1</string>
 </array>
 <key>RunAtLoad</key>
 <true/>
</dict>
</plist>

この例では、ProgramArgumentsキーの配列に、スクリプトのパスと引数Argument1が含まれています。この設定により、スクリプトは指定した引数を持って起動時に実行されます。

引数が正しくスクリプトに渡されることを確認するため、事前に手動でスクリプトをテストしてください。
引数の値が変わる場合は、その都度.plistファイルを更新し、再度launchctlを使って登録する必要があります。

このセクションでは、引数を含むスクリプトの自動実行に必要な.plistファイルの作成方法を示しました。次のセクションでは、これらの.plistファイルを実際にlaunchdに登録し、自動実行を設定する手順について詳しく解説します。

`launchd`にスクリプトを登録する

.plistファイルを作成し、適切なディレクトリに配置した後、次のステップは、このファイルをlaunchdに登録することです。これにはlaunchctlコマンドが使用されます。以下のコマンドは、新しく作成した.plistファイルをlaunchdに登録する例です。

launchctl load ~/Library/LaunchAgents/com.yourusername.myscript.plist

このコマンドは、~/Library/LaunchAgents/にあるcom.yourusername.myscript.plistという.plistファイルをlaunchdに登録します。これにより、指定された条件（この場合はMacの起動時）にスクリプトが自動的に実行されます。

登録が正常に完了したかを確認するには、以下のコマンドを実行します。

launchctl list | grep com.yourusername.myscript

このコマンドは、登録されたジョブのリストから、指定した識別子com.yourusername.myscriptを検索します。出力結果にこの識別子が表示されれば、登録が成功していることを意味します。

何らかの理由で.plistファイルの登録を解除したい場合は、以下のコマンドを使用します。

launchctl unload ~/Library/LaunchAgents/com.yourusername.myscript.plist

このコマンドは、com.yourusername.myscript.plistファイルの登録を解除し、以降のMacの起動時にはスクリプトが実行されなくなります。

以下は注意点です。

launchctl loadコマンドは、Macが起動するたびに自動的にスクリプトを実行するように設定します。
登録を解除する際は、同じ.plistファイルを指定する必要があります。

まとめ

この記事では、Macのlaunchdシステムを利用して、特定のスクリプトを起動時に自動的に実行する方法について詳しく説明しました。スクリプトの準備から、.plistファイルの作成、そしてlaunchdによる登録までの全ステップをカバーしました。また、引数を含むスクリプトの扱い方についても触れました。

pre-commitでGitのコミットメッセージのプレフィックスをチェックする

Wed, 15 Nov 2023 17:11:39 +0900

はじめに

現代のソフトウェア開発では、コードの品質を維持することが非常に重要です。そのためには、バージョン管理システムであるGitを効果的に活用し、特にコミットプロセスを最適化する必要があります。このブログ記事では、pre-commitを使用してコミットメッセージにプレフィックスを確認する方法について解説します。

pre-commitは、Gitのコミット前に自動的に実行されるフックを設定するためのツールです。これにより、コードのスタイルチェック、テストの実行、その他の重要な検証が可能となります。特に、コミットメッセージに適切なプレフィックス（例えばfeat、fix、docsなど）が含まれているかどうかを自動的に確認することは、プロジェクトの整理と追跡を容易にし、チームメンバー間のコミュニケーションを明確にします。

この記事では、pre-commitの基本的なセットアップからカスタムスクリプトの作成、そして実際の統合に至るまでのプロセスを段階的に説明します。

コミットメッセージのプレフィックスの重要性

コミットメッセージの役割

コミットメッセージは、ソフトウェア開発におけるコミュニケーションの基本的な要素です。これらのメッセージは、変更内容を要約し、他の開発者や将来の自分自身がコードの変更点を理解しやすくするために使われます。良いコミットメッセージは、プロジェクトの履歴を追跡しやすくし、特定の変更を見つけ出す際の手がかりとなります。

プレフィックスの役割

コミットメッセージにプレフィックスを含めることは、変更の種類を明確にし、プロジェクトの管理を効率化します。例えば、featは新機能を、fixはバグ修正を、docsはドキュメントの更新を示します。これらのプレフィックスは、コードレビューや履歴の追跡を行う際に、どのような種類の変更が含まれているかを瞬時に理解するのに役立ちます。

一般的なプレフィックス

プロジェクトによって異なることはありますが、一般的には以下のようなプレフィックスが使われます：

feat: 新機能の追加
fix: バグの修正
docs: ドキュメントの変更
style: コードのフォーマットやスタイルの変更
refactor: コードのリファクタリング
test: テスト関連の変更

これらのプレフィックスを使うことで、コミットメッセージがより情報豊かで、プロジェクトの管理がより容易になります。次のセクションでは、pre-commitをセットアップし、これらのプレフィックスを自動的にチェックする方法について詳しく説明します。

`pre-commit`のセットアップ

`pre-commit`のインストール

pre-commitは、開発プロセスを自動化し、コード品質を維持するための強力なツールです。まずは、pre-commitをインストールする必要があります。Pythonがシステムにインストールされている場合、以下のコマンドでpre-commitをインストールできます：

pip install pre-commit

このコマンドは、pre-commitをグローバルにインストールし、任意のGitリポジトリで使用できるようにします。

`.pre-commit-config.yaml`ファイルの設定

pre-commitを使用するには、リポジトリのルートに.pre-commit-config.yamlファイルを作成し、必要な設定を記述する必要があります。このファイルはpre-commitフックの動作を定義し、どのフックをいつ実行するかを指定します。

ここでは、例として、基本的なpre-commit設定を以下に示します：

repos:
-  repo: https://github.com/pre-commit/pre-commit-hooks
 rev: v3.4.0  # フックのバージョンを指定
 hooks:
 -  id: check-yaml
 -  id: end-of-file-fixer

この設定例では、公式のpre-commit-hooksリポジトリからいくつかの基本的なフックを使用しています。各フックは特定のタスクを実行し、コードの品質を向上させるのに役立ちます。

`pre-commit`フックのインストール

.pre-commit-config.yamlファイルを設定した後、次のコマンドを使用してpre-commitフックをリポジトリにインストールします：

pre-commit install

このコマンドは、Gitのpre-commitフックとしてpre-commitを設定し、コミットを行う際に自動的にこれらのフックが実行されるようにします。

次のセクションでは、コミットメッセージのプレフィックスをチェックするためのカスタムスクリプトの作成について詳しく説明します。

カスタムスクリプトの作成

pre-commitを使用してコミットメッセージのプレフィックスをチェックするためには、カスタムスクリプトを作成し、それをpre-commit設定に組み込む必要があります。

スクリプトの作成

プレフィックスをチェックするスクリプトは、シェルスクリプト（Bashスクリプトなど）で書くことができます。以下は、コミットメッセージが特定のプレフィックスで始まっているかどうかをチェックする簡単なスクリプトの例です：

#!/bin/bash
commit_regex='^(feat|fix|docs|style|refactor|test|chore):'
error_msg="エラー: コミットメッセージは 'feat|fix|docs|style|refactor|test|chore:' のいずれかで始まる必要があります。"

if ! grep -qE "$commit_regex" "$1"; then
 echo "$error_msg" >&2
 exit 1
fi

このスクリプトは、コミットメッセージがfeat, fix, docs, style, refactor, test, choreのいずれかで始まっていることを確認します。そうでない場合、エラーメッセージを表示し、コミットを拒否します。

スクリプトのテスト

スクリプトを作成したら、適切に動作するかどうかをテストすることが重要です。スクリプトをリポジトリのルートに保存し（例：commit-msg-lint.sh）、実行可能にします：

chmod +x commit-msg-lint.sh

そして、異なるコミットメッセージを使ってスクリプトが正しく動作するかを確認します。

`pre-commit`にスクリプトを組み込む

カスタムスクリプトをpre-commitに組み込むには、.pre-commit-config.yamlファイルにスクリプトを追加します。以下はその設定例です：

repos:
-  repo: local
 hooks:
 -  id: commit-msg-lint
 name: Check commit message format
 entry: ./commit-msg-lint.sh
 language: script
 stages: [commit-msg]

この設定により、pre-commitがコミットメッセージをチェックする際にカスタムスクリプトが実行されます。

次のセクションでは、pre-commitの使用において遭遇する可能性がある一般的なトラブルシューティングについて説明します。

`pre-commit`におけるトラブルシューティング

pre-commitを使用する際には、いくつかの一般的な問題に直面することがあります。ここでは、これらの問題のいくつかとその解決策について説明します。

スクリプトが実行不可能な場合

時折、pre-commitがカスタムスクリプトを実行不可能と認識することがあります。この問題は、スクリプトに適切な実行権限が設定されていない場合に発生することが多いです。スクリプトに実行権限を与えるには、次のコマンドを使用します：

chmod +x commit-msg-lint.sh

これで、スクリプトは実行可能になります。しかし、これだけでは不十分な場合もあります。Gitのインデックスとファイルシステムの間で実行権限の不一致が生じている場合、git update-indexコマンドを使用してこの問題を解決することができます：

git update-index --chmod=+x commit-msg-lint.sh

他の一般的な問題

他にも、設定ファイルの誤りや、pre-commitフックの不適切な設定など、さまざまな問題が発生する可能性があります。これらの問題を解決するには、以下のステップを試みてください：

.pre-commit-config.yaml ファイルの設定を再確認し、構文エラーがないかチェックします。
pre-commitフックを再インストールします：pre-commit install
詳細なエラーメッセージを確認し、具体的な問題の原因を特定します。

これらの一般的なトラブルシューティング手法を試みることで、ほとんどの問題は解決できるはずです。

次のセクションでは、pre-commitの使用におけるベストプラクティスと結論について説明します。

結論とベストプラクティス

`pre-commit`の有効活用

pre-commitを使用することで、コードの品質を維持し、開発プロセスを効率化することが可能です。特に、コミットメッセージのプレフィックスを自動的にチェックすることにより、プロジェクトの整理と追跡が容易になります。以下はpre-commitを最大限に活用するためのいくつかのベストプラクティスです：

明確なプレフィックスの規則を設定する：プロジェクトのニーズに合わせて、明確なプレフィックスの規則を設定し、チーム全体で共有します。
カスタムフックを適切にテストする：新しいフックを追加する際は、適切にテストを行い、予期しない挙動がないことを確認します。
ドキュメントを整備する：pre-commitの設定や使用するフックに関するドキュメントを整備し、新しいチームメンバーが迅速に理解できるようにします。

コード品質の維持の重要性

pre-commitは、コードレビューの負担を軽減し、品質を一定の水準で保つのに役立ちます。自動化されたチェックを導入することで、コーディング規約の遵守、バグの早期発見、一貫性のあるコミットメッセージの作成など、多くの利点があります。

最後に

この記事では、pre-commitを使用してコミットメッセージのプレフィックスをチェックする方法について解説しました。適切なツールとプロセスを取り入れることで、開発プロジェクトの効率と品質を同時に高めることが可能です。これらのプラクティスを活用して、より良いソフトウェア開発を目指しましょう。

Gitの”Executable … not executable”エラー: 原因と解決法

Wed, 15 Nov 2023 16:21:47 +0900

はじめに

Gitとpre-commitは、現代のソフトウェア開発プロセスにおいて中心的な役割を果たしています。これらのツールを使うことで、開発の効率を高めながらもコードの品質を維持することができます。しかし、これらを日常的に使用する中で、予期しない問題に遭遇することもあります。今回の記事では、そんな一つの典型的な問題、「Executable /path/to/your-script.sh is not executable」というエラーメッセージに遭遇した際の解決方法を掘り下げます。

この問題は、Gitリポジトリ内のスクリプトファイルに適切な実行権限が設定されているにも関わらず、pre-commitフックがそのファイルを実行不可能とみなす状況を指します。それでは、このエラーがどのような状況で発生するのか、見ていきましょう

背景

Gitと`pre-commit`の基本

Gitは、ソースコードのバージョン管理に広く使用されているシステムです。それに対してpre-commitは、Gitのコミットプロセスにフック（カスタムスクリプト）を組み込むためのツールで、コードの品質を確保するための自動化されたチェックを提供します。これらのフックは、コードがリポジトリにコミットされる前に様々なタイプの検証を行います。

実行権限の重要性

UNIX系オペレーティングシステム（LinuxやmacOSを含む）では、ファイルの実行権限は非常に重要です。スクリプトやプログラムが実行されるためには、適切な実行権限が設定されている必要があります。この権限は、ファイルシステム上でchmodコマンドを使って設定されます。

Gitの実行権限の取り扱い

Gitは、ファイルの内容と共に、その実行権限の状態も追跡します。しかし、Gitのインデックス（ステージングエリア）とローカルファイルシステムの間で実行権限の状態に不一致が生じることがあります。特に、異なる環境やファイルシステム間でGitリポジトリが共有される場合、この問題はより複雑になることがあります。

問題の全体像

この背景において、Executable not executableというエラーメッセージは、Gitがスクリプトファイルの実行権限を正しく認識していない場合に発生します。これは、pre-commit などのツールがスクリプトを実行しようとした際に特に顕著になります。この問題を解決するためには、Gitのインデックスとローカルファイルシステムの間の実行権限の状態を同期させる必要があります。

問題の詳細

開発者として、私たちは頻繁にコードの品質を確保し、バグを未然に防ぐためにpre-commitフックを利用します。ある日、私は自分のプロジェクトにカスタムのpre-commitフックを追加しようとしました。このフックは、コミットメッセージが特定のフォーマットに従っているかどうかをチェックするものでした。

しかし、このフックを追加した後、コミットしようとすると次のようなエラーメッセージが表示されました：

Executable `/path/to/your-script.sh` is not executable

このエラーメッセージは、私のスクリプトが実行不可能とみなされていることを示していました。しかし、ファイルには明らかに実行権限が与えられていました。これは、特に混乱を招く問題でした。

最初のトラブルシューティングの試み

問題の解決に取り組むため、まずは基本的なトラブルシューティングから始めました。最初のステップとして、スクリプトファイルの実行権限を確認しました。ターミナルで以下のコマンドを実行しました：

ls -l /path/to/your-script.sh

結果は、ファイルが実行権限を持っていることを示していました（-rwxr-xr-x）。次に、Gitのcore.fileMode設定がファイルの実行権限を正しく追跡しているかどうかを確認しました。この設定は、Gitがファイルの実行権限の変更を検出するかどうかを決定します。

しかし、これらの基本的なチェックにも関わらず、問題は解決しませんでした。ファイルには明らかに実行権限が付与されているにもかかわらず、pre-commitは依然としてスクリプトを実行不可能と認識していました。この時点で、問題がもう少し複雑なものであることが明らかになりました。

解決策：`git update-index --chmod=+x`

最初のトラブルシューティングのステップが効果を示さなかった後、さらに深く問題を掘り下げました。調査の結果、Gitのインデックスとファイルシステムの間で実行権限の状態に不一致が生じている可能性が浮上しました。この不一致を解消するために、git update-index --chmod=+x コマンドを使用することにしました。

このコマンドは、Gitに対して特定のファイルに実行権限があることを明示的に指示します。コマンドを実行することで、Gitのインデックスが更新され、ファイルが実行可能として認識されるようになります。以下のコマンドを実行しました：

git update-index --chmod=+x /path/to/your-script.sh

このコマンドを実行した後、再びコミットを試みると、今度は成功しました。エラーメッセージは消え、pre-commit フックが正常に実行されました。

なぜこのコマンドが効果的だったのか

git update-index --chmod=+x コマンドが効果的だった理由は、Gitのインデックスがローカルのファイルシステムの状態と同期していなかったためです。通常、Gitはファイルの内容とメタデータ（この場合は実行権限）を追跡しますが、特定の状況下ではこれらの情報が不一致になることがあります。このコマンドによって、Gitの内部状態が強制的に更新され、スクリプトが実行可能であるという情報がGitのインデックスに正しく反映されました。

この経験から、特に複数の環境やファイルシステムを跨いで作業する場合には、Gitのインデックスとローカルのファイルシステムの間で生じる可能性のある不一致に注意が必要であることがわかりました。

他の関連する問題への適用

この問題とその解決策は、特定の状況に限定されるものではありません。実際、異なるオペレーティングシステムやGitの設定、さらには異なるバージョンのGitを使用する際にも類似の問題が発生する可能性があります。特に、チーム内で複数の開発環境が混在している場合、Gitのインデックスとファイルシステム間の不一致は一般的な問題となり得ます。

また、この問題はpre-commitフックに限定されず、他のGitフックやスクリプト実行の文脈でも発生する可能性があります。そのため、Gitの実行権限に関連するエラーに直面した場合は、git update-index --chmod=+x コマンドの使用を検討することが有益です。

結論

この経験から、私たちはGitとpre-commitの使用におけるいくつかの重要な教訓を学びました。最も重要なのは、Gitのインデックスとローカルのファイルシステムの間に生じる可能性のある不一致に注意を払うことです。また、標準的なトラブルシューティング手法が効果を示さない場合でも、Gitのより高度な機能やコマンドを使用して問題を解決する方法が存在することを理解することも重要です。

最後に、この問題は、開発者が遭遇する可能性のある一連の問題の一例に過ぎません。技術的な問題に直面した際には、根気強く原因を探求し、コミュニティやドキュメントからのサポートを活用することが不可欠です。このような経験は、技術的スキルの向上だけでなく、より良い開発者に成長するための道の一部です。

参考リンク

“Executable … is not executable” error · Issue #1514 · pre-commit/pre-commit

Pythonでシェルスクリプトを効率的に実行する: subprocessモジュールの利用

Wed, 15 Nov 2023 11:46:58 +0900

シェルスクリプトやコマンドラインツールをPythonから実行する機能は、多くの開発者にとって有用です。この機能を理解し適切に使いこなすことで、プログラムの自動化、システム管理、データ処理の効率が大幅に向上します。

しかし、この強力な機能を最大限に活用するためには、いくつかの重要なポイントを理解する必要があります。特に、subprocess モジュールの shell と text パラメータの適切な使用は、コードの安全性、効率、そして読みやすさに大きな影響を与えます。これらのパラメータを正しく理解し使い分けることで、Pythonを用いたシェルスクリプトの実行が、より強力かつ柔軟なものになります。

この記事では、Pythonでのシェルスクリプト実行の基本から始め、shell と text パラメータの詳細な使い方、そしてこれらのパラメータを使用する際のベストプラクティスについて解説していきます。

基本的なスクリプトの実行

Pythonでシェルスクリプトや外部コマンドを実行する最も基本的な方法は、標準ライブラリの一部である subprocess モジュールを使用することです。このモジュールは、Pythonプログラムからシェルコマンドを実行し、その出力を捕捉するための強力な手段を提供します。

`subprocess.run()` 関数の使用

subprocess.run() は、外部コマンドを実行し、その結果を取得するための主要な関数です。最も単純な形では、実行したいコマンドの名前を文字列として渡します。例えば、Unix系システムでディレクトリの内容をリストする ls コマンドを実行するには、以下のように書きます：

import subprocess

# 'ls' コマンドを実行
result = subprocess.run(['ls'], stdout=subprocess.PIPE)

このコードは、現在のディレクトリの内容をリストするコマンドを実行し、その出力を result 変数に格納します。ここで、stdout=subprocess.PIPE はコマンドの標準出力をキャプチャするために使用されます。

実用的なコード例

実際の使用例を見てみましょう。たとえば、特定のディレクトリ内のファイルを検索するコマンドを実行したい場合、次のようなコードを書くことができます：

# 'grep' コマンドを使用して特定のパターンを検索
result = subprocess.run(['grep', '特定のパターン', 'ファイル名'], stdout=subprocess.PIPE)

# 結果の出力
print(result.stdout.decode('utf-8'))

このスクリプトは、指定されたファイル内で「特定のパターン」を検索し、見つかった行を表示します。ここで、decode('utf-8') は、標準出力を人間が読める形式（UTF-8エンコードされたテキスト）に変換します。

`shell` パラメータ

subprocess.run() 関数を使用する際に重要な選択の一つが shell パラメータの設定です。このパラメータは、コマンドがどのように実行されるかを制御し、セキュリティと機能の両面に影響を与えます。

`shell=True` の利用

shell=True を指定すると、指定されたコマンドはシェル（bash, cmd.exeなど）を介して実行されます。これにより、シェルの機能（ワイルドカード、パイプライン、リダイレクトなど）を利用することができます。たとえば、複数のコマンドをパイプラインで連結する場合、shell=True が必要です。

# 'grep' コマンドをパイプラインで使用
result = subprocess.run("ls | grep '特定のパターン'", shell=True, stdout=subprocess.PIPE)

ただし、このモードはセキュリティリスクが伴います。特に、不適切に制御された入力からコマンドを構築する場合、シェルインジェクション攻撃に対して脆弱になる可能性があります。そのため、shell=True は信頼できる入力に対してのみ使用すべきです。

`shell=False` の安全性

デフォルトでは、shell パラメータは False に設定されています。このモードでは、コマンドはシェルを介さずに直接実行されます。これにより、セキュリティが強化され、シェルインジェクション攻撃のリスクが低減されます。

# シェルを介さずに 'grep' コマンドを実行
result = subprocess.run(['grep', '特定のパターン', 'ファイル名'], stdout=subprocess.PIPE)

このモードでは、シェルの特殊な機能を使用することはできませんが、より安全で予測可能なコマンド実行が可能です。

出力の処理：`text` パラメータ

subprocess.run() 関数を使用する際にもう一つ重要な選択肢が text パラメータです。このパラメータは、コマンドの出力をどのように扱うかを制御し、使いやすさとデータの扱い方に大きな影響を与えます。

`text=True` の利点

text=True を指定すると、コマンドの出力は文字列（str 型）として返されます。これにより、出力を直接テキストとして処理することができ、コードがより簡潔かつ直感的になります。

# 'grep' コマンドの出力を文字列として扱う
result = subprocess.run(['grep', '特定のパターン', 'ファイル名'], stdout=subprocess.PIPE, text=True)
print(result.stdout) # 出力は直接文字列として扱える

このモードは、コマンドの出力をテキスト処理する場合に非常に便利です。例えば、出力を検索したり、ファイルに書き込んだり、ユーザーに表示したりする際に役立ちます。

`text=False` の場合

デフォルトの text=False は、出力をバイト列（bytes 型）として返します。これは、バイナリデータを扱う場合や特定のエンコーディングでデータを処理する場合に適しています。

# 'grep' コマンドの出力をバイト列として扱う
result = subprocess.run(['grep', '特定のパターン', 'ファイル名'], stdout=subprocess.PIPE)
print(result.stdout.decode('utf-8')) # バイト列をデコードして文字列に変換

このモードでは、出力をデコードする追加のステップが必要ですが、バイナリデータや特殊なエンコーディングを扱う際には必要不可欠です。

使い分け

text パラメータの設定は、出力の扱い方とプログラムの使いやすさに直接影響します。テキストベースの出力を扱う場合は text=True が便利ですが、バイナリデータや特殊なエンコーディングを扱う場合（（例えば、画像データや特定の文字セットを扱う場合）には text=False を選択すると良いでしょう。

エラー処理とデバッグ

Pythonでシェルスクリプトを実行する際には、エラー処理とデバッグが重要な役割を果たします。適切なエラー処理と効果的なデバッグ手法を用いることで、信頼性の高いスクリプトを作成することができます。

エラー処理の重要性

シェルスクリプトの実行中には様々なエラーが発生する可能性があります。これには、コマンドが見つからない、コマンドが失敗する、間違った引数が渡されるなどが含まれます。これらのエラーを適切に処理することで、スクリプトの堅牢性を高めることができます。

`try-except` ブロックの使用

Pythonの try-except ブロックを使用して、subprocess.run() からの例外を捕捉し、適切に処理することができます。例えば、以下のコードは、コマンド実行中に発生したエラーを捕捉し、エラーメッセージを表示します：

import subprocess

try:
 subprocess.run(['ls', '-l'], check=True)
except subprocess.CalledProcessError as e:
 print(f"エラー: {e}")

ここで、check=True はコマンドが非ゼロの終了ステータスで終了した場合に CalledProcessError を発生させるために使用されます。

デバッグのヒント

デバッグの際には、コマンドの正確な出力やエラーメッセージが重要な手がかりとなります。以下に、デバッグを容易にするためのヒントをいくつか紹介します。

標準出力と標準エラーのログ記録

コマンドの標準出力と標準エラーをログに記録することで、問題の診断が容易になります。例えば：

result = subprocess.run(['ls', '-l'], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
print("標準出力:", result.stdout.decode())
print("標準エラー:", result.stderr.decode())

この方法では、コマンドの実行結果を詳細に確認することができます。

エラーコードの確認

コマンドが失敗した場合、エラーコード（終了ステータス）を確認することが有効です。例えば：

result = subprocess.run(['ls', '-l'], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
if result.returncode != 0:
 print(f"エラーコード: {result.returncode}")

このエラーコードは、コマンドが何故失敗したかを理解するための手がかりとなります。

結論

この記事を通じて、Pythonを使用してシェルスクリプトを実行する際の重要な側面を探求しました。subprocess モジュールの shell と text パラメータの適切な使用方法を理解することで、Pythonスクリプトの機能と安全性を最大限に引き出すことができます。

shell パラメータは、シェルの特性を活用する際に重要ですが、セキュリティリスクを考慮して慎重に使用する必要があります。
text パラメータは、コマンドの出力を文字列として扱うかバイト列として扱うかを決定し、出力の扱いやすさを大きく左右します。

また、エラー処理とデバッグの重要性を理解し、これらのテクニックを適切に適用することで、より堅牢で信頼性の高いスクリプトを作成できます。

Pythonを使用したシェルスクリプトの実行は、多くの自動化とプロセス管理タスクにおいて強力なツールです。この記事が提供するガイダンスとヒントを活用することで、あなたのプロジェクトにおいても、より効率的で安全なスクリプトの実装が可能になることを願っています。

メタデータを含まないGitHub.comからGitHub Enterpriseへのリポジトリ移行ガイド

Tue, 14 Nov 2023 13:29:37 +0900

導入: GitHubからGitHub Enterpriseへのリポジトリ移行の際は、まずメタデータの移行をするかどうかが重要な判断となります。GitHubリポジトリのメタデータ（Issueやプルリクエストなど）の移行を行うかどうかを判断する際に考慮すべきポイントは以下の通りです：

プロジェクトの歴史の重要性: 過去のIssueやプルリクエストが将来のプロジェクト運営に重要な情報を含んでいる場合、これらのデータを移行する価値があります。
プロジェクトの継続性: 新しい環境でのプロジェクトの継続性を保つために、過去の議論や決定の履歴を参照できることが重要な場合は、メタデータの移行を検討すべきです。
リソースと技術力: メタデータの移行は複雑で時間とリソースを要するプロセスです。十分な技術力とリソースがあるかどうかを評価してください。
プロジェクトの将来計画: プロジェクトが新しいフェーズに入っており、過去のデータがそれほど関連性を持たない場合、メタデータの移行は必要ないかもしれません。

これらの要素を総合的に検討し、プロジェクトのニーズとリソースに基づいて決定を下すことが重要です。

Issueやプルリクエスト（PR）などのメタデータを含まなくてよい場合、移行は比較的簡単なプロセスです。ここでは、コードとコミット履歴のみを移行する手順を詳細に説明します。

手順:

新しいリポジトリの作成:

GitHub Enterpriseにログインし、新しいリポジトリを作成します。このリポジトリは空である必要があります。

ローカルリポジトリの準備:

移行するローカルリポジトリで作業している場合、最新の状態に更新しておきます（git pull）。

リモートURLの変更:

リポジトリのリモートURLをGitHub Enterpriseの新しいリポジトリURLに変更します。これにはgit remote set-url origin [新しいURL]コマンドを使用します。（ .git/configを参照することで変更を確認できます）

コードのプッシュ:

git push -u origin master（または対象のブランチ名）を使用して、コードを新しいリポジトリにプッシュします。

チームメンバーへの指示:

チームの他のメンバーも、自分のローカルリポジトリで同じリモートURLの変更を行う必要があります。

注意点:

この方法では、コードとコミット履歴のみが移行されます。GitHubのメタデータ（Issue、PRなど）は移行されません。これらの情報を移行したい場合は、追加の手順が必要です。

結論: GitHub.comからGitHub Enterpriseへのリポジトリ移行は、上記の手順を実行することで、簡単かつ効率的に行うことができます。ただし、プロジェクトの要件に応じて、メタデータの移行も検討してください。

[Mac] シェルスクリプトでファイルを日付別に整理する方法

Tue, 31 Oct 2023 22:34:55 +0900

はじめに

ファイルの整理は作業効率を上げる重要なステップです。特に、多くのファイルがあるディレクトリでは、ファイルを日付別に分類することで目的のファイルを素早く見つけられるようになります。

この記事では、シェルスクリプトを使用してファイルを最終変更日に基づいて日付別のフォルダに自動で移動する方法を紹介します。

手順

ターミナルを開き、整理したいファイルがあるディレクトリに移動します。
以下のシェルスクリプトを作成します。

#!/bin/bash

for file in *; do
 if [ -d "$file" ]; then
 continue
 fi
 date=$(stat -f "%Sm" -t "%Y-%m-%d" "$file")
 if [ ! -d "$date" ]; then
 mkdir "$date"
 fi
 mv "$file" "$date/"
done

スクリプトを保存し、実行権限を与えます。

chmod +x script.sh

スクリプトを実行します。

./script.sh

まとめ

この記事では、シェルスクリプトを使用してファイルを最終変更日に基づいて日付別のフォルダに自動で分類する方法を紹介しました。簡単なスクリプトで作業効率が大幅に向上します。是非お試しください。

Fishスクリプトでファイル名に日付時刻を追加する

Fri, 29 Sep 2023 07:52:46 +0900

Fishシェルは、その美しいシンタックスと強力な機能で知られています。この記事では、Fishスクリプトを使用してカレントディレクトリの各ファイル名にタイムスタンプ（ここでは日付と時刻の文字列）を追加する方法を紹介します。このスクリプトは、既にタイムスタンプが付いているファイルは無視するので、複数回実行しても安全です。また、ディレクトリは対象外です。

以下に、タイムスタンプを追加するためのスクリプトを示します。

ワンライナースクリプト:

for file in *; if test -f $file; and not string match -r "^[0-9]{14}_" $file > /dev/null; set timestamp (date -r $file +"%Y%m%d%H%M%S"); mv $file "$timestamp"_"$file"; end; end

分割バージョン:

for file in *
 if test -f $file; and not string match -r "^[0-9]{14}_" $file > /dev/null
 set timestamp (date -r $file +"%Y%m%d%H%M%S")
 mv $file "$timestamp"_"$file"
 end
end

bashバージョン:

for file in *; do
 if [[ -f $file ]] && [[ ! $file =~ ^[0-9]{14}_ ]]; then
 timestamp=$(date -r "$file" +"%Y%m%d%H%M%S")
 mv "$file" "${timestamp}_$file"
 fi
done

これらのスクリプトは、カレントディレクトリの全てのファイルをループし、各ファイルに対して以下の操作を行います

test -fコマンドを使用して、アイテムがファイルであることを確認します（ディレクトリは除外されます）。
string matchコマンドを使用して、ファイル名が既にタイムスタンプを含んでいるかどうかを確認します。
タイムスタンプが含まれていない場合、dateコマンドを使用してファイルのタイムスタンプを生成します。
mvコマンドを使用して、生成されたタイムスタンプとアンダースコアをファイル名の先頭に追加し、ファイル名を変更します。

このスクリプトは、ファイルの整理と管理を容易にし、ファイルのバージョン管理を簡単に行えるようにします。

サブディレクトリ下の画像ファイルをwebp形式に変換するシェルスクリプト

Sun, 24 Sep 2023 15:38:27 +0900

はじめに

この記事では、サブディレクトリに存在する.PNG, .png, .jpg, .jpeg, .JPG, .JPEG ファイルを.webp形式に変換し、元の画像ファイルを削除するスクリプトを、BashとFishシェルでそれぞれ実装する方法について説明します。

必要なツール

ImageMagick (convert コマンドが使用されます)

Fishのスクリプト

コード

for img in /*.PNG /*.png /*.jpg /*.jpeg /*.JPG /*.JPEG
 set name (basename $img .(string split -r -m1 '.' $img)[2])
 set dir (dirname $img)
 set new_path $dir/$name.webp
 convert $img $new_path
 rm $img
end

ワンライナー

for img in /*.PNG /*.png /*.jpg /*.jpeg /*.JPG /*.JPEG; set name (basename $img .(string split -r -m1 '.' $img)[2]); set dir (dirname $img); set new_path $dir/$name.webp; convert $img $new_path; rm $img; end

Bashのスクリプト

コード

#!/bin/bash
find . -type f \( -iname '*.png' -o -iname '*.jpg' -o -iname '*.jpeg' \) -exec sh -c '
 f="{}"
 d=$(dirname "$f")
 b=$(basename "$f")
 nf="${d}/$(basename "${b%.*}").webp"
 convert "$f" "$nf"
 rm "$f"
' \;

ワンライナー

find . -type f \( -iname '*.png' -o -iname '*.jpg' -o -iname '*.jpeg' \) -exec sh -c 'f="{}"; d=$(dirname "$f"); b=$(basename "$f"); nf="${d}/$(basename "${b%.*}").webp"; convert "$f" "$nf"; rm "$f"' \;

結論

以上がBashとFishで.PNG, .png, .jpg, .jpeg, .JPG, .JPEG ファイルを.webpに変換するスクリプトの書き方です。これにより、簡単に画像ファイルの形式を変更することができます。

文字列混じりのファイル名の数字部分をゼロ埋めするスクリプト

Sun, 24 Sep 2023 15:02:56 +0900

背景

Linux や macOS などのシステムでよく使われる ls コマンドで出力されたファイル名リストが整列されていないと、作業効率が下がることがあります。特に、ファイル名の後ろに数字がついている場合、a1.png, a2.png, a10.png のように整列されていないことがよくあります。

この問題を解決するために、Fish シェルと Bash シェルで数字部分をゼロ埋めするスクリプトを作成します。

Fish シェル

Fish シェルでは以下のようにスクリプトを書きます。

for file in *.png
 set name (string match -r "[a-zA-Z]+" $file)
 set num (string match -r "\d+" $file)
 set new_num (printf "%02d" $num)
 mv $file "$name$new_num.png"
end

ワンライナー

for file in *.png; set name (string match -r "[a-zA-Z]+" $file); set num (string match -r "\d+" $file); set new_num (printf "%02d" $num); mv $file "$name$new_num.png"; end

Bash シェル

Bash シェルでは以下のようにスクリプトを書きます。

for file in *.png; do
 name=$(echo "$file" | grep -o "^[a-zA-Z]*")
 num=$(echo "$file" | grep -o "[0-9]*")
 new_num=$(printf "%02d" $num)
 mv "$file" "$name$new_num.png"
done

ワンライナー

for file in *.png; do name=$(echo "$file" | grep -o "^[a-zA-Z]*"); num=$(echo "$file" | grep -o "[0-9]*"); new_num=$(printf "%02d" $num); mv "$file" "$name$new_num.png"; done

まとめ

この記事で紹介したスクリプトを使えば、ls コマンドで出力されるファイル名の数字部分をゼロ埋めして、整列されたリストを得ることができます。Fish シェルと Bash シェルの両方で実現可能です。

カレントディレクトリのサブディレクトリを.cbz形式で圧縮するBashワンライナー

Sat, 23 Sep 2023 00:46:20 +0900

自炊ユーザ必携スクリプト。カレントディレクトリにあるjpgの塊のサブフォルダを.cbzにするワンライナをChatGPTに書かせたのであった。昔コツコツ書いていた自作のスニペットもう全部不要……。

イントロ

BashおよびFishシェルは、UNIX系オペレーティングシステムにおいて、コマンドラインから操作するためのインターフェースを提供します。これらのシェルを利用することで、システムの様々なタスクを一行のコマンドで実行できます。本記事では、これらのシェルを使用して、サブディレクトリを.cbz形式で圧縮する方法を紹介します。

Bashでの実行

Bashでは、以下のワンライナーを使用することで、カレントディレクトリに存在する全てのサブディレクトリを.cbz形式で圧縮できます。

for dir in */; do dir_name="${dir%/}"; zip -r "$dir_name.zip" "$dir_name"; mv "$dir_name.zip" "$dir_name.cbz"; done

Fishでの実行

Fishシェルでは、少し構文が異なります。以下のワンライナーを使用します。

for dir in */; set dir_name (string trim -r -c '/' $dir); zip -r $dir_name.zip $dir_name; mv $dir_name.zip $dir_name.cbz; end

プロセスの説明

カレントディレクトリの全サブディレクトリをリストアップします。
各サブディレクトリに対して、ディレクトリ名から末尾のスラッシュ(/)を削除し、その名前を変数にセットします。
次に、そのディレクトリをzip形式で圧縮します。
最後に、生成されたzipファイルの拡張子を.zipから.cbzに変更します。

.cbz形式は通常、コミックブックのリーダーアプリで使用される形式で、基本的にはzipアーカイブです。このワンライナーは、特にコミックや画像集の整理に有用で、シンプルでありながら、大量のディレクトリを効率的に圧縮するのに役立ちます。

シェルスクリプトで括弧を取り除く: BashとFishシェルのワンライナー

Sat, 23 Sep 2023 00:26:41 +0900

例によってFishスクリプトの備忘録。これのあとにゼロ埋めすること多し。

あわせて読みたい

シェルスクリプトでファイル名をゼロ埋めする方法: BashとFishシェル

/shell-zero-padding/

はじめに:

カレントディレクトリに存在する (数字).jpg 形式のファイル名から括弧 () を取り除く方法について、BashシェルとFishシェルでの簡単なワンライナーを紹介します。

Bash シェル:

Bash シェルでは、次のワンライナーで、カレントディレクトリにある全ての (*).jpg ファイル名から括弧を取り除くことができます。

for file in *'('*')'*.jpg; do mv "$file" "${file//\(/}"; done
for file in *')'*.jpg; do mv "$file" "${file//\)/}"; done

これにより、例えば (123).jpg というファイル名が 123.jpg に変更されます。

Fish シェル:

Fish シェルでは、以下のワンライナーで同様の操作が可能です。

for file in *'('*')'*.jpg; set new_file (string replace -ra '[()]' '' $file); mv $file $new_file; end

この Fish シェルのワンライナーは、カレントディレクトリに存在する (数字).jpg 形式のファイル名から、左括弧 ( と右括弧 ) を両方正しく取り除きます。

まとめ:

ファイル名から特定の文字を取り除くことは、ファイルの整理や管理を助けます。Bash シェルと Fish シェルのどちらでも、簡単なワンライナーでこの操作を行うことができます。

シェルスクリプトでファイル名をゼロ埋めする方法: BashとFishシェル

Sat, 23 Sep 2023 00:22:50 +0900

画像のファイル整理中とかに時々出てくるシチュエーションのbash, fishのワンライナスニペット。毎回ChatGPTに聞くのも煩わしいので備忘録メモ。

はじめに:

数値で構成されたファイル名（例： 1.jpg 、 10.jpg ）を3桁のゼロ埋め形式（例： 001.jpg 、 010.jpg ）に変更する方法について解説します。ここでは、BashシェルとFishシェルの両方で利用可能なワンライナーコマンドを紹介します。

Bash シェル:

Bash シェルでは、次のワンライナーコマンドで、カレントディレクトリにある全ての .jpg ファイル名をゼロ埋めできます。

for file in *.jpg; do [[ $file =~ ^([0-9]+)\.jpg$ ]] && mv "$file" "$(printf "%03d.jpg" ${BASH_REMATCH[1]})"; done

このコマンドは、カレントディレクトリに存在する全ての .jpg ファイルを対象にし、数字だけのファイル名を3桁のゼロ埋めに変更します。

Fish シェル:

Fish シェルでは、次のワンライナーで同等の操作が可能です。

for file in *.jpg; if echo $file | grep -qE '^[0-9]+\.jpg$'; set -l num (string match -r '([0-9]+)' $file)[2]; mv $file (printf "%03d.jpg" $num); end; end

Fish シェルでこのコマンドを実行すると、カレントディレクトリにある数字だけの .jpg ファイルが、3桁のゼロ埋め形式に変更されます。

まとめ:

シェルスクリプトを用いて、数値で構成されたファイル名をゼロ埋め形式に変更することは、ファイルの整理や管理を助けます。Bash シェルと Fish シェルのどちらも、簡単に同等の操作を実行することができます。

fishシェルの環境変数設定：-Ux vs -gx

Sun, 17 Sep 2023 12:50:48 +0900

環境変数の設定方法いつも忘れてしまうので、メモっておく。

イントロ

fishシェルは、その直感的な機能とユーザーフレンドリーな設定方法で多くの開発者から支持を受けています。この記事では、fishシェルで環境変数を設定する2つの一般的な方法、-Uxと-gxの違いと、それぞれの利点と欠点について詳しく説明します。

2つの方法

大別して、-Uxを使う方法と-gxを使う方法があります。

`-Ux`：ユニバーサル変数としてエクスポート

set -U：変数を永続的なユニバーサル変数として設定します。これは、すべてのfishインスタンスで共有され、セッション間で保存される変数です。
set -x：変数をエクスポートします。これにより、その変数が子プロセスに利用可能になります。

例として、MY_VARIABLEという名前の環境変数を永続的に設定し、それをエクスポートしたい場合、次のようにコマンドを使用します：

set -Ux MY_VARIABLE "Some Value"

このコマンドを実行すると、MY_VARIABLEはすべてのfishインスタンスと子プロセスで利用可能となります。そして、システムを再起動してもこの設定は保持されます。

ユニバーサル変数を削除する場合は、set -eオプションとともに変数の名前を指定します：

set -e MY_VARIABLE

このコマンドにより、指定されたユニバーサル変数が削除されます。

メリット:

永続性: すべてのセッション間で保持され、システム再起動後も失われません。
共有: すべてのfishインスタンス間で変数が共有されます。
インタラクティブ設定: コマンドラインから直接変数を設定・変更が可能です。

デメリット:

オーバーヘッド: 多くのユニバーサル変数を使用すると、起動時のオーバーヘッドが増加する可能性があります。
混乱の原因: 変数の変更が他の全てのfishインスタンスに影響します。

オススメするケース:

共通の設定: 複数の fish セッションやインスタンス間で共有したい設定がある場合。例えば、特定のプログラムのパスを追加したいときなど。
一時的な変更: インタラクティブに変数を変更し、その設定を暫定的にすべてのセッションで利用したい場合。
マシン全体の設定: 複数のユーザーアカウント間で共有したい設定がある場合。

`-gx`：グローバル変数としてエクスポート

-g オプションを使用して設定された変数は、グローバル変数として保存されます。
これは現在のセッション内でのみ存在し、新しいセッションやターミナルウィンドウで利用することはできません。
セッションが終了すると、グローバル変数も消失します。

いくつかの代表的な設定パターンを列挙します。

PATH変数にディレクトリを追加する

set -gx PATH $PATH /path/to/your/directory

新しい環境変数を設定する

set -gx MY_VARIABLE "Some Value"

既存の環境変数の値を変更する

set -gx PATH "/new/path:$PATH"

これらの設定を、設定ファイルに記述することで、セッションを開始する時に読み込まれます。

nano ~/.config/fish/config.fish

メリット:

明確な初期化: 変数の初期化が明確になり、文書化しやすくなります。
セッション固有: 特定のセッションにのみ変数や設定を適用可能です。

デメリット:

非永続性: セッションが終了すると変数は消失します。
変更の手間: 変数の変更のためには設定ファイルを編集し、新しいセッションを開始または設定ファイルを再読み込みする必要があります。

オススメするケース:

セッション固有の設定: あるセッションに特定の変数や設定を適用したいが、他のセッションには影響を与えたくない場合。
明確な管理: セッションの設定や起動時の動作を明確に制御したい場合。config.fish に明確な指示を書くことで、どの変数がセットされているか、なぜそれがそうなっているかを文書化しやすくなります。
多数の変数を設定: 多くの環境変数を設定する場合、それらを一か所（config.fish）にまとめることで、管理や変更が容易になります。

`-gx`を推奨

一般的なシナリオでは、-gxオプションをconfig.fishに記述する方法が推奨されます。これにより、設定の一元管理が容易になり、意図しない変数の共有や競合を避けることができます。しかしながら、特定の状況やニーズに応じて-Uxオプションを選択することも有効です。

環境変数の設定方法は、その用途やニーズに応じて最も適した方法を選択することが重要です。どちらの方法を選ぶかは、具体的な使用ケースやニーズに応じて異なるため、各プロジェクトやタスクの要件をよく理解し、適切な選択をするよう努めましょう。

寸評

こういう話題は得意だよねChatGPT。基本的には設定ファイルに書いてるかな。持ち運べるし。

fish,bashでのPNGとJPGファイルのWebPへの一括変換

Wed, 26 Jul 2023 14:28:43 +0900

単純な内容だけれどよく使うかつよく忘れるので。これ、本当はBardに書かせようと思っていたんだよね。でも、Bardはfishスクリプトだと言っているのにBashのスクリプトしか書いてくれなかった。あと日本語も通じづらくて、かなり明確に指示してやる必要がある。結論として、ChatGPT-4にはまだ及ばないなぁ、と。アホになっているという噂のChatGPT-4だが、それでも今出ているAIチャットでは一番なんじゃないだろうか。

ということで、記事を書かせた。

イントロ

こんにちは、皆さん。

今日はLinuxシェルを使ってカレントディレクトリのPNGとJPGファイルを一括でWebP形式に変換する方法についてご紹介します。この作業は、fish shellとbashの両方で実行可能です。Macのターミナルや、Windows上のWSL2でももちろん実行可能です。

前提条件として、この記事で用いるconvertコマンドはImageMagickの一部なので、事前にシステムにインストールしておく必要があります。

Fish Shellでの変換

まず、Fish Shellを使った方法から見ていきましょう。以下のワンライナーを実行すると、カレントディレクトリの全ての.pngと.jpgファイルが.webpに変換されます。

for file in *.png *.jpg; convert $file -format webp (basename -s (string match -r "\..+" $file) $file).webp; end

このコマンドは、まず*.png *.jpgというパターンで全てのPNGとJPGファイルを選択します。そして、convertコマンド（ImageMagickの一部として提供されている）を使ってそれぞれのファイルを.webpフォーマットに変換します。

Bashでの変換

次に、Bashを使った方法を見ていきましょう。以下のワンライナーを実行すると、同様にカレントディレクトリの全ての.pngと.jpgファイルが.webpに変換されます。

for file in *.{png,jpg}; do convert "$file" -format webp "${file%.*}.webp"; done

このコマンドでは、*.{png,jpg}というパターンマッチングを使用して.pngと.jpgファイルを一度に全て選択します。そして、"${file%.*}.webp"という表現を用いて元のファイル名から拡張子を取り除き、新しい.webp拡張子を追加します。

結論

以上が、Fish ShellとBashを使ってPNGとJPGファイルをWebPに一括変換する方法です。このようなスクリプトは、特に大量の画像ファイルを効率的に変換したいときに非常に便利です。

寸評

実家のような安心感。なんだかんだでChatGPT-4パイセンが今のところナンバーワンですわ……。

fishでカレントディレクトリのすべてのpngをwebpにconvertするワンライナ
いいね。pngだけではなくjpgについてもやりたい時は？
ありがとう。ここまでの内容を、ブログの記事としてまとめてください。

質問の数もシンプル。

Node.jsのバージョン一覧をCLIから取得する方法

Wed, 19 Jul 2023 15:54:41 +0900

fishではnvmのサポートが微妙ということで、Node.jsのバージョン管理にはvoltaを使うことにした。が、voltaは配布されているNodeのバージョン一覧を取得するコマンドがない。まぁ volta install node@18とかでざっくりインストールすればいいからだと思うが。まぁそうは言っても、バージョン一覧をCLIから取得したいなぁと思って、ChatGPT-4に聞いた。

環境

M2 Pro MacBook Pro 14インチ
macOS 13.4.1
fish 3.6.1

はじめに

Node.jsはJavaScriptをサーバーサイドで実行するための環境で、そのバージョン管理は重要な作業の一部です。今日は、Node.jsの公式配布元から利用可能なすべてのNode.jsのバージョンを一覧表示する方法を紹介します。これにより、特定のバージョンが存在するか確認したり、どのバージョンをインストールすべきか決定する際の参考にすることができます。

Node.jsのバージョン一覧を取得するコマンド

以下のコマンドを使用します：

curl -s https://nodejs.org/dist/ | grep -Eo 'v[0-9]+\.[0-9]+\.[0-9]+/' | sed 's/\///g' | sort -V

以下のような出力が得られます：

v0.1.14
v0.1.14
v0.1.15
v0.1.15
...
v20.1.0
v20.2.0
v20.2.0
v20.3.0
v20.3.0
v20.3.1
v20.3.1
v20.4.0
v20.4.0

このコマンドは以下の操作を行っています：

curl -s https://nodejs.org/dist/：Node.jsの公式配布元からHTMLを取得します。
grep -Eo 'v[0-9]+\.[0-9]+\.[0-9]+/'：取得したHTMLからバージョン番号を抽出します。-Eオプションは拡張正規表現を使用することを指定し、-oオプションは一致した部分のみを出力します。
sed 's/\///g'：バージョン番号の末尾にあるスラッシュ(/)を削除します。
sort -V：バージョン番号を順番に並べ替えます。-Vオプションはバージョン番号のような形式を正しくソートすることを指定します。

注意点

このコマンドはUNIXベースのシステム（LinuxやmacOSなど）で動作します。Windowsの場合、同等の操作を行うためにはWindows Subsystem for Linux（WSL）や、cygwin、git bashなどのツールが必要です。

まとめ

Node.jsのバージョン管理は、プロジェクトの安定性や互換性を確保するために重要です。今回紹介したコマンドを使えば、CLIから簡単にNode.jsのバージョン一覧を取得でき、適切なバージョンの選択に役立つでしょう。

寸評

質問一発で返ってきそうだが、以外にも引っかかっている。

node.jsのマネージャであるvoltaでnodeを入れたいのだが、インストールできるバージョンの一覧はどのように取得できるのか
コマンドラインからNode.jsで配布されているバージョンを簡単に取得するにはどうしたらよいか
grep: invalid option – P usage: grep [-abcdDEFGHhIiJLlMmnOopqRSsUVvwXxZz] [-A num] [-B num] [-C[num]] [-e pattern] [-f file] [–binary-files=value] [–color=when] [–context[=num]] [–directories=action] [–label] [–line-buffered] [–null] [pattern] [file …] とエラーが出た。Macのターミナルで実行した。
何も出力されない。awkによる抽出が失敗していると見られる。curlのレスポンスを一部抜粋した。これを見て修正できるか。（コードを貼る）
うまく動いた！備忘録としてブログにまとめたい。CLIからnodeのバージョン一覧を取得する方法について、ブログ記事としてまとめてくれ。適切に見出しを入れてくれ。

失敗したが、実際の出力を貼ることでうまくいった。

【Macユーザー必見】右クリックから画像をwebpに瞬時に変換しよう！

Sun, 16 Jul 2023 14:13:24 +0900

内容はタイトルのとおりで、クイックアクションを使ってwebpに変換するコマンドを作成するというもの。要はこれを作る。

これは普通に便利だよ。では以下、ChatGPT-4によるテンション高めの記事本文。

イントロ

こんにちは、今日はMacの便利な機能であるクイックアクションを使って、画像をwebp形式に変換する方法をご紹介します。この方法を使えば、画像ファイルを右クリックするだけで簡単にwebp形式に変換することができます。

手順は以下の通りです。

準備

今回の作業のための準備をしましょう。いくつかのツールを入れる必要があります。

Homebrewのインストール

まずはHomebrewをインストールします。HomebrewはMacでソフトウェアを簡単に管理するためのパッケージ管理システムです。既にインストールしてある方はこの手順をスキップしてください。ターミナルを開き、以下のコマンドを実行します。

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

libwebpのインストール

次に、Homebrewを使ってlibwebpをインストールします。libwebpはGoogleが開発した画像形式であるwebpへの変換ツールです。ターミナルで以下のコマンドを実行します。

brew install webp

クイックアクションの作成

Automatorを開き、「新規ドキュメント」を作成します。「ドキュメントの種類」の選択画面が表示されたら、「クイックアクション」を選択します。選択したら、下記のような設定をしますので、手順を説明します。

「ワークフローが受け取る現在の項目」の項目で「イメージファイル」を選択し、さらにその右隣の「検索対象」のドロップダウンから「Finder」を選択します。

左側のパネルから「ユーティリティ」カテゴリを開き、「シェルスクリプトを実行」を右側の空白領域にドラッグアンドドロップします。

シェルスクリプトアクションに以下のコマンドを入力します（「入力の引き渡し方法」は「引数として」に設定）。

for f in "$@"
do
 /usr/local/bin/cwebp "$f" -o "${f%.*}.webp"
done

著者注記: あらかじめ which cwebp でcwebpのパスを調べておく。 /opt/homebrew/bin/cwebpにする必要があるかも。

クイックアクションの実行

メニューバーの「ファイル」から「保存」を選び、クイックアクションに名前をつけて保存します。この名前がコマンドの名前になるため、「webpに変換」などのわかりやすい名前にしましょう。

これで準備は完了です。Finderから画像ファイルを右クリックすると、コンテクストメニューの「クイックアクション」の中に新しく作成したアクションが表示されます。選択すると、選択した画像ファイルがwebp形式に変換され、元の画像と同じ場所に保存されます。

注意点、画質と元画像の削除について

元画像の削除

注意点として、このコマンドは元の画像ファイルを保持しつつ新しいwebpファイルを作成します。元の画像を削除したい場合は、上記のシェルスクリプトにrm "$f"コマンドを追加します。これにより、変換後のwebpファイルが作成された後に元の画像が削除されます。

以下に修正したコードを示します。

for f in "$@"
do
 /usr/local/bin/cwebp "$f" -o "${f%.*}.webp"
 rm "$f"
done

このコードは元のファイルを完全に削除するため、誤って重要なファイルを削除しないように十分注意してください。実行前にバックアップを取るなど、データの安全対策を忘れずに行ってください。

画像の品質

また、出力されるwebp画像の品質はデフォルトの設定（75％）になります。品質設定を変更するには、上記のcwebpコマンドに-qオプションを追加します（例：-q 90）。

以上で、Macのクイックアクションを使って画像を簡単にwebpに変換する方法のご紹介を終えます。ぜひ試してみてください。

寸評

有能。シェルスクリプトを交えつつAutomatorを使った完全なガイド。これはGoogle検索だと中々出てこない。

以下のような質問をした。

Macのクイックアクションで、画像をwebpに変換するアクションを作成したい！
素晴らしい。完璧だ。UIは日本語のほうがよかったが、そこは僕が補足しよう。クイックアクションで画像ファイルを右クリックから手軽にwebpに変換できるようにする方法について、ブログ記事としてまとめてくれ
元の画像を削除したい場合のコードについても書いたほうがいいな。

解説のUIが思いっきり英語だったので、僕のほうで直すといったところ、なんだか日本語化しようと頑張っていたが、結果間違っていたのでそこは僕が修正した。相変わらずディテールを間違えるChatGPT。こうして人間の仕事は微調整になっていくのか……。

WSL2でMacのようにクリップボードを操作する方法

Sun, 16 Jul 2023 00:52:55 +0900

Macだとpbcopyやpbpasteといったコマンドでクリップボードの内容をターミナル上で扱うことができて、これが非常に便利。Windowsでも同じことができないか、ChatGPT-4に聞いたところ非常にうまくいったので、ブログ記事としてまとめさせた。

イントロ

Windows Subsystem for Linux 2（WSL2）は、Windows上でLinuxを動作させることができる強力なツールです。しかし、Macユーザーが利用できる便利なpbcopyとpbpasteコマンドのような、クリップボードに直接アクセスする機能がデフォルトではありません。この記事では、WSL2でこれらのコマンドを模倣する方法を解説します。

Windowsのクリップボードにコピー

WSL2からWindowsのクリップボードにコピーするには、Windows側のclip.exeコマンドを利用します。例えば次のようにします:

echo 'テキスト' | clip.exe

Windowsのクリップボードからペースト

逆に、WindowsのクリップボードからWSL2にペーストするには、powershell.exeを利用します:

powershell.exe -command 'Get-Clipboard'

コマンドを短くする

これらのコマンドは有用ですが、特にペーストの方は長く、打つのが面倒かもしれません。それを解決するために、pbcopyとpbpasteというエイリアスを定義します。

bashの場合

bash シェルを使っている場合、.bashrc ファイルに以下のエイリアスを追加します:

alias pbcopy='clip.exe'
alias pbpaste='powershell.exe -command Get-Clipboard'

そして、ターミナルを再起動するか、以下のコマンドを実行して新しいエイリアスを利用可能にします:

source ~/.bashrc

これで、Macのように pbcopy と pbpaste コマンドを使用することができます。

fishの場合

Fish shellでは、関数として定義して、config.fishファイルに保存することで、同様の機能を実現できます。

まず、Fish shellで新しい関数を作成します:

function pbcopy
 command echo -n $argv | clip.exe
end

function pbpaste
 powershell.exe -command 'Get-Clipboard' 
end

次に、これらの関数を保存します。以下のコマンドは、作成した関数を ~/.config/fish/functions/ ディレクトリに保存します：

funcsave pbcopy
funcsave pbpaste

以上の手順で、pbcopyとpbpasteの機能をFish shellで使用できるようになります。新たなシェルセッションでもこれらの関数が使用可能になるよう、手動で定義するのではなく、funcsave コマンドを使って保存することが重要です。

結論

これにより、WSL2でもMacのようにクリップボードを操作することが可能になります。この機能を利用すれば、シェルスクリプトやコマンドラインツールから直接クリップボードにアクセスすることができ、作業の効率を上げることができます。

寸評

これでWSL2でもpbcopyやpbpasteといったコマンドを使えるようになった。pbcopyで一行改行ができるのが少し気になるが……。まぁでもこれは便利だね。

以下、質問した内容。

Macではpbcoyやpbpasteでクリップボードの内容をターミナルで利用できますが、WindowsのWSL2で同じようなことはできませんか
いいね。しかし、clip.exeはいいがペーストのほうはコマンドが長すぎる。
最高だ。完璧に

まちがって途中で送信してしまった

それでは、この素晴らしい方法を、いつでも思い出して使えるように、あるいは他の人もできるように、ブログ記事としてまとめてくれ。
fishだとどうなる？

今回は記事の方もあまり手直ししていない。

WordPressのエディタ選択: Gutenbergとクラシックエディタの存在理由と選択ガイド

Fri, 30 Jun 2023 00:45:50 +0900

これは私がクラシックエディタの存在意義についてChatGPT-4に書かせたものである。私自身は複数のブログを運営しており、Gutenbergをメインにしているものもあれば、クラシックエディタをメインにしているものもある。どちらにも良いところと悪いところがあるわけだが、基本的には新しいエディタであるGutenbergが推奨される。というか、Gutenbergが出てもう何年もたっているのに、未だにクラシックエディタは健在である。それはいったいぜんたいどういうことだ、ということについての記事である。

はじめに

WordPressユーザーにとって、記事やページの作成と編集は日々の重要なタスクの一つです。そのため、使用するエディタの選択は、作業の効率性、使いやすさ、そして最終的なコンテンツの品質に大きな影響を与えます。WordPressでは、現在、二つの主要なエディターが提供されています: Gutenbergとクラシックエディタ。しかし、これらの違いとどちらを選ぶべきかは一見すると明確ではありません。ここでは、両者の特性を詳しく見ていき、どちらのエディタがあなたに適しているかを判断するためのガイドを提供します。

Gutenbergとクラシックエディタの違い

まず最初に、それぞれのエディタの特性と機能を理解することが重要です。

Gutenbergは、ブロックベースのエディタで、視覚的なレイアウトとデザインに重点を置いています。それは特に、画像、ビデオ、カラムレイアウトなどを頻繁に使用するユーザーにとって有用です。視覚的なエディタとして、ユーザーは自由にブロックを移動、編集、または削除することができ、より直感的なビジュアル編集体験を提供します。

一方、クラシックエディタはより伝統的なWordPressエディタで、テキストエディタと視覚エディタの間で切り替える選択肢があります。これはテキストベースのコンテンツとHTMLコードを直接編集する能力を必要とする人々にとっては便利な機能かもしれません。

なぜクラシックエディタは依然として存在しているのか

それぞれのエディタには独自の利点があり、WordPressユーザーの間でそれぞれ異なるニーズを満たしています。Gutenbergは多くの点で魅力的なエディタですが、すべてのユーザーや状況に対して最適とは限りません。その一部を以下に挙げます。

テキストヘビーなブログ

Gutenbergは視覚的な要素とレイアウトが多いサイトに最適化されています。しかし、主にテキストベースのコンテンツを提供するブログや、コードスニペットや引用などの特定のテキスト要素を頻繁に使用するウェブサイトでは、クラシックエディタの方がより直感的で使いやすい場合があります。

高度なカスタマイゼーションの必要性

Gutenbergは便利なブロックを提供していますが、それらのブロックのカスタマイゼーションは限定的です。HTMLやCSSのようなウェブ言語に精通していて、独自のカスタマイゼーションを高度に適用したいユーザーにとっては、クラシックエディタの方が直接的なコード編集の能力を提供するため、より魅力的な選択肢となるかもしれません。

特定のプラグインやテーマの依存

一部のプラグインやテーマは、Gutenbergではなくクラシックエディタに最適化されているか、または両方をサポートしていません。したがって、これらのプラグインやテーマに依存している場合、Gutenbergの使用は制限される可能性があります。

ただし、古いプラグインやテーマには、セキュリティなどの観点で別の問題を抱えていることにも留意すべきです。

学習曲線

最後に、長年にわたりWordPressを使用してきたユーザーの中には、クラシックエディタの使いやすさと見覚えのあるインターフェースのほうが好ましいを感じられる人もいるでしょう。新しいシステムを学ぶことなく、すぐに編集作業を開始できることは、継続的にコンテンツを提供するために重要な要素です。

新規参加者にとって、なぜGutenbergがおすすめなのか

これらの理由にもかかわらず、新規のWordPressユーザーに対しては、まずGutenbergを試すことをお勧めします。その理由は、Gutenbergが現在のデフォルトのエディタであり、今後のアップデートと新機能のサポートが続くと考えられるからです。

GutenbergはWordPressの未来のデザインと機能の方向性を示しています。ブロックベースの設計は、編集体験をより直感的で視覚的にするだけでなく、柔軟性と拡張性も提供します。ユーザーは個々のブロックを使ってページを自由に設計し、各ブロックを個別にカスタマイズすることができます。

さらに、新機能や改善はまずGutenbergに導入され、新しいテーマやプラグインはGutenbergとの互換性を保証する傾向があります。これは、Gutenbergを学ぶことが、最新のWordPress機能を活用するための重要なステップであることを示しています。

最終的な選択はユーザーのニーズによる

最終的には、どのエディタを選ぶべきかは、その人が何を求めているか、どのようなスキルや経験を持っているかによります。したがって、最適なエディタを見つけるためには、両方のエディタを試し、自分のニーズと作業フローに最も適しているものを選ぶことをお勧めします。

しかし、今後のことを考えると、新規のWordPressユーザーは、まずGutenbergを試すことを強くお勧めします。現在のデフォルトのエディタとして、そしてWordPressの未来のデザインと機能の方向性を示しているためです。クラシックエディタはまだ有効な選択肢であり続けますが、新しいユーザーはGutenbergに触れ、その機能と可能性を試すことで、最新のWordPress機能を最大限に活用するための基盤を築くことができます。

寸評

僕はクラシックエディタとGutenbergの両方を使っている。このChatGPT-4の回答は、概ね悪くないものだと思う（まぁそのように誘導したとも言えるが…）。

以下のような質問をした。

WordPressのGutenbergはクラシックエディタと比べた時、すべての人にとって推奨されるエディタだと言えるか。
シンプルな編集体験を求めるのは、具体的にどんな人か
私自身、Gutenbergをメインで使っているブログとクラシックエディタをメインで使っているブログに分かれている。テキストベースのブログでクラシックエディタを今も使っており、実際、機能的にもクラシックエディタのほうが優れていると感じることが多い。Gutenbergではタブキーで箇条書きのインデントを下げるといった、通常テキストエディタに期待されるような機能もなかったりする。 2つの形式をサポートするのはWordPressにとっても負荷が大きいと思うが、実際的に両方に向き不向きがあると感じる。Gutenbergに統一されることはあるのだろうか。
これからWordPressを始めようという人に、あえてクラシックエディタを勧める理由はあるだろうか。それとも、たとえテキストベースのブログであったとしても、今後のことを考えると、総合的にGutenbergを勧めるべきか。
ここまでの話を、長くなってもよいのでしっかりとした記事としてまとめてください。特に、今でもクラシックエディタがなくならない理由には必ず触れてください。そのうえでなお、新規参加者はまずGutenbergに触れたほうがよいのは何故かについても書いてください。

ポイントとして、最初の質問で「すべての」という修飾を入れた。普通に聞けばChatGPT-4がGutenbergを勧めるのは明らかだったからだ。しかし、ChatGPTは「すべて」について語ることを避ける。そこで、「すべての人に勧められるか」を聞いて、勧められないパターンについて言及させた感じだ。

まぁ、僕自身もこれから始める人がわざわざクラシックエディタから選ぶ必要はないかなと思う。とはいえ、クラシックエディタで既にサイトを運営していてかつ、テキスト主体のブログの人が、あえてGutenbergに乗り換える理由も薄いだろう。

CLI・シェル環境 on AIによる技術記事 備忘録

EmacsでC-h（ヘルプ）を誤打したときに画面を元の状態へ戻す手順

キー入力待ちの状態から中断する

ヘルプ画面が表示された後に元の配置へ戻す

状態の識別と混乱を防ぐ要点

rsyncで「IO error encountered — skipping file deletion」が発生した原因と対処法

エラーの発生状況と原因

対処法：DBデータディレクトリの除外

修正後の動作確認

Emacsを常にターミナル内（-nw）で起動させる設定とsudo実行時の対策

常にターミナル内でEmacsを起動するエイリアス設定

sudo実行時にエイリアスを展開させる工夫

安全に管理者権限で編集するsudoeditの活用

macOS 14.8.3におけるスクリーンショット保存先とファイル形式のJPG変更手順

環境

スクリーンショットアプリによる直感的な保存場所の変更

ターミナルを利用したファイル形式のJPG化と詳細設定

Webブラウザでシェルにアクセスする Shell In A Box のセットアップ備忘録

目的と再現環境

前提となる再現環境

Shell In A Boxのインストールと基本的な起動

LAN内アクセスを可能にする設定と手順

PC起動時の自動起動設定

bashでターミナル間の履歴を共有する方法

履歴共有の仕組み

実装方法

強制同期が必要な場合（オプション）

動画ダウンロードの定番──yt-dlpという万能ツール

導入という第一歩

基本動作──URLひとつで完結する魔法

音だけを抜き出すという美学

整理整頓という技術

フォーマットを選ぶ自由

プレイリストを一括で手に入れる

結語──コマンドラインに宿る洗練

Linux/WSLでghqをインストールする方法

前提条件

推奨方法：go installで直接インストールする

代替方法：APT経由（非推奨）

ソースからのビルド（特殊用途向け）

まとめ

補足：環境変数設定の確認

第3回 Python補完の実践 ― Emacsに頭脳を宿す

Python用LSPサーバの選択肢

サーバの導入

pylspの場合

pyrightの場合

Emacs側の準備

基本設定例（use-package使用）

動作確認

周辺ツールの統合

自動整形：blacken

構文チェック：flycheck

仮想環境切替：pyvenv

eglot を使う場合

実際の動作の理解

まとめ

終わりに

第2回 EmacsがLSPを話す ― クライアントの世界

EmacsにおけるLSPクライアントの役割

lsp-mode ― 機能主義と総合化の道

eglot ― 簡潔主義とEmacs的統合の道

両者の比較と選択の軸

クライアントとUIの分離 ― Emacs哲学の体現

まとめ

第1回 EmacsでPython補完を考える前に ― LSPとは何か

LSP以前 ― 言語ごとに分裂していた時代

LSPの登場 ― 共通言語の誕生

エディタとサーバの関係

LSPの三層構造

オープンな標準としてのLSP

まとめ

macOS launchctl の bootstrap と bootout コマンドの使い方

bootstrap と bootout の基本

ドメインの種類と意味

system ドメイン

gui/UID ドメイン

user/UID ドメイン

基本的な使い方

システムデーモンの登録と削除

CLI・シェル環境 on AIによる技術記事備忘録

推奨方法：`go install`で直接インストールする

第3回　Python補完の実践 ― Emacsに頭脳を宿す

`eglot` を使う場合

第2回　EmacsがLSPを話す ― クライアントの世界

`lsp-mode` ― 機能主義と総合化の道

`eglot` ― 簡潔主義とEmacs的統合の道

第1回　EmacsでPython補完を考える前に ― LSPとは何か