シェルスクリプト総合その29

**デフォルトの名無しさん** · 2018/09/21(金) 23:34:47.98

シェルスクリプトに関する総合スレッドです。

全般
・荒しは無視しましょう。
・丁寧な姿勢を心掛けましょう。
・ネチケット（死語）を意識しましょう。

前スレ:
シェルスクリプト総合その28
http://mevius.5ch.net/test/read.cgi/tech/1532397676/

**デフォルトの名無しさん** · 2019/04/11(木) 17:03:23.97

exec 3>&1; exec >&-; exec >&3
たまにこんなのを見ますがこれはどんな時に使うんです？
ファイルディスクリプタ自体は理解しましたがfdの複製や切り替える目的が分からなくて
cmd 2>err.txtは意識せず使えてますが

**デフォルトの名無しさん** · 2019/04/11(木) 17:46:50.14

>>252
不勉強なんで「3」ってfdは知らないんだけど、「>&」ってリダイレクトを
使うと書き込みじゃなくて切替になるんだけど、これを使うとエラー
出力を標準出力に切り替えて標準出力で両方の出力を得たりする
ことができるです

「Command > FileName 2>&1」ってするとエラー出力の内容が標準
出力になってFileNameに両方の内容が書き込まれる
逆に「Command 2> FileName 1>&2」ってすると標準出力がエラー
出力になっるので、エラー出力でFileNameに書き込むことが出来る

で、何に使うのかっていうと、「grep」なんかは検索結果は標準出力に
でるけど「指定されたのはディレクトリだよ」みたいなメッセージは
エラー出力に出される
両方の出力をみて処理したいとかの時にはこれで切り替えて標準
出力の内容を変数に保存しておいて処理するとかに使うです

例が雑でわかりにくいかもだけど、エラーと通常の出力を同じ出力で
使う方法ってことで、あとはスクリプトなんでアイデアしだいなんで

**デフォルトの名無しさん** · 2019/04/11(木) 23:20:48.83

>>252
http://tldp.org/LDP/abs/html/x17974.html

**デフォルトの名無しさん** · 2019/04/12(金) 00:07:43.92

>>252 はリダイレクトを知りたいんじゃなくて、fd=1 を 3 にコピーして 1 をクローズして再度 3 から 1 にコピーする意味
が何なのかを質問しているんだと思う。
結局もとのファイルに繋ぎなおすだけだよね。
一旦クローズするから flush されるとか？ならわかるんだが、実際どうなのかわからん。

**デフォルトの名無しさん** · 2019/04/12(金) 00:45:21.11

ファイルディスクリプタに関しては
逆引き辞書が必要なんだと思う

○○をしたい時 → こうします。っていうやつ

**デフォルトの名無しさん** · 2019/04/12(金) 03:08:23.09

ファイルディスクリプタ(FD) 3番からは、システムが使うけど、ユーザーも使うことができる。
FD0 : 標準入力、FD1 : 標準出力、FD2 : 標準エラー出力

端末に、ls と打つと、
1. シェルが、lsコマンドのプロセスを起動して、それに、FD0～2 を渡す
2. lsプロセスは、FD3 を使って、ファイル一覧を作って、FD1 に出力する

主なFD3 の使用方法は、標準入力を、ファイル・キーボードの2つで、切り替えて使いたい時

標準入力をファイルからにすると、キーボード入力が出来なくなるため、
一旦、標準入力(FD0)をFD3 にして、ファイルから入力して、済んだら元に戻す

こんな事を一々、シェルスクリプトでやるよりも、Ruby でやればよい。
FD何番を使っているとか、意識せずにすむ

**257** · 2019/04/12(金) 04:14:55.73

exec 3<&0 < a.txt # FD3 から入力

while read LINE
do
echo "--- ${LINE} ---"
done

exec 0<&3 3<&- # 標準入力を元に戻し、FD3 を閉じる

# 上のようにも書けるが、下の方が、標準入力のファイルディスクリプタ(FD)0 をいじらないので、安全

exec 3< a.txt

while read LINE 0<&3 # FD3 から入力
do
echo "--- ${LINE} ---"
done

exec 3<&- # 閉じる

「UNIX シェルスクリプト・コマンドブック第2版、山下哲典」の、exec の説明の所に書いてある。
第3版には載っているかどうか、知らないけど

**デフォルトの名無しさん** · 2019/04/12(金) 13:25:25.09

もう少しまともに説明できるやついないのかな・・・

**デフォルトの名無しさん** · 2019/04/12(金) 13:27:28.90

宿題は自分でやろうな

**デフォルトの名無しさん** · 2019/04/12(金) 16:22:09.16

CTRL+Cのトラップについて教えて

以下のスクリプトの時、実行してすぐにCTRL+Cを押すと
#!/bin/sh
set -e
sigint() { echo sigint; }
trap 'sigint' INT
#trap 'echo $?' EXIT
sleep 10

こんな感じでバラバラなんだけどさ

dash・・・トラップできない。終了コード130
（ただしコメントアウトしてるEXITのtrapを有効にするとトラップできる）
bash・・・トラップできる。終了コード130
zsh・・・トラップできる。終了コード130
ksh・・・トラップできない。終了コード130
（コメントアウトしてるEXITのtrapを有効にすると258と表示される。トラップできず）
mksh・・・トラップできる。終了コード0
（コメントアウトしてるEXITのtrapを有効にすると0と表示される。トラップできる。）
posh・・・トラップできない。終了コード130
（ただしコメントアウトしてるEXITのtrapを有効にするとトラップできる）
yash・・・トラップできる。終了コード130
（コメントアウトしてるEXITのtrapを有効にすると386と表示される。トラップできる。）

なんでこうなって、どれが正しい動きで、どれでも同じ動きさせるには、どうすりゃいいの？

**デフォルトの名無しさん** · 2019/04/12(金) 16:46:27.11

宿題は自分でやろうな

**デフォルトの名無しさん** · 2019/04/13(土) 06:04:26.25

Ruby では、カスタムハンドラを定義した場合、終了しない。
デフォルトのままなら、Ctrl+C で終了する

つまり、デフォルトハンドラから、カスタムハンドラへ付け替えたため

sleep 7 #=> ここではデフォルトハンドラだから、Ctrl+C で終了する

previous_handler = Signal.trap( :INT ) do
puts "シグナルハンドラへ入った！"
end

print "previous_handler = "
p previous_handler #=> "DEFAULT"

sleep 7 #=> ここでは、カスタムハンドラへ付け替えたので、終了はしない

**デフォルトの名無しさん** · 2019/04/13(土) 06:40:14.96

それはシェルスクリプトも同じだろうな。上の終了しているのは set -e しているからじゃないのかな
シェルスクリプトは子プロセスを起動していてシグナルを受けるのが子プロセスでが多くタイミング的に～以下省略

**デフォルトの名無しさん** · 2019/04/13(土) 07:34:12.37

> set -e しているからじゃないのかな
それをわかってるから、サンプルコードにも入れてるんだけどねｗ

問題はそこじゃなくて、なんでシェル毎に挙動違うんだよ！？
どれが正しいんだよ！？という話なわけで

**デフォルトの名無しさん** · 2019/04/13(土) 07:57:58.58

CTRL-Cを入力するタイミングが下手すぎるって話だろ
まさか手入力じゃあるまいな？

**デフォルトの名無しさん** · 2019/04/13(土) 08:08:06.94

>>266
手入力しないでやる方法を教えてくれ！

**デフォルトの名無しさん** · 2019/04/13(土) 08:08:38.43

いやkill使うのは知ってる。それをどういう風に使えば、
手入力と全く同じことを再現できるのかという話だ。

**デフォルトの名無しさん** · 2019/04/13(土) 08:12:44.72

2つの端末を使って一方で実行してから
もう一方で（手入力で）実行するっていうのは
結局手入力してるのと変わらないし、

1つのスクリプトでkillすると、
それこそわけわからんことになる。
イベントハンドラ内でkillするか、違う場所でkillするか
シェルによって挙動が違う

**263** · 2019/04/13(土) 08:51:59.71

Ruby では、

previous_handler = Signal.trap( :INT ) do
puts "シグナルハンドラへ入った！"
end

print "previous_handler = "
p previous_handler #=> "DEFAULT"

# 自プロセスへシグナルを送ると、カスタムハンドラが呼ばれるが、終了はしない
Process.kill :INT, Process.pid

Signal.trap( :INT, previous_handler ) # 元のハンドラへ戻す

sleep 7 #=> ここでは、デフォルトハンドラへ戻したので、Ctrl+C で終了する

「改訂2版 Ruby逆引きハンドブック」では、もっとややこしい記述をしてる

シグナルハンドラはグローバルだから、
他のスレッドに変更されないように、Mutex で排他制御してる

**263** · 2019/04/13(土) 09:02:30.89

シングルスレッドでは、sleep 7、としてる間に同時に、

Process.kill :INT, Process.pid
と、自プロセスの命令を実行できない

マルチスレッドなら出来るのだろうが、マルチスレッド・プログラミングはややこしい！

**デフォルトの名無しさん** · 2019/04/13(土) 09:27:42.11

>>271
マルチスレッドのほうが楽だな。

それらをマルチプロセスでやってくれ。
子プロセスは自分で作成したものだけじゃなくて
既存のプログラムも使い、バックグラウンドプロセスも使ってみること

**デフォルトの名無しさん** · 2019/04/13(土) 09:36:25.97

zshの謎な挙動はこれが原因か？
https://fumiyas.github.io/2013/12/05/trap-exit.sh-advent-calendar.html

> でました、zsh の非互換! zsh はシグナルハンドラー※内で終了すると、 EXIT ハンドラーを実行してくれません。酷い。 (※この例では SIGINT のデフォルトのシグナルハンドラー)

> こんな感じで bash, ksh, zsh には微妙な動作の違いがあったりするので、ちょっと変わったことしようとするときは特に注意しましょう。

**デフォルトの名無しさん** · 2019/04/13(土) 09:39:48.45

読みづらいなｗ

$ zsh -c '
atexit(){ echo "Bye!"; };
trap atexit EXIT;
trap "trap - EXIT; atexit; exit -1" TERM;
kill -TERM $$
'

**デフォルトの名無しさん** · 2019/04/13(土) 11:31:16.12

全てのシェルで適切に終了処理をするって難しいな・・・

**263** · 2019/04/13(土) 11:39:28.75

Ruby で、at_exit に、終了処理を書いておけばよい

シェルスクリプトで、書く必要がない

**デフォルトの名無しさん** · 2019/04/13(土) 11:55:58.29

時たま出来てしまうゾンビは何が原因なんだろう？
kill -TERM 0 してるから全部死んでくれるはずなんだが・・・

**デフォルトの名無しさん** · 2019/04/13(土) 11:57:21.41

あ、バックグラウンド処理とかしてる
そしてCTRL-Cで強制終了した時の話
ゾンビだから消せなくて困る

**デフォルトの名無しさん** · 2019/04/13(土) 13:02:33.69

ゾンビは、子プロセスが終了して、
OS が、その終了コードをどう扱えば良いのか、わからないから、ひとまず保存している状態

普通なら、子プロセスの終了コードは、親プロセスへ渡されるのかな？

ゾンビが生まれた時に、親プロセスがどうなっているのか？

**デフォルトの名無しさん** · 2019/04/13(土) 14:09:25.74

>>265
お前には言ってない

>>266
タイミング的に子プロセスが受け取るのかシェルが受け取るのかってことなんだけどね。コマンドを実行中なのかシェルが実行中なのか
set -e を使うからややこやしい、シグナルの基本をわかってないんじゃないんだろなとしか思えんけど。コマンドがINTシグナルで終了した場合、シェルが擬似的にシグナルハンドラ呼んでるっぽいかな(もしくは自らにINTシグナル出してるのかな？)

何したいのか知らんけど、set -e 使わずに、INTシグナルハンドラでexitすればいいんじゃないの

**デフォルトの名無しさん** · 2019/04/13(土) 14:29:06.39

>>279
その理屈はわかるんだけどねぇ

まず必ずゾンビになるんじゃなくてたまになる。だからタイミングの問題
CTRL-Cを押した時になる。通常の処理では発生しない。
CTRL-Cのハンドラでは作業ディレクトリの削除を行っている。

ワーカー（& によるバックグラウンド処理）が複数ある。サブシェルを使ってるせいか
同じな名前のプロセスがたくさんいる。ワーカーを生成した後はwait（引数なし）を実行している。
ゾンビの存在は確認しているが、誰がゾンビになったのかその親が誰かはよくわかっていない。
（たまにしかならんので探しにくい）ただし内部で呼び出してるtrやmvがゾンビになったこともある。

CTRL-Cのハンドラでは作業ディレクトリの削除の他、多数生きてるワーカー（労働者）を
皆殺しにするためにジェノサイド（kill -TERM 0）を発動している。
ただし労働者を消した後に、労働者の作業場（作業ディレクトリ）も片付ける
必要があるので自分だけは死なないようにしている。（trap ':' TERM）
実際にはもっと複雑だけど、死なないのは自分だけなはずなんだけどな

バグでゾンビになったこともあるので記憶が曖昧だけど
（バグを修正した今は）zshだけしか発生しなくなっているかもしれない。
もしかしたらzsh内蔵のkillにバグがあって殺す順番とか
子供が生まれるタイミングで発生してるとか？

でもまあなんだかんだでシンプルにしていったら
ゾンビの発生率も下がってきたし諦めるかな

**デフォルトの名無しさん** · 2019/04/13(土) 14:40:48.63

うーん、おかしい。trってワーカー（バックグラウンドプロセス）の
中で使っているとはいえ、パイプの右側でしか使ってないんだが？

**279** · 2019/04/13(土) 15:17:27.06

漏れにも、ゾンビになるプログラムとならないプログラムの、違いがわからない

ゾンビになるメカニズムを検索してみれば？

**デフォルトの名無しさん** · 2019/04/13(土) 15:21:25.04

「ゾンビになるメカニズム」で検索してみた

管理テーブルにデータが残ってるだけなら
消す方法（もしくは隠す方法）があってもいいと思うんだがねぇ

**デフォルトの名無しさん** · 2019/04/13(土) 16:27:29.48

>>284
wait()すりゃいいんだよ。
普通はinitが拾ってくれるんだが、誰にでも好き嫌いはあるということだろう。

**デフォルトの名無しさん** · 2019/04/13(土) 16:33:30.75

>>280
>コマンドがINTシグナルで終了した場合、シェルが擬似的にシグナルハンドラ呼んでるっぽいかな(もしくは自らにINTシグナル出してるのかな
違うか。control-cでのINTシグナル送るやつの文献ってどこぞにあるかなあ

**279** · 2019/04/13(土) 17:05:08.41

Ctrl+C が、子プロセスやパイプラインのジョブグループに、

どのように伝達されていくかとか、難しい

**デフォルトの名無しさん** · 2019/04/13(土) 17:21:22.57

いろいろ間違っていた。訂正する。

まずCTRL-Cは関係なさそう。実は正常な動作でも（プログラム実行中に）ゾンビができることがあった。
ゾンビができると今は無限ループ状態になるので気づいたが、ちょっと前まではプログラムの構造上、
ゾンビを放置して正常終了していたと思う。zshではあまりテストしていなかったから気づかなかった。

バックグラウンドプロセスが関係あるかないかはよくわからない。
何回か動かしているがバックグラウンドプロセスを使用しない場合は今の所再現していない。

あとなんかWSLとのからみな気がしてきた。
速度が違うから断定は出来ないがLinuxだと再現しない。

今の所、WSL環境にて、zshで、バックグラウンドプロセスを使用し、
その中でパイプを使った処理を行うと、まれにゾンビプロセスができる。

**デフォルトの名無しさん** · 2019/04/13(土) 17:27:02.88

>>286
シグナル一般の話ではなくてttyの話だったら、詳解Unixに載ってた気がするが、
当然そのくらいは読んでるよね。

**デフォルトの名無しさん** · 2019/04/13(土) 17:36:42.95

>>287,289
なるほど
すまん、読んでない。遠い記憶では読んでいたような気もするが忘れたので読んでない

**デフォルトの名無しさん** · 2019/04/13(土) 17:43:50.87

再現コード出来た。このコード、なにか問題有る？

これをWSL＋ZSHで実行すると、人目につかず永遠とbcコマンドで1+1を計算し続け、
CTRL-Cで停止するときにbcコマンド含めたプロセスグループ全体をkillする（はず）
これをやるとbcコマンドがゾンビ化する。（Linuxだとしない）

#!/usr/bin/zsh

int() {
echo kill
kill -TERM 0
echo killed
exit 1
}
trap 'int' INT
trap ':' TERM

worker() {
while :; do
echo '1+1' | bc > /dev/null
done
}

for i in $(seq 16); do
worker &
done

echo wait
wait

**デフォルトの名無しさん** · 2019/04/13(土) 17:44:42.87

やっぱり詳解Unixは買わねばいかんか・・・

**デフォルトの名無しさん** · 2019/04/13(土) 17:54:41.69

dash、bashでは再現しない。kshでも再現した。
いずれもWSLのみ。これもうWSLの問題だろ・・・
きっとWSLのバグをzshとkshが踏んじゃったんだな

**デフォルトの名無しさん** · 2019/04/13(土) 17:55:48.18

これ関連してるのかな？

Why are there many zombie process in windows subsystem for linux(WSL)? How to kill them totally?
https://superuser.com/questions/1419292/why-are-there-many-zombie-process-in-windows-subsystem-for-linuxwsl-how-to-ki

**デフォルトの名無しさん** · 2019/04/13(土) 18:09:57.29

次のWindows 10のリリースで治ってんじゃないですかねー
もういいか

Zombie zsh processes left behind that consume 8 % CPU each
https://github.com/Microsoft/WSL/issues/3940

Killing a defunct zombie leaks the zombie process forever
https://github.com/Microsoft/WSL/issues/3741

https://docs.microsoft.com/en-us/windows/wsl/release-notes#build-18267
Fix issue where zombie process may not be reaped and remain indefinitely.

**デフォルトの名無しさん** · 2019/04/14(日) 14:12:09.49

read -r text <<HERE
printf [%s]\n it's a "s'm'a'l'l 'w"o'r"l'd"
HERE
$text

↓出力

[it's]
[a]
["s'm'a'l'l]
['w"o'r"l'd"]

この仕様、うまくすればなにかに使えそうな気がしている。
文法エラーにもならずevalとはまた違った挙動だ。
とゆうかどういう仕様なんだろう？

**デフォルトの名無しさん** · 2019/04/14(日) 17:50:16.12

$ cat b.pl
#!/usr/bin/perl -w
print("$_\n") foreach @ARGV;
$ cat c.sh
#!/bin/bash

IFS=+
./b.pl a b c
./b.pl a+b+c
while read -r v ; do $v ; done <<EOF
./b.pl a b c
./b.pl+a+b+c
EOF
$ ./c.sh
a
b
c
a+b+c
./c.sh: 行 6: ./b.pl a b c: そのようなファイルやディレクトリはありません
a
b
c
$ # うん、なかなか面白いね。どうしてこうなるかは man に書いてあるよ。
$ # 簡単に言うと、単語の分割というのは最初に行われるものと
$ # 変数が展開された後に行われるものがあるんだ。
$

**デフォルトの名無しさん** · 2019/04/15(月) 17:41:03.59

シェルスクリプト（対話操作含め）が実行される手順って結構複雑な割に他の言語よりずっと単純だから
理論から実践（この場合はシステム処理とか？）への、かなり良い足掛かりになるよね。

**デフォルトの名無しさん** · 2019/04/21(日) 01:20:29.51

http://www.sample/{01..10}.jpg
これが書かれたtxtを読み込んでブレース展開して出力する方法ないです？

$ printf "%s\n" < foo.txt
適当にこうやっても上手く行かなくて

**デフォルトの名無しさん** · 2019/04/21(日) 01:26:56.31

ないです

**デフォルトの名無しさん** · 2019/04/21(日) 01:40:13.99

eval $(echo -n 'echo '; cat foo.txt) とか？

**デフォルトの名無しさん** · 2019/04/21(日) 02:15:47.05

sh << END
printf "%s\n" $(cat foo.txt)
END

**デフォルトの名無しさん** · 2019/04/21(日) 02:24:15.12

echo "printf '%s\n' $(cat foo.txt)" | sh
でよかった

**デフォルトの名無しさん** · 2019/04/21(日) 08:49:56.51

eval 'echo '$(<foo.txt)

**デフォルトの名無しさん** · 2019/04/21(日) 10:59:40.33

>>304
内側のリダクレクトが何かと思えば $(cat file)の変形があったとは
複数行も対応してるしこれなら行けそうですわ

**デフォルトの名無しさん** · 2019/04/21(日) 12:47:47.19

ごめん、もうちょっとシンプルに書けた。
eval echo $(<foo.txt)

**デフォルトの名無しさん** · 2019/04/22(月) 02:03:07.74

>>306
これいいね！
……正直，実際に使う機会は少なそうだけど
シェルの処理をしっかり把握してないと思い付かない回答。

**デフォルトの名無しさん** · 2019/04/22(月) 11:54:54.98

例えばさ、

bash -n -c 'a=(a b c)'
↑これはbashとして正しい文法だけどさ

sh -n -c 'a=(a b c)'
↑これは文法エラーになるじゃん？実行していなくても

これみたいに、実行してないのにあるシェルではOKで
別のシェルではNGみたいな文法って他に何かしらない？

**デフォルトの名無しさん** · 2019/04/22(月) 12:22:26.76

>>308
君と似た例ではあるが;

$ bash -n -c '%=a'
$ sh -n -c '%=a'

**デフォルトの名無しさん** · 2019/04/22(月) 15:47:58.78

eval 'printf "%s\n" '$(cat foo.txt)
これprintfをシングルクォートで囲まないと改行されないのね
http://www.sample/01.jpgnhttp://www.sample/02.jpgnhみたいな結果ばかりでちょっと悩んだ
zsh使ってないけどこれはforの後の二重括弧に空白が必要だとかなんとか
{には空白がいるのにfor((が通るbashの方が不自然なのか

**デフォルトの名無しさん** · 2019/04/22(月) 18:28:36.64

export -p と export の違いってなに？

**デフォルトの名無しさん** · 2019/04/22(月) 18:36:38.02

\n の処理をだれがいつやらかすのかってとこかな。printfにやらせたいprintfに \n のまま渡さなくてはという感じ
eval printf "'%s\n'" $(cat foo.txt)
eval printf '%s\\n' $(cat foo.txt)

**デフォルトの名無しさん** · 2019/04/22(月) 23:58:52.60

そもそもなぜ eval を使うのかというと、コマンドラインの解釈において
ブレース展開がコマンド置換より前だから
コマンド置換してからブレース展開するためには
eval を使って解釈を最初からやり直す必要があるためで
しかしながら printf と "%s\n" にはその必要がないのだから、つまり
printf "%s\n" $(eval echo $(<foo.txt))
でいいんじゃないかな。

**デフォルトの名無しさん** · 2019/04/23(火) 08:44:15.00

ダブルクリックで実行できるのとできないシェルスクリプトの違いって一体
whileとcaseで簡易メニュー作ってたんだけどダブルクリックしても画面に何も出ない上に
起動されたbashがCPUがかなり食ってた
無論端末から実行はしっかり通る
ls結果を外部保存するような単純な奴はダブルクリックでも正常通りなんだけど

**デフォルトの名無しさん** · 2019/04/23(火) 13:31:54.32

シェルスクリプト関係ない

**デフォルトの名無しさん** · 2019/04/23(火) 18:19:48.00

>>311
マニュアル嫁
つーか実行すれば一目瞭然だぞ
……と思ってやってみたらexportはオプション成しで起動すると
export -pと同じ動作をするんだね

**デフォルトの名無しさん** · 2019/04/23(火) 18:22:18.78

>>314
使ってるGUIシステムがX11なら
x-terminal-emulatorなんかを使って仮想端末を立ち上げてからじゃないと
メニューみたいな端末出力を必要とするものは期待した通りに動かないよ。

**デフォルトの名無しさん** · 2019/04/23(火) 20:23:01.28

>>316
そうマニュアルに書いてあるだろう。なんのボケ？w

**デフォルトの名無しさん** · 2019/04/23(火) 21:51:37.02

模範解答

export -p がどう表示されるかはPOSIXで規定されていますが、
export がどう表示されるかは未定義です。（同じとは限りません）
つまり、exportがどうなるかはシェル毎に異なります。
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#export

更にexport -pはbashではPOSIXに反してdeclareで表示されます。
これらは各シェルのマニュアルには書いていません。

**デフォルトの名無しさん** · 2019/04/23(火) 22:49:27.06

模範解答

**デフォルトの名無しさん** · 2019/04/24(水) 08:22:12.86

bashで abc*が展開できると出来ないときがあって
それをテストするのに
[ 　"abc*" = 'abc*'　]
とやりたいのにできません
どうやったらできますか？

**デフォルトの名無しさん** · 2019/04/24(水) 17:25:06.62

>>321
何がどうできないのかよく分からないけどシングルクォートとダブルクォートは
処理が違うから「=」にならないと思うよ
シングルクォート側は文字列なので「abc*」っていう文字列になるけど
ダブルクォート側は解釈されるので「*」にあたるものが存在しないと何もない
状態なので「abc」って文字列になるんじゃないかな

**デフォルトの名無しさん** · 2019/04/24(水) 17:40:21.19

は？

**デフォルトの名無しさん** · 2019/04/24(水) 17:42:31.98

abc*が展開できない時はそのままabc*になるのでそう思って書いてみました

**デフォルトの名無しさん** · 2019/04/24(水) 18:28:22.30

abc* というファイルが実際にあるというというのは除外でいいのね？

**デフォルトの名無しさん** · 2019/04/24(水) 18:32:06.10

ええです

**デフォルトの名無しさん** · 2019/04/24(水) 18:45:29.21

ダブルクォートで囲んでも囲んじゃうとglob展開は行われない変数などのようには。(>>322見るとデフォでは？？展開できるなんかあっったかなあ)

[ "$(echo abc*)" = "abc*" ]
とかかな
any='abc*'; [ "$(echo $any)" = "$any" ]

**デフォルトの名無しさん** · 2019/04/24(水) 19:43:12.00

日本語がダメな奴と日本語がダメな奴が
初心者同士の会話をしてる。
ついていけない。

**デフォルトの名無しさん** · 2019/04/24(水) 19:56:20.38

＞＞３２７
ありがとうございます
echoを使わずできたらお願いします
無理なら諦めます

**デフォルトの名無しさん** · 2019/04/24(水) 20:25:30.92

>>328
答えてやれよ。マウントとりではなくて。ふたレスもするくらいな
(>>322は正直お前の>>323と同じだが、それだけじゃなというのと、もしかしてもしかしてもしかしてだけど)

**デフォルトの名無しさん** · 2019/04/24(水) 20:29:18.25

>>329
echoを使わずの条件がわからない。他にもやり方があるけど、複数行にだったり
stackoverflowではなんか凝ったのより ls が人気みたい。見た目でわかりやすからかな

**デフォルトの名無しさん** · 2019/04/24(水) 21:08:22.56

何をやりたいのかわからない。

端末にecho *って入力して
あぁ、展開されましたねって
確認すりゃいいだけじゃんか

なんで[ ]とか使うのか

**デフォルトの名無しさん** · 2019/04/24(水) 21:16:12.73

>>332
お前が何言っているのかわからない
シェルスクリプトで判断してなにかその後にする部分のことを聞いてきているのだろう。その判断するとこだけを書いているのだろうと読むと思うけど

(日本語どうの言うなら、他人の日本語より自分の日本語を疑った方がいいようなw)

**デフォルトの名無しさん** · 2019/04/24(水) 21:29:00.43

>bashで abc*が展開できると出来ないときがあって
abc* としても、該当するものがあってglob展開する場合と、該当するものがなくてglob展開しない(出来ない＝globのまま)ときがあって
>それをテストするのに
展開できなかった場合はマズいので(とかなんとで)、それをテストするのに
[ 　"abc*" = 'abc*'　]
>とやりたいのにできません
としてみましたが、思ったようになりません

だよ。たぶんw

**デフォルトの名無しさん** · 2019/04/24(水) 22:15:49.65

Ruby で該当するファイル数を数えれば？
それが、0 なら、該当なし

p Dir.glob( 'C:/Users/Owner/Documents/*.txt' ).length #=> 0

**デフォルトの名無しさん** · 2019/04/24(水) 22:19:13.46

>>333
お前はさ、なぜこういう質問に至ったかまで考えられてないんだよ。
意味不明なんだよ。

>>334
そう思うやろ？だったら意味不明って気づかなきゃ。

> 展開できなかった場合はマズいので

つまり、現時点で「展開できてる」はずなわけだよ。
展開の仕方を知ってる。
なのに展開できないと言ってる。意味不明だろう？

**デフォルトの名無しさん** · 2019/04/24(水) 22:37:08.62

>>336
なにを言っているのかさっぱりわからん。意図目的とすることがな。いや後半はまったくわからん、お前の頭の世界の話だけのようで。ちょっと怖いぞw
ただマウントとりたいだけというのはわかるぞw

**デフォルトの名無しさん** · 2019/04/24(水) 22:39:35.88

読めなかったらのをごまかすためにむちゃくちゃ言っているんだな
うん。そゆことにしとこ。でないとアレだなということで

**デフォルトの名無しさん** · 2019/04/24(水) 22:49:53.80

だーかーらー、いつもどおりのやってるやり方で展開して
それをチェックすればいいだけだろと

**デフォルトの名無しさん** · 2019/04/24(水) 23:04:43.57

ぜんぜん「だーかーらー」でもなんでもないな。お前の言っていることはわからん
どうも自称初心者じゃない自称日本語ダメじゃない人の自分の脳の世界でなんか言ってるとしか見えない

お前の言う初心者の ID:6T3A9gnL は >>327 ので不満があるようだがそれでも答えになってるらしいぞ

お前の変な言い分はお前のためでしかなく、他に対する目的も意味もない。マウントとりたいだけのお前には意味があってもな。マウントとりたいから延々続くのか？

**デフォルトの名無しさん** · 2019/04/24(水) 23:06:17.58

誤お前の言う初心者の ID:6T3A9gnL は
正お前の言う初心者の ID:6O+4Q2Ek は
なんかすまん

**デフォルトの名無しさん** · 2019/04/24(水) 23:14:58.44

> お前の言う初心者の ID:6T3A9gnL は >>327 ので不満があるようだがそれでも答えになってるらしいぞ

だからなんなのか知らんが、お前ら、いつもどおりの展開ってecho使ってんのか？
使ってないだろ。いつもどおりの使えばいいだけなのに、
悩んで（？）別の方法模索してるから、意味不明だって言ってるんだよ。
質問者にも回答者にも

**デフォルトの名無しさん** · 2019/04/24(水) 23:22:52.75

むちゃくちゃww
自分で>>332って書いているのに
言うにことかいて「だからなんなのか知らんが」だってwwwもろマウントとりたいだけ、マウントとり失敗してわけわからんだけだな

**デフォルトの名無しさん** · 2019/04/24(水) 23:54:51.80

展開されるかどうかの確認はそれでいいし、
プログラムでならいつもどおりのやり方で展開すればいい
何をやりたいのかわからないのに、どちらの話かわかるわけないだろ
どちらにしろ「は？」なわけだが

**デフォルトの名無しさん** · 2019/04/25(木) 00:00:15.44

すでにお前に対して「は？」だよ

**デフォルトの名無しさん** · 2019/04/25(木) 00:02:54.32

っていうか、正しいやり方知らんのか？
echo使って検査するんじゃないぞ（それじゃできない）

**デフォルトの名無しさん** · 2019/04/25(木) 00:05:34.10

それじゃできないっていうのはコレな

> abc* というファイルが実際にあるというというのは除外でいいのね？

abc* というファイルが実際にあることも考慮するやり方をするべき
そうすれば正解にたどり着く

**デフォルトの名無しさん** · 2019/04/25(木) 00:16:01.39

ダメな場合もあるのはわかって聞いているんだけど。本人がいいっていったからそれに合わせてだよ

だれかみたいに「すべき」とか強要するつもりも知識自慢したくてたまらないとかもないからな。その最後のといい、なんか偉そうにしたいのね、質問者の意図とか読まずに、知識自慢するためのw質問者の他の情報も引き出そうともせずに

shopt使うとかいう知識自慢だったら笑うぞ。別にabc*という実ファイルがあった場合でものshopt使わずにの方法もあるけどな

**デフォルトの名無しさん** · 2019/04/25(木) 00:21:59.00

本当に差があるやつとの会話は疲れるｗ

> bashで abc*が展開できると出来ないときがあって
展開でするやり方知っってるよな？それ使え

> それをテストするのに
展開できないことのテストはいらん

お前が知ってるはずの、展開するやり方を使って、
-f （もしくは -d や -e 等）で、その名前の
そのファイルが実査に有るかどうかを調べるだけ

shoptとかもしらん

**デフォルトの名無しさん** · 2019/04/25(木) 00:22:22.15

実査 -> 実際

**デフォルトの名無しさん** · 2019/04/25(木) 00:34:11.93

やっぱり、まだわかってないんだな、「展開～」という質問を
shoptとかもしらん....
-f とか、まさかそんな「当たり前の」こと言い出すとは
まさか「その程度」だとは思わなかったわっ。なんだろこれw