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

**デフォルトの名無しさん** · 2020/11/24(火) 21:37:20.06

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

全般
・荒しは無視しましょう。
・丁寧な姿勢を心掛けましょう。
・ネチケット（死語）を意識しましょう。
・「○○（他の言語）でいいやん」は禁止。他のスレに行ってください。

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

**デフォルトの名無しさん** · 2021/02/03(水) 05:05:52.97

レスする前にちゃんと読み返したほうがいいよ
としか言いようがない

1.コマンド置換とreadは同じであるはず／あるべきと思った
2.それが間違いだったのに自ら先に返答レスを馬鹿にした
この2つの間違いを決して認められないだけ
だけでよくそんだけ小手先の誤魔化しを続けられるな。マジキチすぎだろう

**デフォルトの名無しさん** · 2021/02/03(水) 05:06:58.67

> 1.コマンド置換とreadは同じであるはず／あるべきと思った

思ったとか、それはお前の感想でしかない

> 2.それが間違いだったのに自ら先に返答レスを馬鹿にした

「それ」とはお前の感想である

**デフォルトの名無しさん** · 2021/02/03(水) 05:08:08.44

何でそんなアホな小手先の誤魔化し文書けるの？？

**デフォルトの名無しさん** · 2021/02/03(水) 05:09:08.17

ほらね。俺が言い返しても、
こいつは言い返してこない。

言い返せないというのが正しいがｗ

**デフォルトの名無しさん** · 2021/02/03(水) 05:11:25.52

すぐにそういう馬鹿なこと言うし
アホな小手先の誤魔化し文になんで正面からいつまでも付き合わなきゃならんねん
アホな小手先の誤魔化し文という自覚がないのか？マジキチすぎすぎだろう

**デフォルトの名無しさん** · 2021/02/03(水) 05:13:12.26

それにコマンド置換とreadが全く違う動作をすると思ってそうだよなｗ
違うところがあるのは知ってるからそれは聞いてない
同じ動作をするところがあるのを、はたしてこいつは知ってるんだろうか？ｗ

ま、また関係ない話をしてごまかすだろうな

**デフォルトの名無しさん** · 2021/02/03(水) 05:16:11.71

後付けて決めつけが始まりましたwww
ソース読んでるし、他のシェルで試してもいるし
イマイチ何のことかだが、こいつだと言い出しそうなのは大体推測できる
こんなこと言い出したのもついさっきわかったとかだろうな。違うか？w

**デフォルトの名無しさん** · 2021/02/03(水) 05:18:11.87

ほらね。俺のレスへの言及が一切なし

**デフォルトの名無しさん** · 2021/02/03(水) 05:19:36.98

だいたいさぁ command substitution: ignored null byte in input を出すなら、
read: ignored null byte in input も出すべきだって思うだろ
これに関する動作は同じなんだから

多分それも知らなかったんだろうけどな

**デフォルトの名無しさん** · 2021/02/03(水) 05:20:21.08

レスする前にちゃんと読み返したほうがいいよ

www
いい加減怒るヤツ出るだろうし、誤魔化しに付き合うのももういいってので

どうして4.4からコマンド置換のとこでメッセージ出すようになったか
開発者の気分だろうwもしくはそこの部分で開発者に何らかの注文があったんだろ
コマンド置換の部分だけの修正(ソースコードからは気分としか読めないけどw)なのでコマンド置換だけの話、readは関係ない
readに主題置いて聞かれたら、readはコマンド置換じゃないからという返答は特におかしくもない

1.コマンド置換とreadは同じであるはず／あるべきと思った
2.それが間違いだったのに自ら先に返答レスを馬鹿にした
この2つの間違いを決して認められないだけ

というだけのお話でしたとさw

**デフォルトの名無しさん** · 2021/02/03(水) 05:21:04.31

> どうして4.4からコマンド置換のとこでメッセージ出すようになったか

誰もそんな事気にしてない

**デフォルトの名無しさん** · 2021/02/03(水) 05:21:20.27

> 1.コマンド置換とreadは同じであるはず／あるべきと思った

同じところがありますね。

**デフォルトの名無しさん** · 2021/02/03(水) 05:22:16.05

もうネタバレしてやると

コマンド置換とreadは、どちらも ignored null byte in input は同じなんですよ
どちらも入力のnullバイトを無視してる

**デフォルトの名無しさん** · 2021/02/03(水) 05:27:21.54

>>779ですでに書かれてることを何を一人悦に入っているのだか
すでに書かれてることを、何自分は知ってるお前(ら)は知らないと言えるんだか
>コマンド置換とreadは、どちらも ignored null byte in input は同じなんですよ
ちょっと違うんだなあ。さてどう違うでしょう？ww

**デフォルトの名無しさん** · 2021/02/03(水) 05:29:11.45

違いはありません。どちらも同じように ignored null byte in input します。
英語わかる？入力のNULLバイトを無視するって書いてあるんだよｗ

**デフォルトの名無しさん** · 2021/02/03(水) 05:30:22.06

ふふ～んwww
「ちょっと違う」ことは知らないということね

**デフォルトの名無しさん** · 2021/02/03(水) 05:30:41.09

1. コマンド置換とreadはどちらも入力のNULLバイトを無視する
2. 質問は「なんでreadだとこのエラーはださないんだろう？」

これだけなのにreadが主語だ！とか理由わからないことを言って
ずーっと自分の勘違いをごまかしてる

**デフォルトの名無しさん** · 2021/02/03(水) 05:31:53.40

>>815
「入力のNULLバイトを無視する」は同じですといいました。
それ以外の点では違うところがあると>>805ですでにいいました。
> 違うところがあるのは知ってるからそれは聞いてない

お前のターン（笑）

**デフォルトの名無しさん** · 2021/02/03(水) 05:32:05.41

はい出ました、また話題を変えての堂々巡り巡り
レスする前にちゃんと読み返したほうがいいよ

www
一人でやってなさい。じゃね

**デフォルトの名無しさん** · 2021/02/03(水) 05:32:55.92

逃げました（完）

**デフォルトの名無しさん** · 2021/02/03(水) 05:35:38.89

逃げてないよぉ
他の人に怒られるのが嫌なだけだぞw本当にお前は自分がどれほどだと思ってるねん

**デフォルトの名無しさん** · 2021/02/03(水) 05:42:02.60

俺がじゃなくて、お前がアスペ

**デフォルトの名無しさん** · 2021/02/03(水) 05:46:48.79

www

**デフォルトの名無しさん** · 2021/02/03(水) 06:57:20.76

質問者おいてけぼりで夜通しマウント合戦
きもっ

**デフォルトの名無しさん** · 2021/02/03(水) 08:29:21.99

質問者おいてけぼりだと思ってるやつがいるらしい
そんなやついないだろう

**デフォルトの名無しさん** · 2021/02/03(水) 08:37:12.75

>>823 に１票

**デフォルトの名無しさん** · 2021/02/03(水) 08:52:34.64

嘘くさ

**デフォルトの名無しさん** · 2021/02/03(水) 09:51:45.69

反論できなくなって単発IDを出し始めたぞｗ
>>823とか>>825とか

**デフォルトの名無しさん** · 2021/02/03(水) 11:06:47.70

いつまでこの話題を続ける気だよｗ

**デフォルトの名無しさん** · 2021/02/03(水) 18:30:45.39

>>827
いつものことです

**デフォルトの名無しさん** · 2021/02/04(木) 12:41:51.48

自己紹介

**デフォルトの名無しさん** · 2021/02/07(日) 19:23:43.78

$find . -type f -name '*.mp4' -exec sh -c "echo /Applications/Safari.app " \;
/Applications/Safari.app
/Applications/Safari.app

$find . -type f -name '*.mp4' -exec sh -c "echo $dirname /Applications/Safari.app " \;
/Applications/Safari.app
/Applications/Safari.app

$dirname /Applications/Safari.app
/Applications
どうして2番目の例ではdirnameが作用していないように見えるのですか？

**デフォルトの名無しさん** · 2021/02/07(日) 19:26:54.39

しらんけどダブクォだろ

**デフォルトの名無しさん** · 2021/02/07(日) 19:30:49.83

$dirname /Applications/Safari.app
だと、dirnameという変数を展開しようとしてるだけだろ
dirnameというコマンドを実行するのではなく

コマンドプロンプトのとちょっと見分けづらいのでちゃんとスペースを置くべきだな

**デフォルトの名無しさん** · 2021/02/07(日) 19:34:34.15

何がしたいの？

**デフォルトの名無しさん** · 2021/02/07(日) 19:39:40.46

さっぱりわからんなw
動作確認の途中なんだろう。findしても同じ結果出すだけだしな
そのうち {} とか入れたりするんだろうが、

実行したいなら $() だろう

-exec sh -c "
は
-exec sh -c '
でないとマズそうマズいだろうな

な感じかなあ

**デフォルトの名無しさん** · 2021/02/07(日) 20:30:53.02

${～} だろ

echo ${dirname}/Applications/Safari.app

**デフォルトの名無しさん** · 2021/02/07(日) 23:59:19.31

パラメータ展開よりbasename/dirnameコマンドのほうが分かりやすいね

~$ DIR='/ChonChon/Chon.bak'
~$ basename $DIR
Chon.bak
~$ echo ${DIR##*/}
Chon.bak
~$ basename $DIR
Chon.bak
~$ echo ${DIR#*/}
ChonChon/Chon.bak
~$ echo ${DIR##*/}
Chon.bak
~$ echo ${DIR%/*}
/ChonChon
~$ echo ${DIR%%/*}

~$ dirname $DIR
/ChonChon

**831** · 2021/02/08(月) 00:07:37.75

ありがとうございます
変数になっていることに気づいていませんでした
find -exec sh -cで複数コマンドを扱うのは諦めforを使って解決しました
>>833 スペースをどう置くとどう見分けやすくなりますか？
>>834 質問に関係ある部分だけ抜き出したので意味不明なものになっています

**デフォルトの名無しさん** · 2021/02/08(月) 01:01:47.00

>>837
わかりやすさ vs 実行速度の話だね
さくっとコマンド入力する時はbasenameでいいけど
シェルスクリプトであればパラメーター展開のほうがいい

**デフォルトの名無しさん** · 2021/02/08(月) 02:02:04.12

>>838
$ find . -type f -name '*.mp4' -exec sh -c "echo $dirname /Applications/Safari.app " ¥;

$ dirname /Applications/Safari.app

**デフォルトの名無しさん** · 2021/02/08(月) 17:24:23.44

# sudo apt install xclip
CLIPB=$(xclip -o)
echo $( basename $CLIPB )

**デフォルトの名無しさん** · 2021/02/08(月) 19:08:48.56

Ruby なら、glob を使う

# . で始まる、隠し directory, file を除く
glob_pattern = "C:/Users/Owner/Documents/*.csv"

Dir.glob( glob_pattern )
.select { |full_path| File.file?( full_path ) } # ファイルのみ
.each { |full_path| puts full_path }

出力
C:/Users/Owner/Documents/a.csv
C:/Users/Owner/Documents/b.csv

**デフォルトの名無しさん** · 2021/02/08(月) 19:27:57.47

すでにroot

**デフォルトの名無しさん** · 2021/02/08(月) 19:29:24.19

Rubyなら～
C:/
特異すぎ

**デフォルトの名無しさん** · 2021/02/08(月) 20:15:13.87

なぜ定期的にRubyが出てくるのか

**842** · 2021/02/08(月) 20:50:44.33

シェルスクリプトも、Windows 10, WSL2, Ubuntu 18.04, VSCode でやってる

Ruby は、Linux用・Windows用の両方を入れてる

**デフォルトの名無しさん** · 2021/02/08(月) 20:53:25.78

>>845
久しぶりだけどなw
なんて言われてるかは上の方であるな
トンチンカンなレスしてるとこからもトンチンカンな承認欲求なんだろう

**831** · 2021/02/09(火) 16:10:25.08

>>840
ありがとうございます

**デフォルトの名無しさん** · 2021/02/10(水) 14:26:08.93

Alpine？busyboxってコマンド追加した場合の競合どうなってるんですかね？
たとえばdateがGNU版と挙動が違うのでcoreutils追加したんですけど
元々/bin/dateだったのが追加後も/bin/dateのままなのに呼び出されるのはしっかりcoreutilsのに変わってます
macではdateとgdateで使い分けられたのでモヤモヤします

**デフォルトの名無しさん** · 2021/02/10(水) 15:19:36.03

汎用ではなくカスタマイズした環境前提だからそんなの気にしない
置き換わっても置き換わるのを知って作るそういう独自の環境を自ら望んで作る

**デフォルトの名無しさん** · 2021/02/10(水) 18:01:20.69

そういうものなんですねありがとうございます！

**デフォルトの名無しさん** · 2021/02/10(水) 20:16:55.68

>>849
ディストリの方針次第。Debianとかだってvim-tinyを入れるか
通常のvimを入れるかで呼び出されるvimが変わる
どちらを使うかの切り替え機能も持っている

パッケージで入れる分には、入れても動作するように作られてる
パッケージで入れて壊れたらそれはディストリのバグ

Debianなんかはbusyboxを入れてもデフォルトで置き換えたりしない
alpineはbusyboxの方がデフォルトなんだから、それで動くように作られてる
それをcoreutilsに変更しても動くように作られてるだろう

macの場合、gdateを入れるのはサードパーティのHomebrew
Apple社と一切関係ないフリーソフトで、Appleは動作保証もしてないのだから
Homebrewはデフォルトで置き換えたりしない。壊れる可能性があるから
dateを置き換えられないだけで使い分ける方が便利なわけではない

そもそもbusyboxはcoreutilsのコマンドと比較して一部の機能が
実装されてないだけで、実装されてる機能に関しては互換性があるように作られてる
しかしMacのdateはBSD版なのでgdateと互換性がない

**デフォルトの名無しさん** · 2021/02/12(金) 23:49:25.35

超高速なシェルって登場しないもんかね？
JITエンジン搭載して最適化とかガシガシやるようなやつ

**デフォルトの名無しさん** · 2021/02/13(土) 09:35:59.06

>>853
それはスクリプト言語の高速化、とはちがうのけ?

**デフォルトの名無しさん** · 2021/02/13(土) 11:22:13.76

>>854
お前の言うスクリプト言語の高速化が何のことかわからんって

**デフォルトの名無しさん** · 2021/02/13(土) 15:47:07.99

>>855
各自適当に当てはまると思うのを挙げてもらえばいいと思ったんだがw
じゃあ例えばPythonの各種実装でいいけども。
そしてJITだけが高速化の技術ではないけども。

**デフォルトの名無しさん** · 2021/02/13(土) 15:50:58.00

超高速なシェルって～という質問に対して
スクリプト言語の高速化とは違うのけと言われてもね

飴がほしいに対して
キャンディーとは違うのけと言うようなもんだよ
お前は何がいいたいのか

**デフォルトの名無しさん** · 2021/02/13(土) 16:12:05.01

思慮が浅いからわからんのだろう
思慮が浅いからトンチンカンな疑問が湧くのだろう

**デフォルトの名無しさん** · 2021/02/13(土) 16:14:48.15

>>857
じゃあ最初から「ちがうのけ」に対して「ノー」と言えよw
どうしてもシェルじゃないといけないのかの確認だったのだが。
もうどうでもいい。

**デフォルトの名無しさん** · 2021/02/13(土) 16:20:51.53

各自適当に当てはまるといっておきながら何を言ってるんだ？

（俺の定義に当てはまるものは）ノーだ

これでお前は何のことかわかるのか？

**デフォルトの名無しさん** · 2021/02/13(土) 16:44:38.58

これはいつものやつ

**デフォルトの名無しさん** · 2021/02/13(土) 16:46:14.65

俺もそう思った

**デフォルトの名無しさん** · 2021/02/13(土) 16:50:09.98

いやお前がなんだが
いつものやつもそういうレスを前にいくつかしてたからなおだな

**デフォルトの名無しさん** · 2021/02/13(土) 16:52:14.62

俺は違うぞ？何を言ってるんだか

**デフォルトの名無しさん** · 2021/02/13(土) 16:58:17.73

じゃあ、そういうように見えるから気をつけたほうがいいな
なぜかいきなり喧嘩腰になる>>857とか、全然意図を読めずにまだマウント取るのがメインのような>>860とかな
本当に違うんだったら、すまんかった。本当に違うなら

**デフォルトの名無しさん** · 2021/02/13(土) 21:13:09.13

超高速なシェルって言ってもどこを高速化したいのか分からんね
他のスクリプト言語と違ってプロセス起動を平気でやる性質があるから
JIT実装したところで、ねえ……

**デフォルトの名無しさん** · 2021/02/13(土) 21:18:19.57

>>865
>本当に違うんだったら、すまんかった。本当に違うなら
くっワロタ

**デフォルトの名無しさん** · 2021/02/13(土) 21:48:07.63

>>866
だよな
だから誰も必要としてないから誰も作ろうともしない、
シェルスクリプトの長い歴史から見ても
変わった人(いい意味で)がやろうと出ても企画倒れかな

**デフォルトの名無しさん** · 2021/02/14(日) 01:27:13.76

デーモン起動とかにも使われるシェルスクリプトは、速さよりもちょっとでも軽いほうがええやろ。
JITなんかにメモリを使う余裕はないな。

**デフォルトの名無しさん** · 2021/02/14(日) 14:36:19.88

デーモンとかに使うのは素の/bin/shで、言う通り軽い方なのが採用されてるだろう
JIT云々はそういうのではないのだろう。今あるbashとかzshとかそういう方向の

**デフォルトの名無しさん** · 2021/02/14(日) 15:27:49.90

シェルスクリプトの高速化って結局、exprに対する$()みたいな、外部コマンドの組み込みコマンド化が原則になると思うけど、
それで行き着く先ってPerlでしかないよね

まあRob Pikeの言う通り計測しろって話ではあるので、ボトルネックが実際fork/waitじゃなければまったくの的外れだけど

**デフォルトの名無しさん** · 2021/02/14(日) 18:02:37.21

シェルで使えるってだけならRUSTが速そうだけど

**デフォルトの名無しさん** · 2021/02/14(日) 23:21:01.83

>>871
JavaScriptの言語仕様を見ればわかるけど
JavaScript自体ではファイルの読み書きはできないんだよ
つまりI/Oを伴う機能は言語仕様としては本質的に不要と言える

外部コマンドなんて殆どがI/Oなので、それらを組み込む必要はない
Perlは多数組み込んでるので良くない

JavaScriptと同じように、I/Oを必要としないものは
シェル組み込みとして、メモリ計算処理を高速化すればいい
例えばメモリだけでできる単純な値比較や計算だけでもシェルは遅い

**デフォルトの名無しさん** · 2021/02/14(日) 23:39:01.27

>>873
おまえ、いつものポジキチやろ？

**デフォルトの名無しさん** · 2021/02/14(日) 23:58:12.52

>>874
違うけど、お前はいつもの「ポジキチと争ってるやつ」ってことは確定かなｗ

**デフォルトの名無しさん** · 2021/02/15(月) 00:59:58.92

争ってるがどこまでを指しているのかわからんが、反論してるのは複数居るだろう
確定しても意味なさげw

**デフォルトの名無しさん** · 2021/02/15(月) 01:11:01.23

>>873
ブラウザというホスト環境にのせるために考えられた言語だからI/Oがないだけ
ホスト環境がI/OやEvent Loopを補完しないと動かないし役に立たない

そういう種類の言語の仕様にI/Oがないからといって
一般的なプログラミング言語仕様にI/Oが本質的に不要なわけない
I/O無しではどんなプログラムも役に立たないから

**デフォルトの名無しさん** · 2021/02/15(月) 01:12:58.43

JavaScriptは元々はブラウザ上で動くが発端だからな
勝手にどこぞからロードしてユーザの意思に関係なく勝手に動くプログラムだからな
ローカルファイルにアクセスなんて自由にできたらどうなるか火を見るより明らか
ていうのがあって、何言ってんだかなという>>874じゃないのかな。知らんけどw

**デフォルトの名無しさん** · 2021/02/15(月) 01:13:50.12

あ、なんか被ったw

**デフォルトの名無しさん** · 2021/02/16(火) 03:00:19.59

>>877
C言語にも、I/Oないよ

**デフォルトの名無しさん** · 2021/02/16(火) 03:21:55.67

>>880
だから、#includeだったりリンカオプションだったり、めんどくさい準備が必要なんだけどな。

**デフォルトの名無しさん** · 2021/02/16(火) 06:35:07.01

関係ないだろ

**デフォルトの名無しさん** · 2021/02/16(火) 10:30:49.70

>>880
嘘ついちゃだめ

**デフォルトの名無しさん** · 2021/02/16(火) 10:43:13.65

言語とライブラリの区別をつけたほうが良いと思うよ

**デフォルトの名無しさん** · 2021/02/16(火) 11:56:09.07

C言語を持ち出すのはアセンブリに無いと言っているようなもんだな
どういう意味かわかるかな？

**デフォルトの名無しさん** · 2021/02/16(火) 12:22:40.92

>>885
わからん。ｗ
自分でもわかってないやろ？

**デフォルトの名無しさん** · 2021/02/16(火) 13:03:01.94

アセンブリ言語に無いのは当たり前なのはわかるね？
でもアセンブリでもファイルI/Oはできるよね？
C言語はアセンブリに近しい言語だというのはわかる？
だったら「言語仕様」としては無いのは普通と言える
アセンブリでファイルI/Oはアセンブリで記述したライブラリ(サブルーチン)を用いるのと同じように

てか「言語仕様」としては無いが、原典である K&R C でもすでにファイルI/Oに関しては記述があるし、
それに則っての標準としてのライブラリが「必ず」あるだろうから、言語仕様としてないあれはライブラリというのは無理筋だな

プログラミング言語だからとどれも一緒の扱いにするのが間違いでもあるな

**デフォルトの名無しさん** · 2021/02/16(火) 13:06:51.96

>>887
>それに則っての標準としてのライブラリが「必ず」あるだろうから
ああ、無いのもあるか。有名なOSで
まあ、そういう独特なのも独特のファイルI/Oは必ずあるってことでw

**デフォルトの名無しさん** · 2021/02/16(火) 16:08:25.47

>>885
例えば8086のOUT命令はアセンブリにないことになってるの？

**デフォルトの名無しさん** · 2021/02/16(火) 16:14:30.97

>>887
ただの決めつけを根拠にしているから、理屈があやしいな。ｗ

まあ、おまえはまず「フリースタンディング環境」について調べろ。
IOはあるのが当然、ではない。

**デフォルトの名無しさん** · 2021/02/16(火) 16:32:25.56

>>889
OUT命令ってなんなのか知ってるのかっていう
対象はチップのポートだぞ

>>890
そのフリースタンディングでもフリースタンディングではI/Oは無いとは言ってないだろ
C言語の元といえば K&R C Program Language であり、それに標準ライブラリはあると書いてある
ないとこは標準ライブラリがない環境でCを持ってきてるある意味派生であるはずの標準ライブラリが無いだけだな

**デフォルトの名無しさん** · 2021/02/16(火) 16:47:09.77

初版とかどうなのかと思い探したらあった。いいないんたーねっつは

CHAPTER 7: INPUT AND OUTPUT

Input and output facilities are not part of the C language, so we have
de-emphasized them in our presentation thus far. Nonetheless, real pro-
grams do interact with their environment in much more complicated ways
than those we have shown before. In this chapter we will describe “the
standard I/O library,” a set of functions designed to provide a standard I/O
system for C programs. The functions are intended to present a convenient
programming interface, yet reflect only operations that can be provided on
most modern operating systems. The routines are efficient enough that
users should seldom feel the need to circumvent them “for efficiency”
regardless of how critical the application. Finally, the routines are meant to
be “portable,” in the sense that they will exist in compatible form on any
system where C exists, and that programs which confine their system
interactions to facilities provided by the standard library can be moved from
one system to another essentially without change.

We will not try to describe the entire I/O library here; we are more
interested in showing the essentials of writing C programs that interact with
their operating system environment.

**デフォルトの名無しさん** · 2021/02/16(火) 16:51:36.76

K&R The C Program Language が Cの原典ではないというなら話にならないからもう知らないw
フリースタンディング環境とやらののうちのどこぞの環境でファイルI/Oがないなんて、>>888と似たようなもんだろうとしか思えない

**デフォルトの名無しさん** · 2021/02/16(火) 16:59:57.69

>>891
>I/Oは無い
ファイルI/Oは無い
ね。一応訂正させていただきます

**デフォルトの名無しさん** · 2021/02/16(火) 20:04:17.80

なぜC言語の話が出るのか？
なぜアセンブリの話が出るのか？
と飛躍がありすぎて、なんの話なのか、まったくわからん。ｗ

>>893
K&Rなんか、今となっては怪しい歴史書やろ。ｗ
記紀とか聖書とかから現実を語ることはできまい。

**デフォルトの名無しさん** · 2021/02/16(火) 20:43:15.59

自分のそれ関連でレスしておいて何言ってんだか

**デフォルトの名無しさん** · 2021/02/16(火) 20:46:48.66

かと思ったら、以下も何言ってんだかだよ
冗談で逃げただけか？？
マジならお前がそう思うならそうなんだろな、お前の頭の中ではなんとかかんとかw
見損なったのぞお前w

**デフォルトの名無しさん** · 2021/02/16(火) 21:04:42.04

シェルスクリプトスレはいつ見ても
キチ vs キチのマウンティング合戦
サル山でもこうはならない

**デフォルトの名無しさん** · 2021/02/16(火) 21:26:41.96

シェルスクリプトではライブラリに相当するものは外部コマンド

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

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