bash

UNIXシステムの既存機構を活用したミニマルな通知システムの実装例です。 複数の通知元から任意の通知メッセージを受信し、それらをシェルプロンプトに表示できます。 個人利用の環境（趣味用途や開発用途など）への導入を想定しています。

• コードの短さと処理の軽さが特徴です。
• カスタマイズや環境依存部分の調整を前提としています。利用前にコードに一通り目を通してください。
• 通知先（メッセージ受信側）のコードはBash用です。Bash以外のシェルではそのシェルに合わせた変更が必要です。

設計思想

本システムの設計の核は「付け加えるものは最小限に、UNIXそのままの仕様と挙動を活かす」ことです。

• 本システムは、「ファイル」と「シェルのプロンプト更新」という既存機構のみを用いた通知機構です。そのため、常駐プロセスは不要です。
  • 通知状態を「ファイルの存在」に還元することで、通知の生成・可視化・永続化・消費を、仕様と実装の両面で、OSに委ねます。そのため、同期や状態管理のための複雑な機構は不要です。
  • プロンプト表示時にのみ通知を消費します。そのため、常時監視のためのリソース消費と実装複雑性は不要です。

以上の基本思想に合わせ、厳密な順序保証やマルチユーザ間の公平性よりも、単純性・可搬性・挙動の自明さを優先する設計とします。

システム仕様（外部仕様）

1. システム概要

ファイルシステムを介してユーザのシェル（Bash）のプロンプトに通知を表示する軽量な仕組みです。例えば、systemdユニットの実行失敗通知に利用できます。

2. 基本仕様

• 通知メッセージ: 通知したい内容そのものを「ファイル名」とします（ファイルの中身は空で構いません）。
• 通信路: /var/lib/notify_inbox/ ディレクトリを使用します。
• 通知発行: 前述のディレクトリに、touchコマンドなどで、メッセージをファイル名とした空ファイルを作成します。
• 永続性: メモリ（RAMディスク）ではなくディスクを使用するため、OS再起動後も通知は保持されます。
• 表示タイミング: シェルプロンプトがユーザに表示される直前のタイミングでチェックされ、プロンプトと同時に表示されます。
• ライフサイクル: 通知は一度だけ表示され、表示直後に自動削除されます。
• 重複排除: 同じファイル名（同じメッセージ）はシステム上に1つしか存在できません。
• 順序: 複数のメッセージがあるときは、アルファベット順（ロケール依存の辞書順）で表示されます。

3. 注意事項・制約

• ファイル名（通知メッセージ）の制限:
  • メッセージの最大長はファイルシステムのファイル名の最大長（最大バイト数）に依存します。
  • /（スラッシュ）はファイル名に使えません。
  • .（ドット）から始まるファイル名については、通知と削除が行われるかどうかは、Bashのdotglobの設定に依存します。
  • ファイル名にスペースを含めても動作しますが、見やすさのため _ や - の使用を推奨します。
• 特殊文字やマルチバイト文字を含む通知メッセージ:
  • 通知メッセージ（ファイル名）に記号やスペースを含む場合、適切なエスケープやクォートが必要です。通知元での記述仕様を確認してください。
  • 通知メッセージに非ASCII文字を使うときには、systemdのユニットファイルなど、メッセージの文字列を含むファイルの文字コードとUNIXシステムのロケールが整合するようにしてください。
  • 通知元と通知先でロケール（言語設定）が異なるせいで文字化けが発生するなど、ロケールによる不具合が起こる場合があります。必要に応じて、メッセージの文字種を問題が起きない文字（ASCII文字など）に限ったり、適切にロケールを設定したり（例: env LC_ALL=ja_JP.UTF-8 touch "/var/lib/notify_inbox/01_メッセージ"）してください。
• 複数のユーザで利用している環境での利用:
  • 通知ディレクトリは全ユーザ読み書き可能（0777）です。システム上の全ユーザが通知を見ることができます。
  • マルチユーザ環境の場合、このプロンプト表示システムを導入したユーザの中で「最初にシェルを操作した人」だけが通知を受け取り、ファイルが消去されます（早い者勝ち）。
• セキュリティ:
  • この簡易システムは詳細なセキュリティの検討を経たものではありません。セキュリティの確保が必要な環境では使用しないでください。

実装コード一式

Step 1. 共有ディレクトリの設定（管理者権限）

systemdの機能を使って、起動時にディレクトリを作成し、適切な権限を与えます。

作成ファイル: /etc/tmpfiles.d/notify_inbox.conf

# Type Path                   Mode UID  GID  Age Argument
d      /var/lib/notify_inbox  0777 root root -   -

• 解説: 0777 に設定し、スティッキービット（t）を意図的に付けていません。これにより、rootが作成した通知ファイルを一般ユーザが削除できるようになります。

設定の反映:

sudo systemd-tmpfiles --create

Step 2. 通知先（受信側）の設定（一般ユーザ）

ユーザの .bashrc に、プロンプト表示時に通知をチェックし、 通知があれば表示する処理を追加します。

編集ファイル: ~/.bashrc

# --- 簡易通知システム 受信関数 ---
notify_in_prompt() {
    NOTIFY_PS1_PREFIX=''
    local inbox_dir="/var/lib/notify_inbox"

    # 1. ファイル一覧を取得
    local files=("$inbox_dir"/*)

    # 2. ディレクトリがない、または、ディレクトリがあっても
    #    ファイルがない場合は以後の処理をしない (このことが軽量化のポイント)
    # 該当する場合は、nullglobがオンでもオフでも早期リターンする
    # こちらの方が、shopt -p nullglobで前の状態を保存してevalで戻すよりも高速

    # nullglobがオンで、マッチするファイルがない場合、
    # 配列の要素数が0になるのでここでreturnして以後の処理はしない。
    if [ ${#files[@]} -eq 0 ]; then
        return
    fi

    # nullglobがオフで、マッチするファイルがない場合、
    # 配列の先頭要素に パターン文字列 "/var/lib/notify_inbox/*" がそのまま入る
    # 「そのパスにファイルが存在しない」かつ「文字列がパターンと一致する」ならファイル無し
    if [ ! -e "${files[0]}" ] && [ "${files[0]}" = "$inbox_dir/*" ]; then
        return
    fi    

    # パスを取り除き、ファイル名のみの配列を作成
    local names=("${files[@]##*/}")

    # 複数の通知がある場合、スペース区切りで連結される
    #
    # 区切りをスペースから変更したい場合は、デフォルトの IFS を、
    # local 変数として上書きすることで、結合文字を変更できる
    # ※ "${names[*]}" の展開時に、IFSの先頭の1文字が使われる
    #
    # 例1: 縦棒(パイプ)区切りにしたい場合 "Msg1|Msg2"
    # local IFS='|'
    # 例2: 区切り文字なしにしたい場合 "Msg1Msg2"
    # local IFS=''
    #
    # ここではスペース区切りで連結した上で
    #「赤背景・白文字」で目立たせて表示する
    # 色コード(\e[...m)は \001 と \002 で必ず囲む。
    # （\001 及び \002 は Readline に「非表示文字列」を知らせるマーカー）
    # これを忘れると、Bashがプロンプトの長さを計算できず、
    # 長いコマンド入力時や履歴を遡った時に表示崩れが発生する。
    # またANSI-C Quoting（シングルクォーテーション囲みの前に$を付ける）で
    # バックスラッシュエスケープを解釈させ実バイトを埋め込む。
    NOTIFY_PS1_PREFIX=$'\001\e[41;37m\002 '"${names[*]}"$' \001\e[0m\002'
    # シンプルにそのまま表示する場合
    # NOTIFY_PS1_PREFIX="${names[*]}"

    # 3. ファイルを一括削除 (表示済みとして消費)
    # ユーザがrmをエイリアスで定義していても、そのエイリアスは無視
    # -- を挟むことで - で始まるファイル名があったとしてもオプションとして解釈されない
    command rm -f -- "${files[@]}"
}

# 1. PROMPT_COMMAND に登録
# プロンプトが表示される「直前」に毎回実行され、変数 NOTIFY_PS1_PREFIX を更新する
#
# 注意: コードの複雑化を避け、可読性を優先するため、.bashrcの複数回読み込み（リロード）に対する
# ガード処理は省略しています。必要があれば環境に合わせて書き換えてください。
if [ -z ${PROMPT_COMMAND:+x} ]; then
    # PROMPT_COMMANDが定義されていない、または、空文字列のときは単純にセット
    PROMPT_COMMAND="notify_in_prompt"
elif declare -p PROMPT_COMMAND 2>/dev/null | grep -q '^declare \-[a-z]*a'; then
    # PROMPT_COMMANDが配列の時は先頭要素として追加
    PROMPT_COMMAND=("notify_in_prompt" "${PROMPT_COMMAND[@]}")
else
    # PROMPT_COMMANDが空でない文字列の時はその前に追加
    PROMPT_COMMAND="notify_in_prompt; $PROMPT_COMMAND"
fi

# 2. PS1 の先頭に変数を埋め込み
# 必ず 'シングルクォート' で囲む。
# ダブルクォートだと「読み込み時」に展開されてしまうが、
# シングルクォートなら「表示のたび」にその時点の変数が参照される。
PS1='${NOTIFY_PS1_PREFIX}'"$PS1"

設定の反映:

exec $SHELL -l

Step 3. 通知元（送信側）の設定例

systemdユニットファイルに通知コマンドを仕込みます。

例: バックアップサービスのユニット (/etc/systemd/system/backup.service)

[Unit]
Description=Daily Backup Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup_script.sh

# --- 通知機能の追加 ---
# 処理が失敗した場合のみ通知ファイルを置く
# ファイル名: "[!Backup_Failed]"
ExecStopPost=/bin/bash -c 'if [ "$EXIT_STATUS" != "0" ]; then touch "/var/lib/notify_inbox/[!Backup_Failed]"; fi'

解説:

• ExecStopPost: サービス終了時（成功・失敗問わず）に実行されます。
• $EXIT_STATUS: systemdが終了時に設定する環境変数の一つです。0 以外ならエラーと判断しています。確実な失敗通知には OnFailure= の利用も検討してください。
• touch "...": ファイルを作るだけです。このファイル名がそのまま通知メッセージになります。

Step 4. 動作確認

実際に通知が表示されるかテストします。

1. テスト用通知を作成（手動）:

   # 任意の場所で実行
   touch "/var/lib/notify_inbox/[!Test_Message]"
   

2. プロンプトを表示（Enterキーを押す）: ターミナルで Enter を押したタイミングで、プロンプトの前に以下のように表示されます。

   [!Test_Message] user@hostname:~$

3. 消去確認: もう一度 Enter を押し、通知が消えることを確認します。

4. systemd経由のテスト（失敗シミュレーション）: ExecStart=/bin/false と書いたダミーのユニットを作成して systemctl start し、プロンプトにエラーが出るか確認してください。

よく使うコマンドはaliasやシェルスクリプトの形で保存し再利用するのが王道かと思いますが、
「#」」を使ったコメントをコマンドの後ろに付けることで、コマンドを手軽に再利用する方法もあります。

例えば、以下のようにコマンドの後ろにコメントを付けておきます。

cd ~/foo/bar/baz #cfbb

すると今後は、このコマンドをそのまま再実行したいときには、C-rのあと#cfbbと入力してEnterで再実行できます。

ちなみに、コマンド全体が同じではなく、引数などの部分をそのときそのときで変えたい場合には、 先ほどの操作から続けて、C-eで行末に移動し、M-bとM-fで単語単位で移動して、M-dかC-wで単語単位で削除して、新たな内容を入力、といった形で対応することも出来はします。 もちろん、こういった操作がややこしい感じになるなら、素直にaliasかシェルスクリプトの活用の方が良いのではないかと思いますので、このコメントを利用した方法が活躍する場面は、全く同じコマンドを繰り返す場合だと思います。

同じコマンドをパパッと使い回す方法として便利なときがあるかもしれませんね。

それから、.bash_historyを後から見たり検索したりするなら、こういうコメントが残っていると実は便利なのかも。

C-u、つまり、Ctrlキーを押しながらuキーを押す操作は、Bashやその背後にあるreadlineライブラリで、「カーソルから行頭までの切り取り」に割り当てられている。そのせいなのか、Unixシェルでパスワード入力中に失敗したときに、C-uを押してからパスワードを正しく再入力すれば、処理が通ることが多い、という小ネタです。

参考

unix-line-discard (C-u) ポイントから行頭までをキルします。 キルされたテキストはキルリング (kill-ring) に入ります。

https://ja.manpages.org/bash より

unix-line-discard (C-u) Kill backward from point to the beginning of the line. The killed text is saved on the kill-ring.

https://manpages.org/readline/3 より