ls *(アスタリスク)のコマンド展開が実行される条件

Question

あるサーバ(YYY.YYY.YYY.YY)で

ssh [e-mail] ls /tmp/test*.data

と実施するとXXX.XXX.XXX.XXX というサーバには、/tmp/test20200923.dataというファイルが存在するので、
test20200923.data
というデータが取れます。

次に
YYY.YYY.YYY.YYサーバ上に
/tmp/test123.data
というファイルを作成すると、

ssh [e-mail] ls /tmp/test*.data
を実施すると、
ls: /tmp/test123.data にアクセスできません:　そのようなファイルやディレクトリはありません。

というエラーが発生します。

*が、展開されて、
ssh [e-mail] ls /tmp/test123.data
が実行されるため、上記のエラーが発生していると考えていますが、
ローカルに一致するファイル名が存在する場合と存在しない場合で、
*が展開される、されないが変わることに違和感を感じています。

ssh [e-mail] 'ls /tmp/test*.data'
とすることで、問題は回避できるのですが、
*の展開がローカルにファイルがある場合とない場合で挙動が異なる理由について、
ご存知でしたら教えてほしいです。

参考情報
https://qiita.com/emasaka/items/a59335c74220b3641639

Answer 1

ローカルに一致するファイル名が存在する場合と存在しない場合で、
*が展開される、されないが変わることに違和感を感じています。

*の展開がローカルにファイルがある場合とない場合で挙動が異なる理由について、
ご存知でしたら教えてほしいです。

質問文を見る限り挙動は理解されているようで、疑問点について説明出来ているのかどうかわからないのですが…、

「」の展開はローカルのシェルがまず行っており、その際、ローカルに「」で展開出来るファイルがあれば展開された状態の文字列でsshコマンドでリモートに渡され、ローカルで「」で展開できなければ「」のままsshでリモート先に渡されリモート先のシェルでその「*」が展開されるということだと思います。

ssh [e-mail] 'ls /tmp/test*.data'
とすることで、問題は回避できるのですが、

こちらの場合は、ローカルのシェルの「」展開が行われずに「」がそのままsshへ渡るので、ローカル側のファイルの存在の影響を受けません。

今の質問文からはそれ以上の説明は自分には出来ませんが、何が知りたいかさらに掘り下げて補足してもらえば説明出来るかもしれません。

Comments

[toroleaman]

>「*」の展開はローカルのシェルがまず行っており、その際、ローカルに「*」で展開出来るファイルがあれば展開された状態の文字列でsshコマンドでリモートに渡され、ローカルで「*」で展開できなければ「*」のままsshでリモート先に渡されリモート先のシェルでその「*」が展開されるということだと思います。

これが仕様であるというのが、なぜなのか？
*をリモートで展開しないのは、なぜなのか？
というのが、最初の疑問でした。bashを作った人がそのように決めたということであれば、
納得せざるを得ないのですが。。
回答ありがとうございました。

[hidezzz]

> これが仕様であるというのが、なぜなのか？

bashがユーザからコマンドラインで指定されたコマンドを実行するに先立って「*」展開するという単純なルールに従っているだけです。後述しますがそうでないとbashに仕様追加が必要になってしまうからです。

> *をリモートで展開しないのは、なぜなのか？

すべてローカルのファイルシステム上で完結するコマンドについては、bashがローカルファイルシステム上のファイルに基づいて「*」展開するという仕様は合理的なものであると思います。
質問の例ではssh(によるリモートでのコマンド)の実行をしているわけですが、bashは与えられたコマンドがリモートで実行されるかどうかを区別しません。というかbashにとってはsshというコマンドをユーザーの指示されるままに実行しているだけです。
仮に「*」がリモートで展開される場合があるという仕様を実現するためにはbashが実行されるコマンドの性質によって「*」展開すべきかどうかを判断する必要が出てきますが、それは不可能では無いかもしれませんがそこまでやる必要性を感じません。(リモートでの「*」展開が必要なコマンドに対しては「このコマンドはリモートで実行される」属性フラグを付けるとか、bashにリモートで実行されるコマンドのリストを何らかの方法で覚えさせておくとか、になるでしょうか…)

それよりは「*」展開はシェルが行うようにして、そうしてほしくない場合はユーザーが明示的に指定するのが良いやり方だと感じます。(今ある仕様に毒されているだけと言われるかもしれませんが…。)
自分の場合は、
ssh [e-mail] 'ls /tmp/test*.data
sshによるリモート実行する際に自然と上記のような書き方をするようになっています。

Answer 2

理由というか、shやbashの場合、*や?等は、そのディレクトリにマッチするファイルがあれば展開されて、マッチしなければそのまま*や?残されます。

tcshやzshだと、マッチするファイルが無いとエラーになります。
（bashだとオプション設定でエラーになるように変更できます。zshででエラーにしない設定があるかも知れません）

というふうに、シェル開発者の間でも、マッチしないワイルドカードをどうすべきかについては意見が分かれていますね。

shがマッチしない場合にそのまま残す理由については、shの機能が拡充していく際に過去との互換性を保つためだったんだと思います。

Comments

[toroleaman]

なるほどです。tcshやzshで挙動が異なるあたり、
開発者でも悩んで決まった仕様なのだと想像できます。

回答ありがとうございました。

Answer 3

*の展開がローカルにファイルがある場合とない場合で挙動が異なる理由について、...

マッチするファイル名が見つかるかどうか、ですね。

man bash

パス名展開
-f オプションが指定されていなければ、単語分割を行った後に bash はそれぞれの単語が *, ?, [ を含んでいるかどうか調べます。 これらの文字のいずれかが見つかると、その単語は パターン とみなされ、 パターンにマッチするファイル名を アルファベット順にソートしたリストに置換されます。 マッチするファイル名が見つからず、かつシェルのオプション nullglob が無効ならば、その単語は変更されずにそのまま残ります。

Comments

[toroleaman]

回答ありがとうございます。nullglobで、パス名展開に失敗した場合の挙動を変更できるのですね。

Answer 4

なんか勘違いしていませんか。

ssh [e-mail] ls /tmp/test*.data
「/tmp/test20200923.data」というファイルが存在する場合

も、二回目の
ssh [e-mail] ls /tmp/test*.data
「/tmp/test123.data」と言うファイルが存在しない（ローカルにしかない）

も、同じようにリモートサーバの/tmpの情報を取得しています。

ローカルにいくらファイルを作成しても、
リモートの状態は変わりませんよ。

＞＞ローカルに一致するファイル名が存在する場合と存在しない場合で、
＞＞*が展開される、されない

は変わりません。単にリモートにそれに該当する
ファイルが有るか無いかだけです。

Comments

[toroleaman]

これが違うですよ。。。
*が展開されてしまうんです。

[hana_yama_san]

失礼しました。
質問文をよく読んでいなかったですね。
sshのコマンド実行はクオートするものと決め付けて
生活していたもので・・・