Ubuntu で Shell スクリプトをダブルクリック実行する：権限・ファイルマネージャー・安全なランチャー

Ubuntu で「スクリプトをダブルクリックする」動作には、少なくとも四つの層があります。スクリプト本体とインタプリタ、Unix の実行権限、マウントオプション、そしてファイルマネージャーまたはデスクトップの起動ポリシーです。現在の GNOME Files にも実行可能テキストを実行・表示・毎回確認する選択肢はありますが、Ubuntu のリリース、デスクトップ、ファイルマネージャーによってメニューと既定動作は異なります。診断しやすい基準は常に端末です。安定した GUI 入口が本当に必要な場合だけ、レビュー済みのローカルスクリプト用に標準デスクトップランチャーを作成します。

この保守版は 2026 年に書き直しました。2014 年の原文は旧 Nautilus の設定パスとスクリーンショット 2 枚だけです。完全な本文を末尾の不活性アーカイブに保存していますが、現在の UI を保証するものではありません。

1. 実行すべきスクリプトか先に判断する

Shell スクリプトは読み取り専用文書ではなくプログラムです。ダブルクリックする前に、出所、目的、想定する入出力、ネットワークアクセス、書き込み先、ロールバックを確認します。ダウンロード、チャット添付、メール、共有ドライブのスクリプトは、普通のアイコンに見えるという理由だけで実行してはいけません。

まず読み取り専用で調べます。パスはプレースホルダーです。

file -- script.sh
stat -- script.sh
sed -n '1,80p' -- script.sh
sed -n '1l' -- script.sh
sha256sum -- script.sh

先頭 80 行だけでなく、ファイル全体を読みます。ハッシュが識別するのはバイトです。信頼できる配布元が別経路で公開した値と比較して初めて、出所の証拠になります。curl ... | sh を使わず、未知のスクリプトを試すために sudo へ渡さないでください。

2. インタプリタ、shebang、改行コード

スクリプトを直接実行すると、1 行目の shebang がインタプリタを選びます。実際の言語に合わせてください。Bash スクリプトなら次のように始められます。

#!/usr/bin/env bash
set -u
printf 'script=%sn' "$0"
printf 'working_directory=%sn' "$PWD"
printf 'argument_count=%sn' "$#"

#!/bin/sh は、対象システムの sh に本当に適合するスクリプトだけに使います。/usr/bin/env bash は起動環境の PATH から Bash を探すため、インストール位置が違う環境では便利ですが、PATH が信頼できる必要があります。固定された管理対象ホストでは、配備ポリシーに従って絶対インタプリタパスを使えます。

bad interpreter の後ろに ^M が出る場合、CRLF 改行がよくある原因です。file と sed -n '1l' で確認し、信頼できるエディタでコピーを変換します。全内容を読む前に多数のファイルを一括変換しないでください。bash script.sh は shebang を迂回するため、Bash だと確認済みのファイルの診断にだけ使えます。直接実行の設定が正しい証明にはなりません。

3. 所有者にだけ実行権限を付ける

レビュー済みスクリプトを、他ユーザーが書き換えられないローカルの管理下パス、たとえば $HOME/.local/bin/double-click-demo に保存します。その後、所有者の実行ビットだけを追加します。

install -d -m 700 -- "$HOME/.local/bin"
chmod u+x -- "$HOME/.local/bin/double-click-demo"
ls -l -- "$HOME/.local/bin/double-click-demo"
"$HOME/.local/bin/double-click-demo"
printf 'exit_status=%sn' "$?"

chmod 777 を使わず、自分の実行ビットを追加するだけのために sudo を使わないでください。ファイルの x ビットだけでは不十分です。親ディレクトリには検索権限が必要で、ファイルシステムが noexec でマウントされている場合や、ACL・セキュリティポリシーが拒否する場合もあります。FAT、NTFS、ネットワーク共有、アーカイブでは権限の意味が異なることがあります。権限を繰り返し緩めるより、ローカルのネイティブファイルシステムへインストールする方が制御しやすくなります。

まだ実行ビットを付けていないレビュー済み Bash ファイルを試すだけなら、インタプリタを明示できます。

bash --noprofile --norc -- "$HOME/.local/bin/double-click-demo"

これはユーザーの Bash 起動ファイルを避けますが、スクリプトのファイル・ネットワーク・プロセス権限を隔離しません。サンドボックスではありません。

4. 端末実行を診断の基準にする

端末から実行すれば、標準出力、標準エラー、終了ステータスを残せます。スクリプトが実際に想定する作業ディレクトリへ移動するか、スクリプト側で絶対パスを使います。ダブルクリック時の PWD が対話端末と同じだと仮定しないでください。

ファイルを変更するスクリプトには、先に --dry-run または読み取り専用モードを用意し、新しいテストディレクトリだけへ出力します。演習、バックアップ、明確なロールバックがなければ、まだ実行しません。パスワード、管理者権限、ディスク分割、アカウント、ネットワーク規則、または本番データを扱うスクリプトは、確認なしのダブルクリック入口に適しません。

5. GNOME Files の直接ダブルクリック設定

現在の GNOME ヘルプにも、実行可能テキストファイルを「開いたとき実行」「開いたとき表示」「毎回確認」する三つの方針が記載されています。さらに Properties → Permissions でプログラムとして実行可能にする必要があります。インストール済み Ubuntu では Files → Preferences → General/Behavior に置かれることも、別のファイルマネージャーでその選択肢自体がないこともあります。

選択肢があるなら、実行前に確認できる Ask each time を優先します。直接実行では作業ディレクトリ、環境、エラー出力が見えにくく、端末プログラムのウィンドウがすぐ消えることがあります。選択肢がない場合、スクリーンショットを再現するために隠し設定を変更したり旧ファイルマネージャーを入れたりせず、端末または次節の標準ランチャーを使います。

6. レビュー済みスクリプト用のアプリランチャーを作る

再現可能な GUI 入口には、他ユーザーが変更できない固定パスにスクリプトを置き、Desktop Entry 仕様に従って $HOME/.local/share/applications/lazying-shell-demo.desktop を作ります。三つの USERNAME を実際のローカルユーザー名へ置き換えてください。Exec は $HOME を展開せず、shell のようにパイプ、リダイレクト、&& を解釈しません。

[Desktop Entry]
Type=Application
Name=Shell Script Demo
Comment=Run the reviewed local demo in a terminal
TryExec=/home/USERNAME/.local/bin/double-click-demo
Exec=/home/USERNAME/.local/bin/double-click-demo
Path=/home/USERNAME
Terminal=true
Icon=utilities-terminal

TryExec により、対象が存在しないか実行不能なときデスクトップは入口を非表示または無視できます。Path は作業ディレクトリを固定し、Terminal=true は端末 UI を残します。空白を含むパスは Desktop Entry の規則で引用する必要があり、任意の shell エスケープは使えません。空白のない管理下パスの方が簡単です。

テキストエディタで保存した後、Exec、TryExec、Path を 1 行ずつ確認します。desktop-file-utils がインストール済みなら、読み取り専用で検証し、アプリメニューからテストできます。

desktop-file-validate -- "$HOME/.local/share/applications/lazying-shell-demo.desktop"
gtk-launch lazying-shell-demo

desktop-file-validate が何も出さない場合、通常は構文に合格したという意味で、スクリプトの安全性を証明しません。GNOME Shell に新しいアプリが表示されるまで再索引や再ログインが必要なことがあります。ランチャーをデスクトップへコピーすると、デスクトップ拡張機能が Allow Launching を求める場合もあります。自分が今レビューしたファイルだけに許可し、メタデータコマンドでダウンロードした desktop ファイルを一括信頼しないでください。

7. GUI と端末の環境が違う理由

アプリランチャーは通常、対話 shell の alias、関数、すべての起動ファイルを読みません。PATH、locale、プロキシ、表示セッション、資格情報エージェントも異なる場合があります。スクリプトでは次を守ります。

• 外部ツールには検証済みの絶対パスを使うか、小さな信頼済み PATH を設定する。
• 起動位置をスクリプトディレクトリとみなさず、作業ディレクトリを明示する。
• 空白やワイルドカード文字を含む可能性がある引数をすべて引用する。
• 想定内の失敗を端末または管理下ログへ書き、非ゼロ状態を返す。
• 秘密をスクリプト、ランチャー、コマンドライン引数、公開ログへ書かない。

Exec に未信頼テキストを連結せず、shell 構文を得るためだけにユーザー入力を sh -c で包まないでください。ファイルを引数として渡す必要がある場合、Desktop Entry のフィールドコード規則を読み、スクリプト内で個数、種類、所有者、許可ディレクトリを検証します。

8. 症状ごとの証拠表

症状	最初に調べる項目	してはいけないこと
ダブルクリックするとエディタが開く	ファイルマネージャー方針、実行ビット、現在のデスクトップ版	2014 年の画像が現在のメニューと同じだと仮定しない
Permission denied	ファイル/親権限、ACL、noexec、ファイルシステム種別	chmod 777 や root で境界を迂回しない
bad interpreter	shebang パス、CRLF、インタプリタの有無	無条件に Bash へ変えて言語差を隠さない
端末では動くが GUI では失敗	PWD、PATH、locale、セッションバス、表示環境	対話環境全体をランチャーへコピーしない
ウィンドウがすぐ閉じる	Terminal=true、端末での直接実行、終了状態と stderr	無限 sleep を加えてエラーを隠さない
アプリ入口が表示されない	Desktop Entry 構文、ファイル名/アプリ ID、セッション索引	すべての .desktop を一括信頼しない
外付けドライブは読めるが実行不能	マウントオプション、権限モデル、組織ポリシー	信頼境界を無視して実行可能に再マウントしない

読み取り専用診断は次から始めます。出力にはユーザー名やパスが含まれ得るため、公開前にマスキングしてください。

namei -l -- "$HOME/.local/bin/double-click-demo"
findmnt -T -- "$HOME/.local/bin/double-click-demo"
head -n 1 -- "$HOME/.local/bin/double-click-demo"
journalctl --user -b --since "10 min ago" --no-pager

最小構成のシステムには namei、findmnt、ユーザージャーナルがないことがあります。コマンドがないこと自体が環境の証拠です。チェックリストをすべて緑にするためだけに任意のパッケージを入れないでください。

9. 可逆的な無効化とロールバック

先にランチャーを無効化し、次にスクリプトの実行ビットを外します。ファイル削除は不要です。

ScriptPath="$HOME/.local/bin/double-click-demo"
LauncherPath="$HOME/.local/share/applications/lazying-shell-demo.desktop"
test ! -e "$LauncherPath.disabled" || exit 1
mv -- "$LauncherPath" "$LauncherPath.disabled"
chmod u-x -- "$ScriptPath"

アプリメニュー更新または再ログイン後、入口が消えたことを確認します。スクリプトがすでにデータ、アカウント、システム設定を変更した場合、実行ビットを外しても影響は戻りません。実行前に定義・テストしたアプリケーションレベルの復旧計画を使います。

10. 停止条件

• スクリプトの出所、完全な内容、インタプリタ、想定副作用を説明できない。
• 承認とロールバックなしに sudo、パスワード、トークン、セキュリティ制御の無効化、本番データ変更を要求する。
• 権限の全体緩和、外付けドライブの実行許可、ランチャー一括信頼をしなければ動かない。
• 端末実行は失敗するのに GUI がエラーを隠す。先に端末経路を修正する。
• 他ユーザーがファイルを置換できる、同期/共有場所にある、または起動中に置換され得る。
• デスクトップ、ファイルマネージャー、組織ポリシーが本文と異なり、現在の公式文書がその方法を裏付けない。

この場合はスクリプト保守者またはシステム管理者へエスカレーションします。便利な入口がスクリプト自体の権限や信頼境界を広げてはいけません。

11. 公式資料

• GNOME：ファイルマネージャーの動作設定
• GNOME：ファイル権限の設定
• GNU Bash：Shell Scripts
• freedesktop.org：Desktop Entry Specification
• freedesktop.org：XDG Base Directory Specification
• POSIX.1-2024：chmod

資料は 2026-09-01 に確認しました。Ubuntu、GNOME Files、デスクトップ拡張、組織ポリシーは変わります。実行前にインストール済みバージョンのヘルプと現在の公式文書を基準にしてください。

12. 2014 年の原文アーカイブ（出所確認専用）

次のフェンスには source_export の可視本文全体を一字一句そのまま保存しています。末尾空白の正規化、リンク削除、私的値のマスキングはいずれも不要でした。旧 Nautilus のメニューとスクリーンショットは不活性な歴史的証拠であり、現在の UI を保証しません。

~~~~markdown

打开一个文件夹，单击左上角的Home Folder（主目录）－>单击Preferences(首选项)

%%LAZYBLOG_INLINE_0%%

按照下图所示设置：

%%LAZYBLOG_INLINE_0%%
~~~~