シェルスクリプト総合 その34 YouTube動画>1本 ->画像>1枚

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

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

シェルスクリプト総合 その33
http://2chb.net/r/tech/1584893550/

関連スレ

【Bash】Windows Subsystem for Linux【WSL】8
http://2chb.net/r/linux/1590742701/

Bashでプログラミング [転載禁止](c)2ch.net
http://2chb.net/r/linux/1443885102/

シェルスクリプト総合 その28
http://2chb.net/r/unix/1533154936/

zsh その７
http://2chb.net/r/unix/1337844883/

【POSIX】UNIXプログラミング【BSD】 [転載禁止](c)2ch.net
http://2chb.net/r/unix/1443103705/

>>1
おっつん

こんにちは
Macでzshを使っています
フォルダに

memo20200810.txt
memo20200817.txt
memo20200824.txt

のようなファイルがあったとして（週に1つずつ増える）
最新のファイルをechoで見たいとしたらどうするのがいいでしょうか？？？

すみませんechoではなくcatでした
別にコマンドは何でもいいので最新のテキストの内容を見る方法を知りたいです

cat "$(/bin/ls *.txt | tail -1)"

ありがとうございました！

ファイルが大量にあった場合には大きい順でソートして1行目を取り出すみたいに書いた方が速くないか？

ただし ls で引数に指定するのはディレクトリ。

>>7
ちなみにlsだけフルパスなのは? lsがエイリアスである可能性を考慮とか?

Unixで「複数のパスを区切る」といえばコロン区切りが普通だと思うんだけど
（例えばPATH，CDPATH，NLSPATHとか）
POSIXの
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03
でも言われている通りコロンが含まれているパスを指定することができない。

もちろん自分で勝手にPOSIXを逸脱して，バックスラッシュでコロンを
エスケープする，みたいなことをしてもいいんだけど，
なるたけ標準に合わせたい。

環境変数で複数のパスを指定するときに，
コロンを含めるようにしているユーティリティの例とか知らない？

PATHがコロン含められないのにコロン使えるようにするの？
チャレンジャーだなｗ

Unixはパスに使えない文字を決めたほうが良かったと思うね
MS-DOS/Windowsはちょっと多すぎだけど

>>13
Windowsだとドライブレターにコロンを使ってるから
PATHの区切りは;ですね。

>>14
シェルスクリプトには関係なくね？

そういや環境変数名に記号とか改行とか使えるの知ってる？ｗ

コマンドの戻り値を反転させたい、つまり0のときは非0に、非0のときは0に変えたいんだけど、どうすれば？
set -e状態のスクリプトで、特殊なコマンドを使いたい場合に。

また、makeで使うときにmake専用の記法(-とか@とか)がもしあればそれも。

>>17
if [ $? -eq 0 ]; then
　exit 1
else
　exit 0
fi

すればいいと思うけど、困ってる点は何？

>>18
set -e状態やmakefile中では、コマンドが終了した時点でエラー中断する。
なので、$?を参照するところまで至らない。

ちなみに、makefileの場合は、次のように一行にまとめてしまえばごまかすことはできるが、set -eスクリプトだとやっぱりダメなもよう。

コマンド; test $? -ne 0

!

>>19
まあ大体そうなんだろうとは思ったが
どういうときにコマンドの戻り値を反転させたいのか気になるけど
処理をmain関数に入れてしまってこれでできるはず

( main ) && return 1
return 0

! ( main ) でも一応良いはずなんだけど ifを使わずにコマンドの頭に
!をつけるだけだと動かないシェルがあった気がする
今回はサブシェルが間に入っているから大丈夫かもだけど

あとは、思いつきだけどこんな感じでも出来る気がする

#!/bin/sh
set -e
trap 'exit $(($? == 0 ? 1 : 0))' EXIT
任意のコマンド

ちなみにmakefileは知らんｗ

0/1の二択なら1から引けばいいじゃんね

set -eでエラー終了した時は$?が1とは限らん

trap 'exit $(($? == 0 ? 1 : 0))' EXIT
trap 'exit $(($? > 0 ? 0 : 1))' EXIT # 一文字短縮化ｗ

>>21
>>22
ありがとう。
コマンドラインの前に「!」を書けばいいのか。
manページを確認すると、「logical negation」とあったから、こちらの期待どおり。

trap 'exit $(($? > 0 ? 0 : 1))' EXIT
これいいね

MirBSDの記事として書き込まれてたけど
このスレの前々スレくらいでもちょっと議論されてた
「ASCII区切り文字による表形式」についての話

https://www.mirbsd.org/permalinks/wlog2020_e20200620.htm#e20200620_wlog2020

>>28
あー、その記事読んだ。FSってフィールドセパレータだと思っちゃうよねｗ
たまたま俺は、レコードとフィールドと、ファイル区切りもいるかなぁ？って
考えながら探してたから、お、4つもあるじゃんって感じで気付いたが

>>16
知ってる。

>>17
シェルによって書き方違うかも知れないがこんな書き方も可能。

if コマンド [引数 ...]
then
　exit 1
else
　exit 0
fi

ほぼ >>18 と同じだが、コマンドを if の直後に書けばそのまま戻り値の判定ができる。

こういう書き方もできる。短い場合はこれでも良いかも。(でも後で見て分かり辛くなるかな?)

コマンド [引数 ...] && exit 1 || exit 0

2行に分けても行ける。exit 1 の方が実行されたら下の行には行かないので。
こちらの方が見た目は分かり易いかな。

コマンド [引数 ...] && exit 1
exit 0

あ。上の方からゆっくり読んで下まで読まずに書いたら途中で色々と話が進んでいたorz

http://2chb.net/r/tech/1537584801/206
この問題のレベル2を実装できないw

レベル1は
foo() { set -- $2 $1 $(shift 2; printf ' %s' "$@"); bar "$@"; }
↑こんな感じのが正解の一つだと思うんだが，
これだと
foo 1 2 3 4 '5 includes space'
という引数を指定した場合に
$ foo 1 2 3 4 '5 includes space'
begin
2
1
3
4
5
includes
space
end
というような出力になってしまう。

age

シェルスクリプトマスターしてしまったので
シェルスクリプト難しいって言ってる人が
何が難しいのかわからなくなった

シェルスクリプトが難しいんじゃなくて
初心者だから難しいだけなんじゃ？

>>33
age

>>33
いくつかやり方があると思うがヒントな

位置パラメータが 1 2 3 4 5 の状態から
1 2 3 4 5 2 1 3 4 5 を作り出すことができれば
あとはshift 5をするだけで
2 1 3 4 5 にすることができる

この問題を解くカギは、終了条件をどうするか？なんだよ

>>37
Thx
考えてみる

補足 わかると思うけど

この問題を解くカギは、「ループの」終了条件をどうするか？なんだよ

>>37 >>40
ちなみに >>33 の解答でも
setやshiftを使ったりしてうまいこと
引数処理をしてはいる。

もう自演にしか見えないw

前スレ止まってると思ったら埋めずに分裂してたんかい

>>41
できたかニャ？

>>44
できた。
結局 >>37 のヒントには全く頼らなかったわw

eval "set -- \
$(printf "'%s' \\\\\n" "$2" "$1"
shift 2; while [ $# -gt 1 ]; do printf '%s\n' "$1" |
sed "s/'/'\\\\''/g;1s/^/'/;\$s/\$/' \\\\/"; shift; done
printf '%s\n' "$1" |
sed "s/'/'\\\\''/g;1s/^/'/;\$s/\$/'/")"

申し訳ないですが誰か教えてください。
以下のような感じで処理をしたいのですが
a.sh(rootで実行)
#!/bin/bash
#処理
#postgresでb.shを実行
su - postgres -c "bash パス/b.sh `$1`"

echo "b.sh完了"

#testでc.shを実行
su - test -c "bash パス/c.sh"
echo "c.sh完了"

exit 0;

b.sh(postgres)
#!bin/bash
#複数処理
exit 0;

これをやるとb.shの一番最初の処理は実行できるのですが
２番目の処理からがエラーで実行できません。
postgresにてb.sh単体で処理を動かすと問題なく動かすことが出来るのですが・・・

このb.shをrootのa.shからpostgresのb.shを呼ぶ方法を教えていただけないでしょうか。
またシェルを分けずに、一貫してやった場合てどうやって途中でユーザ切り替えするのでしょうか？
申し訳ございませんが教えてください・・・

>>46
なんとなく
"... `$1`"のあたりが原因なような気がする。
この状態だと引数の実行結果が空白区切りでb.shに渡される。

二番目の処理のエラーは見せられない感じ？

>>47
[root@test-srv test]# ll
合計 8
-rwxrwxrwx 1 root root 216 9月 8 11:46 a.sh
-rwxrwxrwx 1 postgres postgres 115 9月 8 11:44 b.sh
[root@test-srv test]# cat a.sh
#!/bin/bash
echo "a.shの処理を開始します。"
echo "a.shのテスト出力、引数は${1}です。"
echo "b.shを実行します"
su - postgres `/home/postgres/work/work/test/b.sh ${1}`
echo "a.shを終了します"
exit 0;
[root@test-srv test]# cat b.sh
#!/bin/bash
echo "b.shの引数1は${1}です。"
echo "b.shのテスト出力です。"
echo "b.shのテスト出力です。"
exit 0;
[root@test-srv test]# ./a.sh test
a.shの処理を開始します。
a.shのテスト出力、引数はtestです。
b.shを実行します
-bash: b.shの引数1はtestです。: そのようなファイルやディレクトリはありません
a.shを終了します
[root@test-srv test]#
少し処理を変えた結果もこんな下の感じです。
[root@test-srv test]# ./a.sh test
テスト: 引数1はtestです: command not found
これはテストです

`/home/postgres/work/work/test/b.sh ${1}`

` じゃん

su - postgres b.shの引数1はtestです。

をしようとしてるじゃん、
-bash: b.shの引数1はtestです。: そのようなファイルやディレクトリはありません
のメッセージの通りじゃん？

いったい何がしたいんや？
バッククォートは何のため？

>>49
すみませんが、知識が貧しいので
詳しく教えてください・・・

>>50
単純にrootでa.shを叩いたら
postgresユーザでb.shが引数付きで呼ばれるようにしたいて感じです。

その処理がいまいちうまく組めないのです・・・

` で囲んだのは、その時点でそれが実行されてその出力に置き換えられる。$() はほぼ等価
su - postgres `/home/postgres/work/work/test/b.sh ${1}`
は
su - postgres b.shの引数1はtestです。
をやろうとしてる(b.shの引数1はtestです。に b.shのテスト出力です。もあるけどな)

だから、
-bash: b.shの引数1はtestです。: そのようなファイルやディレクトリはありません
というメッセージなんだよ
su - postgres b.shの引数1はtestです。
をしようとしてるんだから

やりたいのは、
su - postgres `/home/postgres/work/work/test/b.sh ${1}`
ではなくて、
su - postgres "/home/postgres/work/work/test/b.sh ${1}"
とかだろう

>>53
出来ました！
su - postgres -c "/home/postgres/work/work/test/b.sh ${1}"
という形でした。
ありがとうございました！

ちゃんとメッセージ見ような。だいたいにおいて正しく問題点が書いてあるんだからw

>>54
参考までに聞いてみたいが、なぜバッククォートを使おうと思ったのか？
クォートならどれでも同じだと思った？

>>55
バッククォートの機能を知らずに使うと、エラーメッセージを見てもわからんやろな。

だが、typoでもよくみるメッセージだからな
それを実行しようとしてる、なぜなんだぜぐらいから始めないとな

ブログはクォート関係はよく文字化けする

cshやAndroidにも対応した上で
POSIXに準拠したシェルスクリプトの書き方
（cshの場合はshで起動し直すらしい）
https://togetter.com/li/1077808?page=5
ここまでやる意義は不明w

>>59
それは読んだことがあるが
どうももやもやしている

どういう環境でそれが必要なのかが書いてないからかな？
Androidといわれてもー
バージョンわからないしー
検証環境用意できないしーｗ

読んでて思うのはtogetterはツイートをまとめるだけなので
検証内容をまとめるには適してねーわ

>>60
同意。
「結局なにが分かったのか」
「解決方法はどうだったのか」
っていう，一番重要な情報もめちゃめちゃ
みにくいところにある。

しかも，まとめ主は
「あとで記事にする」と言っているのに
その後音沙汰がないし
アカウント乗り換えてる模様。
怪しすぎる。

>>61
あとなんかシェルによってシバンの扱いが違うように書いてるように見えるんだけど
シバンを解釈するのてOSだよね？
他の言語から起動することもあるんだから
シェルはOSに丸投げしてるだけ

だれかもうずばっと シバンはちゃんと書きましょう。
shを使うなら #!/bin/sh です。このパスがない環境はもうありません
って言ってくれないかな？ｗ

真偽不明でタイトルだけ残ってて困る

>>63
ちょっとつっかかるけど
「このパスがない環境はもうありません」
これも根拠なくないか？

POSIXでは定められていない訳だし，
Solarisだと/bin/shはめちゃめちゃ古い。
POSIX shは/usr/xpg4/bin/shにある。

#!/usr/bin/env sh

>>65
より非可搬。
詳細は前スレ参照。

たまたまSolarisの環境があるから調べてみたが、

> Solarisだと/bin/shはめちゃめちゃ古い。
これはSolaris 10以前の話。古いというかPOSIX以前のBourne Shellだな。
これがSolaris 11ではkshに変わっている。

それからシステムの初期設定PATHと
getconf PATHは必ずしも同じではない

Solarisのシステムの初期設定PATHは/usr/sbin:/usr/binなんだが互換性上の理由（？）で
POSIXに準拠してない可能性があるコマンドが入っていると考えて良さそう
getconfはPOSIX準拠のコマンドということもあり、getconf PATHもPOSIX準拠のためのPATHを返す
例えば /usr/xpg4/bin/ が優先されている。ただし /usr/sbin は入ってない。Linuxでも/bin:/usr/binしか返ってこないな
だから PATH=$(getconf PATH) なんかしてしまうと fdisk が使えなくなったｗ
ちなみに /bin はどちらのPATHにも入ってない

getconf PATHをどう使うかもOS依存な気がするけど、Togetterまとめに書いてあるように
PATH="$(command -p getconf PATH):$PATH"
こうすることで、標準を壊すことなくPOSIX準拠に近くするという意味になるんだろう
ちなみにだけどcommandの-pオプションは古いzsh（たしか4.0あたり）で使えなかったりするけどなｗ

個人的にはgetconfがない環境があるのは知っていたので、そこは何も不思議はない
Togetterまとめに書いてあるPATHの初期化方法は何をやりたいのかよくわからんｗ
なんつーか一行にしようとして意味不明にしてるとしか思えんな。こんなんでいいやろ？

default_path="$(command -p getconf PATH 2>/dev/null ||:)"
[ "$default_path" ] && PATH="$default_path:$PATH"

↑でこれはシバンがないほうがいいかどうかとは全く関係ない話
まぜるなや

宇宙刑事シバン

>>67
Solarisで
$ getconf PATH
するとPOSIX準拠の命令が優先されるような
設定が返ってくるのな

勉強になった。さんきゅ〜

>>67
ちなみに棘でもzshのcommand -p非対応については
触れられてたな。

あきらめてhash使ってたが。

>>71
command -p （もしくはただのcommand）って
シェルで微妙に動作が違うんだよな

ちゃんとまとめてないからきっちりとは言えんけど
例えば dash や ksh だと command -p printf --help は
ビルトインコマンドが実行される

zshだと外部コマンド
zsh で command -p : がエラーになるのはそのせい

なんで昔の人って

command ・・・ 外部コマンドを実行する
builtin ・・・ ビルトインコマンドを実行する
function ・・・ シェル関数を実行する

みたいに全部作ろうと思わなかったんだろうな？
ユースケースを思いつかなかったということなんかな

zsh
% type command
command is a shell builtin

https://linux.die.net/man/1/zshbuiltins
command [ -pvV ] simple command
The simple command argument is taken as an external command instead of a function or builtin and is executed. If the POSIX_BUILTINS option is set, builtins will also be executed but certain special properties of them are suppressed. The -p flag causes a default path to be searched instead of that in $path. With the -v flag, command is similar to whence and with -V, it is equivalent to whence -v.
See also the section 'Precommand Modifiers'.

zshにしたら今まで使ってたbashがぶっ壊れることって結構ありますか？

bashがぶっ壊れるって何？
両方入れるだけでしょ？

bash消してzsh入れるっていうのならぶっ壊れる可能性が高い
もしくは最初からbashが入ってない（必要ない）システムを使うとかね
例えばdashを採用しているdebian/ubuntuとか

そういうシステムでもdashを消してzshにしたらぶっ壊れる
zshをPOSIXモードで実行すればワンチャンあるかもしれんけど

bash用スクリプトはzshで動かすことを考えて作っていない限り動かない
sh用スクリプトであってもzshでは動かない可能性がある

カタリナにしてからmacのターミナル起動するたびに出てくる
`chsh -s /bin/zsh`って実行したらbash使えなくなるよね？

>>73
zshを基準に見ているからそうなる。

シェルとコマンドの関係はOS依存たぞ

>>79
意味不

>>80
意味不ｗ

>>78
ならない。
macは最初からbashとzshの両方がインストールされてる。容量の無駄遣い
macOSでbashは/bin/shとして使われてる。Debianで使われてるdashよりも重い

最新のbashは5系だがmacOSの/bin/shのbashは3系で古い。
ライセンスのせいで新しいbashにアップデートできない
しかしPOSIX準拠のdashにしようと思っても
bash依存してるスクリプトがあって互換性の問題が出るからdashにもできない

つまりmacOSの/bin/shはPOSIX準拠のdashでもない上に
古いbashという中途半端な状態

>>77
> `chsh -s /bin/zsh`って実行したらbash使えなくなるよね？
さっさと実行しろ。どうせシェルスクリプトの類はbashで動く
明示的にしていて無い限りmacOSでは古いbashでスクリプトを動かすことになる
最新のbashの機能も使えない

>>81
コマンドについてはデフォルトのシェル用に作られたものを、別のシェルでは動きを変えて対応している。

だから同じ名前のシェルでもOSが異なれば、動きが変わる。

Linuxのshはbashがsh風に動かしているだけで、いろんなところがshではない。

>>84
それが>>73のレスと何の関係があるの？
どういうつながりでそういう発言をしたのかを聞いてる

>>85
UNIXは体系的に作られたものではないということ。

それぞれが他人によって作られ、それらを統合しているため、一貫性がないのが普通。

細かい規格も存在していないので、コマンド、スクリプトは環境に依存する。

>>86
だからそれが何の関係があるの？

>>87
>>73
後出しの思い付きを垂れたからやろ。

なんでだろう？→疑問に思うな！

思考停止か

>>86 って言ってるのに、疑問に思うな思考停止とか読めないやつなんだろな

そもそもUNIXは、たまたまこうなったんじゃなくて、合理的な理由があるんだけど、なんでそれを知ろうとしないの？

UNIXはこういう思想で物を作ってますと宣言してるのに。

いやー、たまたまやろ。
根っこにポリシーはあっても、それ以外はかなりのいきあたりばったり。

>>92
それな。"$1" みたいにダブルクォートでくくらないといけないのは
明らかな仕様の失敗だって言われてるし
他の言語と同じようにPOSIXシェル以前やBourneシェル以前との
互換性をある程度保ちながら改良を続けてきた
必ずしも合理的な理由があるわけじゃないよ。作者がたまたま必要だった
必要と思いつかなかった。それだけだろ

>>93
二重引用符で囲まない場合，
どういう利点があるの？
あとそれを説明した記事とかある？

>>94
> 二重引用符で囲まない場合，
> どういう利点があるの？
ない

やりたいことはevalで代用できる

ぬるぽ

>>94
あるというか、そうしなければならない場合も。
引数がなかったときに、クォートされてると、空文字列になってしまうので、意味が変わる。

make $1
みたいなスクリプトだとクォートしてはいけない。

>>97もクォートしないと駄目。嘘を教えるな

>>98
試してから言え。
簡単に嘘呼ばわりすんな。

>>97
だと makeに "install uninstall" という文字を渡すと
エラーにならずに実行できるから駄目
試さなくてもわかる

>>100
じゃあ引数がないときは？

>>101
引数がないのに$1を参照してたら

bash: $1: 未割り当ての変数です

っていうエラーが出るだろ
アホかｗ

>>102
でねえわ。
-uを前提にすんな。
クズ。

>>103
お前のようなやつが rm -rf "$path/" とか書いて痛い目見るんだろ
ベストなやり方前提にしろ。ベストなやり方で使えない方法を持ってくるな

>>104
勝手に-uをベストに決めつけんな。クズ。
オプションは使うべきときに使え。クズ。

makeみたいな、引数の有無で挙動が変わるコマンドがあって、考えなしに変数をクォートすりゃあいいってもんじゃない、って話をしてんだよ。クズ。

考えなしにクォートしなかったから
バグが増え危険なコードになってんだろが

ガッ

make組のｽｸﾂか

ガッ
なコード書きたいただの甘えん坊だな ID:GM+a9m1V は

>>108
lsでも同じ。

シェルスクリプト書くうえで、
command
command arg
どちらも(前にチェック無しで)書きたいなんてほとんどないだろうに。ほとんどないのはあげつらってるのはお前だけという点で明らかだな

ls で言えば
ls target
ls
結果が違うんだから目的も違う
ls ''
でエラーになる方が大体の目的にあっているだろうにとしか思えない

>>92
だから、そう説明してるんだよ。わざわざ作り直したり、同じようなものを作らないのがUNIXの考え方。

>>111
文盲どもめ。
もともと頻度の話ではない。
クォートしないことにも意義がある、というだけ。

実際、既存コマンドのラッパーみたいなものを書くときなんかでは活用できる。

そこでPlan 9 rcですよ。

引用符の種類が一つしかない。
そしてクソほど使いにくいw

>>113
文盲と他人をあげつらってるくせにの文盲はお前じゃ
>クォートしないことにも意義がある
誰も意義がないなんて言ってないだろが

発端は
>それな。"$1" みたいにダブルクォートでくくらないといけないのは
>明らかな仕様の失敗だって言われてるし
だからな。その流れ中にクォートありだけをあげつらっている(？)のは、クォートしないことにも意義があるじゃなく読まれてもしょうがないな

失敗だって言われてるってその例では「全く」wピンと来ないが、

今時名前の中にスペースが入っているの当たり前で、ほぼ必ずダブルクォートで囲まなければならないのがメンドくさいのは確かだな
逆(単にダブルクォート有無の動作が逆ではなく、ダブルクォート無しでもダブルクォート有りの動作、IFSで分かつなら別の表現)っていうのならわかるが、失敗というほどでもねえなとも思われる
多分、伝わってないのは、そういうことだよw

>>115
違うわ、文盲。
>>94
これ。

>>117
話には流れがあるんだな
で、お前の言うことには言うほどでもないってこともあるだろう、そのしつこく延々と>>94にたいしてって言うのは。自分で案に認めてるように 頻度 はそうないらしいしw
文盲の意味を履き違えてるなwてかよくわかってないだろう

$1と書いてるのに$1がないとみなされるのは
利点ではなく欠点

>>119
シェルの変数は、ただのテキスト置換なレベルだからな。
今さらそんな理想を言っても始まらん。

>>118
いや、あきらかに文盲であることがはっきりした。ｗ

>>120
> シェルの変数は、ただのテキスト置換なレベルだからな。
それはウソ

>>121
流れに関係なく、俺の突然言い出したことを理解できないのは文盲というのなら、お前から見たら文盲なんだろな
文盲という意味(厳密な意味じゃない)を理解してないアレだと俺は思うけどな
っていうことで明らかに終わりだな、その投げやり言い放ちだけのレスでw

仮にお前が賢い人間だとするじゃん
仮に相手が馬鹿な人間だとするじゃん
その場合だと争いにならないわけだから争いになってるということはその過程は合っていなかったわけだね
つまり
お前らは馬鹿だってことさ

>>122
コードをどう解釈するのかはシェル内部の仕様。

変数名を文字列として指定し、文字列で指定された変数の値を参照する仕組みもシェルの仕様。

これは結果的にわかりにくい表現、使ううえで間違いやすい仕様として認識されている。

UNIXはたいしたことない欠点をあとから変更する文化はない。

マイクロソフトのように次から次へ新しいものを作っては捨て、作っては捨てということはしない。

単に互換性のために修正できないだけ
欠点は欠点。修正できない可哀想
だからPOSIXに新しい言語も追加できない

> 変数名を文字列として指定し、文字列で指定された変数の値を参照する仕組み
ウソ

行為主体(発言主体)の意思ではなく事柄の客観的事実に言及したいのであれば、「ウソ」ではなく「間違い」「事実ではない」といった言葉を用いるべし

わかってていってるからウソだろう

だろうおじさんでしたか...

本人が否定しなければウソだということ

>>126
そうね。でもそれで大成功をおさめているのがUNIX系。もうすべてがUNIXになりつつある。WindowsのUNIX化もとまらない。

そもそもシェルスクリプトに不満があるのなら、別のスクリプト言語を使えばいい。

仕事でシェルスクリプトを触りはじめたけどすぐに地雷を踏む

macのローカルで作ったシェルをLinuxで動かしたら悲しいことになった

>>132
> そもそもシェルスクリプトに不満があるのなら、別のスクリプト言語を使えばいい。
/bin/shが他のスクリプト言語になることなんてあるんか？
最小構成で他のスクリプト言語が含まれることなんかあるんか？
POSIXが改定して別のスクリプト言語が使えるようになることなんてあるんか？

現実的にありえない話をしても意味がない

>>133
まあ初心者さんは何でもそうだよね

>>134
だからPOSIX準拠しろって話だ

>>133
例えば？

>>133
ワナだらけだからね。
しかたないね。
本当に。。。

自分が無知なのをごまかすためにわなと言ってる

>>135
じゃあPOSIXなんか無視すりゃいいんだよ。
自分で好きなのをインストールすれば。

poshが普及したりはしないかな？ｗ

自分は良くても他人のイメージを使うときに困るだろ

posh？好きなら自分でイントールしてろｗ

>>140
そのposhとかいうのをmacにインストールしたんだが

$ cd /
posh: cd: too many arguments

で動かないんだがｗｗｗ

こんなバグソフト普及するわけねーだろｗｗｗ

poshを終了しようとして

$ exit
posh: exit: bad number

ｗｗｗ

>>141
POSIX互換ならなんでもすべて同じ、ではないから、そんな配慮はムダ。

>>142
ツンデレだな？ｗ
まあがんばれ。

https://hoge1http://hoge2https://hoge3
を
https://hoge1
http://hoge2
https://hoge3
にしようと、sedやperlワンライナーで頑張ってみたけど
https://hoge1http://hoge2
https://hoge3
にしかならないです

どうやればできますか？

>>144
全て同じではないから/bin/shはdashかbashしかありえない

PS > "https://hoge1http://hoge2https://hoge3"; -split "http"| %{if($_ -ne ""){"http" + $_}}
https://hoge1
http://hoge2
https://hoge3

>>145
echo 'https://hoge1http://hoge2https://hoge3' |
sed -e 's/https\{0,1\}:\/\//\
&/g'

いけるけど？

>>135
シェルスクリプトで全部やるなんて言われたら、バークレー校出身者もびっくりだわw

https://mrsh.sh/
A minimal POSIX shell

>>150
This project is a work in progress.

はい撤収ｗ

>>149
今話をしてるのはシェルスクリプトでやることの話だろ

よくわからないのが、シェル関数や外部プログラムを作って、呼び出せばいいんじゃないの。

シェルスクリプトの見た目がどうこうという話は不毛だよ。

シェルスクリプト（の文法）に不満がある
→別のスクリプト使えばいい。あちこちに頼んで入れてもらえ

馬鹿なの？
どこにシェルスクリプト以外のスクリプト言語が
予めインストールされている世界があるというのか
現実を見たほうがいい

>>154
「予め」とか言ってるのが馬鹿。
自分でインストールしようと思えばする。
でなければしない。
それだけ。

だから他人が作ったイメージでは無理だろ
なんでもroot持ってると思うな

>>154
そのOSの基本シェルがインストールされていないわけがない。

そもそもシェルがなんなのかわかっているのか？

>>154
だからシェルスクリプト以外を使えないだろって話をしてる

間違え

>>157
だからシェルスクリプト以外を使えないだろって話をしてる

>>147,148
ありがとう

>>147
PS？？？は初見だったんで調べてみます

>>147
先頭のhttpを除外しようと、頭が固くなってた

>>160
PSはPowerShell、Windowsのやつなので関係ない
調べるだけ時間の無駄

>>151
え，開発途中だったら興味ないの？

開発断念には興味ないよｗ

>>161
助かりました

>>164
いえいえ

お前じゃない

>>163
This project is a work in progress

>>167
コミット見てみ。もう飽きてる。

>>168
そんなことわかるなんてすごいね。

>>159
そもそもおまえはUNIX、Linuxをインストールしたことがあるのか？

かなり不思議なことを言っているぞ？

sedやawkは何か説明できる？

Ubuntuのインストールを学ぶべき。

Linuxをインストールしたら、Perlもデフォルトでインストールされることも知らないんだろうな。

そもそもシェルの概念がわかってないと、シェルスクリプトがシェルのスクリプトだとおそらく理解できない。

別にシェルからすれば、シェルスクリプトではなく、実行ファイル形式を橋渡ししてマシン語でやり取りしてもらってもかまわない。

ただし、UNIXは既存のものの組み合わせでできるのであれば作らないという思想なので、C言語でゴリゴリ作るやつは批難される。

>>172
デフォルトって何？ｗ
Perlはインストールされなくてもおかしくないやろ。

>>173
ゴリゴリつくるヤツがいたから、Gitが存在するんやで！ｗ

Linux業界に「思想」なんかない。
あっても、何かの拍子にコロッと変わる。
あんまり真に受けないほうが。

Windows10, WSL, Ubuntu 18.04 では、最初から、Python3 も入っている。
anyenv, asdf などで、Ruby, Node.js などの好きなバージョンも入れられる

file `which python`
/usr/bin/python: symbolic link to python2.7

file `which python2`
/usr/bin/python2: symbolic link to python2.7

file `which python3`
/usr/bin/python3: symbolic link to python3.6

>>175
>>173はUnixの話をしているのに，
Linuxの話にすり替えるべきじゃないな。

「Linuxの思想はない」かも知れないが，
>>173が言っているのはUnix哲学だ。

>>174
おまえは画面まっくらで、いくらキーを打っても何もできない状態で使うのか？

組み込みならわかるんだか。

>>177
あのさ、LinuxはUNIXをPCアーキテクチャのハード用に、初めは個人が作ったものなんだよ。

UNIXの仕様が完全にはわからなくて、Linuxは少し異なるものになってしまった。

だから、LinuxはUNIXでないと説明される。しかし、UNIXの定義はPOSIX程度しかないため、UNIXから見ればLinuxもUNIXに含めてもいいかなあレベルになる。

>>175
あのね、Linuxはレッドハット社がほぼ標準を決めていて、基本的なところが大きく変わることはない。

あなたの言っている部分は枝葉の部分。

実際に存在するLinuxの話をしましょうよｗ

$ docker run -it alpine
/ # perl
/bin/sh: perl: not found
/ # python
/bin/sh: python: not found
/ # pyton3
/bin/sh: pyton3: not found
/ # ruby
/bin/sh: ruby: not found

>>177
であれば、ほとんど死んだようなOSの哲学を語ることに現実の意味はない。
考古学者以外は。ｗ

Alpine は、5MB しかない。
何も入っていない

それに、Ruby on Rails, Node.js などを入れて使うもの

>>178
サーバー用最小ならおかしくない。

まさかデフォルトって、GUIデスクトップ用のことを言ってないよなあ？

>>184
おまえさ、CUIの画面があるのがあたりまえだと思っているだろ？

CUIそのものがシェルなんだよ。

コンピューターの仕組みを理解していないのにいちいち見当違いのことを書くんじゃない。

>>185
だから何？

>>186
自己紹介乙。ｗ

Perlが入ってないLinuxがあるってこともしらんのか

しかも有名でよく使われてるディストリ

揚げ足取りは久しぶりに

>>178
どうしてperlかなかったら画面真っ暗で文字が打てないわけ？

シェルがなかったらと書いてあるだろ。
しつこいけどシェルは人間とのユーザーインタフェースだよ。
シェルがなければ人間は何もできない。

コンピューターは必ずCUIの画面があると思ってしまうのだろうか？

言葉遊びには意味がない。

シェルはLinuxに必ずインストールされているが
Perlはインストールされてないものが実際に存在し使われている

話はこれだけだろ

>>192
お前コミュ力なさすぎ…
perlがインストールされてなくてもおかしくないってレスに対して、
なんでシェルがなかったら画面真っ暗なんて回答になるんだよ

このスレの人ってどうでもいい事になんでこんなすぐ必死になるの？

>>197
そしてなぜ黙ってればいいのに
こんなことを書き込んでしまうの？

真面目で、相手の誤りを修正してあげたいから。
バカで、自分の誤りを認識できないから。

とか、人それぞれに理由があるやろ。
まあ、最大の理由はヒマだから。ｗ
おまえもな。

>>196
デフォルトというのはLinuxだったら、bashシェルがインストールされて起動するということ。PerlはLinuxの大半のインストーラが標準設定でインストールしてしまう。

>>200
もとの話とつながってないぞ！ｗ
やりなおし！

>>200
bashがインストールされてない環境はあるし実際によく使われている

これ何の話だっけ。
「シェルが存在せずにPerlなどが存在する環境」
と
「シェルは存在するがPerlは存在しない環境」
の比較？
いや，違うのかもしれないが，
だとするとPerlがどうとかいう話がどこから出てきたのか分からんw

これだろ？

172 名前：デフォルトの名無しさん[] 投稿日：2020/09/13(日) 21:07:19.31 ID:Z+zAoG6v [4/5]
Linuxをインストールしたら、Perlもデフォルトでインストールされることも知らないんだろうな。

200 名前：デフォルトの名無しさん[] 投稿日：2020/09/15(火) 15:48:33.27 ID:Yms7aROo [3/3]
>>196
デフォルトというのはLinuxだったら、bashシェルがインストールされて起動するということ。


perlもbashも入ってない環境が実際にあってよく使われている

極論が好きな人が居るねぇ
root権限でのパッケージ導入を依頼するでもOS/ディストリビューションの選定提案をするでもVMを生やすでもコンテナを建てるでも何でも使える手は使って、自分の手段と環境の中で一番楽な地獄を使うのがいい
手を尽くしてもシェルスクリプト以外使えないか、手を尽くすのがダルいならそりゃそのままシェルスクリプトを使うしかないのはそれはそう
ただ現代においてシェルスクリプトしかスクリプト言語を使えない上に新規導入もできない案件が多数派だし普通だよって言われると本当？って思うしその立場に同情するまである

最近はコンテナ系がはやって、ガチガチの最小構成も現実的やろ。
昔なら、とりあえずあれこれ入ってるし入れるのがふつうだったが。

>>206
これ

>>197
1つの道具しか使えない人や1つの道具への依存度の高い人は
その道具の必要性を下げる話や短所を指摘されると
無意識に自分の存在意義を否定された(攻撃された)と感じるので必死になる

特定の道具への精神的依存度の高い人たちが集まってる所ではよくあること

>>206
そういう時はGoで書いてもいいよね？

コンテナ向け最小構成ならそれこそコンテナ生やせばいいじゃん…

>>210
PerlコンテナとかPythonコンテナとかつくるの？
粗なの？密なの？ｗ

>>209
C++23で書こう！ｗ

しかし、今さら使いやすそうになってきたな。。。

>>209
ほんの数行で作れるシェルスクリプトの代わりに
goを使うのは手間がかかりすぎる

なんでもPython、なんでもPerl、なんでもGoっていうのは
単に勉強したくないだけなんだろうなって思ってる

Goがやろうとしてる「どこでも動く！，依存性最小！」って
それまさにPOSIXシェルが数十年前から実践してることなんだけどねw

YouTube で有名な雑食系エンジニア・KENTA は、
初心者が進む道を、サーバー側言語のRuby → Go を王道としてる

この2つ以外は、出てこない

GUI 系は、画面の手直しなどで、工数がかさむ。
C#, dot.net などのWindows 系は、いらない。
Java などの土方系も、いらない。
Elixir, Rust は、普及へのchasm・溝を超えられなかった

言語よりも、Docker, Kubernetes, AWS などの、サーバー構築・新規案件を重視する。
上流工程・新規案件の方が、価格交渉力が強いから

>>208
なるほどね〜

コンプレックスの裏返しみたいなものか

「シェルスクリプトで書いていたもの」を他の言語に
置き換えることで楽になることなんてないと思っている

※最初からシェルスクリプトで書いてないものの話ではない

>>211
単芝生やしてるけどそれこそDockerHubにPythonのOfficial Image普通にあるよ
正直お互い想定してる状況が違い過ぎてるような気もするが

1. PythonやPerlが入ってない環境がある
2. シェルスクリプトで実現できる
3. PythonやPerl入れればいいじゃん！
4. PythonやPerlで書き直す
5. コードがシェルスクリプトよりも面倒になってる

ほとんどがこれ
シェルスクリプトで実現できることを
他の言語で書いたら余計面倒になる

面倒になるのに他の言語で書こうとするやつは
単に（効率的な）シェルスクリプトを勉強したくないだけ

はしゃいでるところに水を差して悪いけどシェルスクリプトに必要な心得ってなんですかね？
素人ながらとりあえず動く物は作れたけどifだらけのクッソ汚いコードなんで修正したい
オプションもgetopts知らずにifと[[でなんとかしてる
bashの基本は押さえたけどLinuxの常識までは網羅できてないんで

ifだらけだからクソ汚いってことにはならない

もしキレイなコードとやらを知ってるのであれば
それをシェルスクリプトでやればいいだけ

>>219
そりゃああるやろ。ｗ
あるからなんなの？
コンテナのまま実運用で使うの？

ほんとに必死だね
よほどコンプレックスが強いんだろうな

シェルスクリプトに固執しないとダメな状況ってそうそうないだろうに

シェルスクリプトに固執っていうか、シェルスクリプトが最善な場合に
シェルスクリプトを使うってだけだよね

>>224
スレタイが読めないの？ｗ
どっちが固執してるんだか。。。

>>221
入門UNIXシェルプログラミングという名著を読めばよい。

>>226
シェルスクリプトと、コマンド、外部プログラムの呼び出しはシェルスクリプトではないからな？

シェルのスクリプトだから、シェルスクリプトの構文だけの話をすると、このスレは過疎化すると思うぞ。

だからといって外部コマンドのオプションやら文法の話をしたって意味ない
そういうのはmanページ見ろで終わる話

シェルスクリプトにこだわることの是非はともかく，
このスレに住み着くのは理があるわけだけど，
一方でPythonやRubyに固執している人が
このスレに居座りつづける理由が不明。

このスレはシェルスクリプトのことを話すスレなんだから，
Perl，Python，Ruby，Goなんかにこだわってても
ストレス溜まるだけだと思うんだけど……。
しかも不毛だしw

>>229
過疎化してなにか問題あるか？
シェルスクリプトの構文で質問がある場合は
ageればいいだけだし，
技術系のスレは勢いがなくても一定数の閲覧があるんだから
それで全く問題ない。

もしかしてなんJとかその辺りと同じような考えで
「過疎化する」=「悪」みたいに捉えちゃってる？

シェルスクリプトとPythonやRubyの使い方は全く違っていて
シェルスクリプトの代替にはならないんだよ

だってPythonやRuby言語がシェルになるかい？
そういうのもあるみたいだけど使わないだろ

lslの代わりにPythonやRubyの関数を使えってことだよ
やるかい？

シェススクリプトはそういう手作業の操作をスクリプトにまとめたもので
「手作業の操作」そのものであることに価値があるんだよ

× lslの代わりにPythonやRubyの関数を使えってことだよ
○ ls -alの代わりに

シェルスクリプトを使わないほうがいいケースや使うべきでないケースを判断出来ないようなやつは技術力が低くて使えない

だからリアルでは軽んじられる
その反動がネット上でのマウンティング合戦

不毛なマウンティング合戦を繰り返すスレを見たらリアルでは相手にされない人達だと思って反面教師にしつつその技術への依存度を下げるといい

>>235
シェルスクリプトを使ったほうがいいケースや使うべきであるケースを判断出来ないようなやつは技術力が低くて使えない

だからリアルでは軽んじられる
その反動がネット上でのマウンティング合戦

不毛なマウンティング合戦を繰り返すスレを見たらリアルでは相手にされない人達だと思って反面教師にしつつその技術への依存度を下げるといい

>>223
当然その他個別に必要な要素はDockerfileに書き出すけど、実運用でコンテナを使えるのがDockerHubやオーケストレーションツールを含めた現代コンテナ運用の強みだし革新性だと思ってるよ

なんていうか「シェルスクリプトの文法や仕様が嫌い過ぎてシェルスクリプト数行で済むものにも別の言語を導入して書こうとする1byteもシェルスクリプトを書きたくない人間」に対してシェルスクリプトの可搬性や有用性・必要性を説こうとしてる人と
「シェルスクリプトの文法や仕様でウッとなってしまう嫌な部分が出てくるような複雑さ・処理対象・処理内容の、シェルスクリプトで扱うのにある意味不適な案件がある人間」に対して別の言語や環境で扱うのも選択肢だよって説こうとしてる人が争ってる感

格言「すべての道は、Vagrant に通ず」
Homebrew が、何十年も他の言語で書かれないわけ

つまり、システム構築運用は、できる限りRuby で書く。
シンプルなものに限って、シェルスクリプト

このスレのおかげでシェルだけでWebサイト作れました！
RubyやPythonなんて学ぶ価値無いですね

>>235
PythonやRubyを使わないほうがいいケースや使うべきでないケースを判断出来ないようなやつは技術力が低くて使えない

だからリアルでは軽んじられる
その反動がネット上でのマウンティング合戦

不毛なマウンティング合戦を繰り返すスレを見たらリアルでは相手にされない人達だと思って反面教師にしつつその技術へ

こうですか？ 分かりません！

いいかげん下らなくなってきたけど，ともかく
「シェルスクリプトにこだわるな！ Python・Rubyを使え！」
という主張は同時に「Python・Rubyにこだわっている」わけなんだから，
いくら「こだわり」をバカにしてマウント取ったところで，
ものすごい勢いで自分に跳ね返ってくるだけっていうねw

え、両方使いなよって主張じゃないの？
そういうレスした本人じゃないから知らんけど

>>237
> 「シェルスクリプトの文法や仕様でウッとなってしまう

それってようするにオブジェクト指向言語にそまってて
関数型言語に抵抗があるやつと一緒なんだわ

パラダイムが同じならそれもわかるけど、シェルスクリプトは異なるパラダイムなので
単に異なるパラダイムのものをつけつけられないだけ

>>238
HomebrewのインストーラーをRubyからBashに書き直しました！
https://itchyny.hate
nablog.com/entry/2020/03/03/100000

> 将来的にmacOSデフォルトにRubyやPythonが含まれなくなる (参考リンク)。

こうなる

>>237
シェルスクリプト自体に文句があるのはしゃあない(つーか、ないヤツはおらんやろｗ)が、全否定したらこのスレではただのあらしでしかない。
さらに、最近の一部のヤツはとくにバカっぽかったからな。

状況に応じて使う道具を変えなよって言われてるのに、PythonやRubyを持ち出して否定したがるのはそれらを使えないことへのコンプレックスが強いから

どの技術でもその限界や短所を理解してないやつが多ければ要注意

シェススクリプトへの文句というより
シェルスクリプトが改善されないことに文句がある
何年停滞してるんだ

ハーバード大学には、Ruby on Rails の授業がある。
他の言語だと、数年以上遅れて、その間にシェアを取られてしまうから

他の言語では、複雑さが並みじゃないから、簡単に作れない。
かなりの費用・期間が掛かるから、そういうプロジェクトを起ち上げられない

例えば、Ruby以外のプロジェクトで、半年過ぎると取りやめになる。
サーバー側言語では、Ruby, Go しか使われない

PythonとかRubyみたいな簡単な言語使ってる雑魚がイキってるのマジで笑える

例えば、Ruby の数値リテラルには、_ を含めることができる

1_000_000_000 # 1000000000
0xffff_ffff # 0xffffffff

この機能がないと、下みたいに、コメントを書かないといけないし、確かめるのも大変

1000000000 # 1_000_000_000

Ruby では、こういうように、バグを減らす工夫をしている。
だから、こういうことを思いつく日本人は、smart だって言われる

>>243
どこの誰の事を異なるパラダイムを受け付けられない人間としてるのか知らないけど、パラダイムが異なれば当然向き不向きがあるよね？
その上で私は
> シェルスクリプトの文法や仕様でウッとなってしまう嫌な部分が出てくるような複雑さ・処理対象・処理内容の、シェルスクリプトで扱うのにある意味不適な案件
っていう「シェルスクリプトのパラダイムに向かない作業」を話題の前提にしてる人が他の言語を提案してるんじゃないの？って話しかしてないのよ

「何らかの作業をシェルスクリプトのパラダイムに向かない作業だと感じるのは、そいつがパラダイムを受け付けないだけで不向きな作業だからではない」という可能性は間違いなくある
ただ可能性はあるけれど恒真とは思わない
私がシェルスクリプトに向いてない作業はあると思ってるから
もしあなたがシェルスクリプトに向かない作業なんてないと思ってるなら何も言わない
この先は気持ちの問題なので

ほとんどの人が「別にPythonでもRubyでもいいけど，
そうじゃない選択肢としてシェルがある」というだけの話をしてるのに

「いまだにシェルを使ってるのは時代遅れ！」
「シェルにこだわるな！Python・Rubyを使え！（こだわり）」
となるのはなぜなのか。

あと一部の奴が「シェル最高！世の中にはこれしか要らない！」みたいな
主張をしてるのも問題。

>>250
PerlにもPythonにもC#にも、別の文字ならC++にもある。
Rubyがえらいわけではない。
もうすでにあたりまえ。

>>252
> あと一部の奴が「シェル最高！世の中にはこれしか要らない！」みたいな
> 主張
どれ？
対比でそう返しただけじゃないの。

技術力のある人はシェルスクリプトの短所や限界をよく理解している

Google曰く
If you are writing a script that is more than 100 lines long,
you should rewrite it in a more structured language now.
https://google.github.io/styleguide/shellguide.html#s1.2-when-to-use-shell

GitLab曰く
we recommend staying away from shell scripts as much as possible.
A language like Ruby or Python is almost always a better choice.
https://docs.gitlab.com/ee/development/shell_scripting_guide/#avoid-using-shell-scripts

>>255
全てに当てはまることだけど、理由が書いてないコーディング規約はクソ

そういやユニケージで作られた例のシステム、ユニケージを捨てて
全部作り直したそうだな

同じディレクトリ内にある、yarn.js ファイルを呼ぶラッパーである、yarn ファイル・コマンド
#!/bin/sh
argv0=$(echo "$0" | sed -e 's,\\,/,g')
basedir=$(dirname "$(readlink "$0" || echo "$argv0")")

case "$(uname -s)" in
Darwin) basedir="$( cd "$( dirname "$argv0" )" && pwd )";;
Linux) basedir=$(dirname "$(readlink -f "$0" || echo "$argv0")");;
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
*MSYS*) basedir=`cygpath -w "$basedir"`;;
esac

command_exists() { command -v "$1" >/dev/null 2>&1; }

if command_exists node; then
if [ "$YARN_FORCE_WINPTY" = 1 ] || command_exists winpty && test -t 1; then
winpty node "$basedir/yarn.js" "$@"
else
exec node "$basedir/yarn.js" "$@"
fi
ret=$?

# Debian, Ubuntu では、node ではなく、nodejs
elif command_exists nodejs; then
exec nodejs "$basedir/yarn.js" "$@"
ret=$?
else
>&2 echo 'Yarn requires Node.js 4.0 or higher to be installed.'
ret=1
fi

exit $ret

ユニケージはシェルスクリプトじゃないからなぁ
シェルスクリプトを使って作られたCOBOL用関数みたいなもん

ユニケージを使った途端、シェルスクリプト言語から
COBOL言語に開発スタイルが変わる

シェルスクリプトを始めた頃は
> usp Tukubaiは短期間低コストで企業システムを構築するエンタープライズ向けコマンド群。
> ユニケージ開発手法で利用するコマンド群であり、
https://uec.usp-lab.com/tukubai_man
に便利なコマンドがあるんじゃないか？って思ったんだよ

実際に見てみたら完全にゴミ

> ctail(1) ファイルの末尾n行を削って出力
例えばこれとかhead -n -10でいいじゃんとか

> count(1) 同じキーの行数をカウント
それをawkでやるのがシェルスクリプトでしょとか

そういうのばかりで、

根底に CSVならぬ、空白区切りのファイル形式を使うという前提があって
そのデータ操作するためのコマンド群でしかないことに気付いた

ユニケージのコマンドに絶望した後
クソコマンドをまともにしてやろうと思ったが
クソな理由はコマンドではなくデータ形式だったので
どうしようもないというねｗ

データ形式を空白区切り前提にしなければ、
通常のシェルスクリプトで使うコマンドを使うことになるが
ユニケージのコマンドとは全く異なる仕様になる
直しようがない

一日やってるとか暇か
ユニケージを導入して後悔してるとこならあったぞ
https://www.hands-lab.com/tech/entry/5600.html

>>255
>a more structured language

↑ここがポイントだろうね

ポイント？ なんでそう思ったの？
根拠がないから具体的ではないだけ

どうでもいいんですけど，
シェルスクリプト以外の話題なら他所でやってもらえません？
もちろんシェルスクリプトの存在論も含めて。

テンプレくらい読んでくれよな〜頼むよ〜

長々とどうでもいいこと書き綴ってスレ荒らしてたのお前じゃん

>>264
わかる人にはわかる。
わからない人のほうがその理由を内省するべき。

ただ、Bashは関数と連想配列のおかげで、それなりの構造化はできてるな。
逆に言うと、よっぽどややこしいデータ構造を組むのでなければ、シェルスクリプトでも可、ってことか。ｗ

>>267
分かる人が理由を書くべきだろ
こういう意味不明なこと言うから信用されないんやで

まあ結局
「シェルスクリプトでおかしな書き方をするやつは
Pythonで書こうがRubyを使って メタプログラミング() をしようが
下手な書き方をすることに変わりない」
ってことよね。

シェルスクリプトから○○言語に変更したってやつは
変更した結果どうなったのか、そのコードを見てみたいんだが
シェルスクリプトで一体何をしていたのか？

Pythonさえやっておけばシェルスクリプトやる必要ないってことじゃないですかやったー！

Pythonの関数（特別に作られたものではなく標準関数）を使うという前提の
シェルが作れるものなら作ってみて欲しいね
Python以外でもいいけど

>>268
べつに信用せんでもええで。ｗ
相手にしないだけの話やから。

>>273
信用されないというのは「その他大勢の人から」という意味だよ
>>268の内容は俺がお前を信用しないという宣言じゃなくて
その他の人に対して、お前は信用に値しないという宣言をしている

>>267
POSIX準拠じゃないから使えないねw

>>274
そんな個人的アホ宣言はいらんで。ｗ
「その他大勢の人から」とか少数側が主張しても意味なんかあらへん。

bash特有の機能を使おうと思った時点で
それはシェルスクリプトでやるべきことじゃないんだろうな
もちろんちゃんとシェルスクリプトのスタイル（関数型）でコーディングするのは大前提
ようするにシェルスクリプトはPOSIX準拠の機能で十分なんだよ

シェルスクリプトのスタイルは関数型！

さすがシェルスクリプターの考えることは次元が違うぜ

>>278
https://qiita.com/piroor/items/77233173707a0baa6360

ところで、「流入してくるデータを加工して返却する」「ステートレスな」処理が得意で、
「内部で複雑な状態を持つ必要のある」「ステートフルな」処理が苦手だというのは、
関数型言語にも見られる特徴です。14

そう考えると、シェルスクリプトで凝った事をしようとする人があまり多くないのも頷けます。
「関数型言語は難しい」と言われる事が多いですが、他の言語とパラダイムが違う言語だと思えば、
これまでのプログラミングのパラダイムに囚われたままでは理解が進まないのも当然です。


14. 実際、関数型言語が得意な人にこの説を披露してみた所、
「関数型言語というのはストリーム型のデータを処理するという所が
キモ（なので、解釈としてそう外してはいない）」という感じの感想を頂きました。 ?

沈黙してて草

関数型Elixir は、map・パイプラインばっかり

元の要素を変更しない。
新たに要素を作りながら、変換していく

>>279,280
関数型言語にも見られる特徴があることを関数型とは言わない

知らないなら関数型なんて書かずにパイプでつなぐスタイルとでも書いとけば恥かかずに済んだのにね

関数型言語と同様の特徴があるなら、関数型スタイルでいいだろｗ
関数型言語だって言ってないんだからさぁ

> パイプでつなぐスタイルとでも書いとけば恥かかずに済んだのにね
パイプ以外も関数型にみ見られる特徴があるので
関数型スタイルでいいだろｗ

>>283
ダメ。
関数型は、結果を呼び出し側に戻すことに意義がある。
処理の流れも記述の形式も、むしろ何も似ていない。
もとの文で「特徴」と言っているが、カテゴリの基準にしていい意味ではない。

シェルスクリプトは、フィルタ型とかパイプライン型とか呼べばいいのでは。

> 関数型は、結果を呼び出し側に戻すことに意義がある。

結果を呼び出し側に戻すなんて、どの言語でも同じじゃん
正しく説明することすらできない程度なら語らないようがいいよ
墓穴掘るだけだから

その理屈で言うなら
C言語は「C言語型」だし
Elixirは「Elixir言語型」だし
F*は「F*言語型」だね。

言語使うたび，パラダイム増えるね♪

>>286
まともに理解することすらできない程度なんだね。ｗ

シェルスクリプトでは、関数式のように値を返すのではなく、パイプラインのように出力を流していくように考えよう、とリンク先は主張してる。
ステートレスでというほかの主張とあわせて一貫している。

うむ。
これは、たしかにわかりやすいな。
覚えておこう。

>>287
アホなのかな？

>>288
> シェルスクリプトでは、関数式のように値を返すのではなく、パイプラインのように出力を流していくように考えよう、とリンク先は主張してる。
> ステートレスでというほかの主張とあわせて一貫している。

まさに関数型の動作だねｗ

初心者でよくいるんだわ。関数を使うのが関数型だって思ってるやつ
お前がそれだな

シェルスクリプトは手続き型

他言語との一番の違いは処理の入力と出力が文字列に固定されていること
処理の合成を容易にした代わりに入出力に関わる部分で一般的な手続き型言語とは異なる作法が必要
その作法はプログラミングパラダイムというほど大げさなものじゃない

>>290
アホには通じなかったか。。。
まあ、そんでええんちゃう。ｗ

言い返せないでおしまい

>>293
理解力が足りへんもん。ｗ
ワイはおまえの先生やないからな。
しゃあない。

>>294
俺に説明しろって言ってないよ
他の人にわかるように説明しろと言ってる
それがないから、他の人はお前のことを○○だと思う

https://wiki-dev.bash-hackers.org/syntax/basicgrammar#shell_function_definitions
$ {x}<"$x" _=${x=<(echo moo)} <&0$(cat <&"$x" >&2)
simpleとは一体

>>295
ほかのひとてだれやねん。ｗ
ま、アホの衆が集ったところで、知能が上がるわけやないからな。
通じひんもんは通じひん。
しゃあない。

>>296
日本語での解説
https://www.ryotosaito.com/blog/?p=366

pipefailってPOSIXに取り入れられるの？

https://www.mail-archive.com/[email protected]/msg01960.html

>>299
そこに書いてること読んだ？w

読んだよ？だから聞いてるんだけど

シェルって普通に「副作用」があるコマンドが使われてるよね
POSIXには収録されてないとはいえ，mktempなんかはめちゃめちゃ利用されて
かつ副作用があるコマンドの一例じゃないかしら。

mktemp $$-XXXXX
とすると「ファイルが作られて」かつ「標準出力にそのファイル名が出力」される。

今なら、プロセス置換やcoprocを使えば、テンポラリファイルなしにできることも少なくなさそう。

>>303
いや、たしかにそうかもしれないんだけど、
私が言いたかったのは「関数型」と名乗るには
副作用のある動作はできちゃだめなんでは
ということ。

言葉が足りず申し訳ない

標準エラー出力を画面にそのまま表示し、同時にパイプで繋いだ先にも標準出力として出力する方法ってありませんか？

色付きのエラーを画面に表示させ、さらにその内容をgrepで判定したいです
エラー出力はそのままパイプに渡せないのでgrepにかけられません
エラー出力を標準出力に渡すとgrepで判定できますが色が消えてしまいます

>>305
色が消えるのは、出力先がパイプだからやろ。
コマンドの--colorオプションとかで強制的に色付きにしろ。
そういうオプションがなければ残念ながら。。。

>>304
関数型言語ではファイルを作るというような
副作用があるプログラムを作ることができないとでも？

副作用がまったくないのは"純粋"関数型言語
純粋じゃない関数型言語は副作用を許容する

そして関数型スタイルという言い方なら
別に関数型言語である必要はない

https://docs.python.org/ja/3.6/howto/functional.html

> この文書では、関数型スタイルでプログラムを実装するのに
> ピッタリな Python の機能を見てまわることにしましょう。

初心者のうろ覚えですが、モナドというのは関係ない？

>>307
え，ファイル作成って副作用としてしか表現できないと思ってんの？

シェルスクリプトのファイル作成もモナドですねー

https://qastack.jp/software/369770/do-functional-programming-languages-disallow-side-effects

その意味で、関数型プログラミング言語は実際には副作用を許容します。
外部の世界に影響を及ぼし、他の関数を呼び出し、例外を発生させ、
ファイルに書き込むなどの無数の例があるからです。

常識で考えればわかるだろうに、関数型言語でファイルの作成ができるならそれは副作用でしか無いんだよ。
関数型言語でファイルの作成が副作用に当たらないという屁理屈を言えるなら言ってみるが良い

知ってるなら「○○で表現できる」と断定する言い方をしてみろよ
知らないから>>310のような言い方をしてごまかしている

>>305
scriptで実行してからtypescriptをgrepすれば？

また延々と恥さらしなレスがはじまった
>>304は責任取って

ステートレスなパイプでの受け渡しをする様が関数型的という表現に同意しない訳ではないが、関数が第一級オブジェクトじゃないので関数型言語ではないです
evalで取り扱うのはあくまで文字列です

まぁこれ以外にもないない尽くしだしその一点のみで関数型言語だと主張するのは無理があると思うよ

副作用云々に関しては副作用を明示する事を大事にする関数型言語が純粋関数型言語としてあるよねくらいで終わり

>>316
同意。

>>316
> 関数が第一級オブジェクトじゃないので関数型言語ではないです
知ってます。ってか常識です。
だから関数型スタイルって書いたんです。
考え方の話です。

>>318
スクリプト内でコマンド列組み立てて文字列で標準出力に投げて標準入力から受け取った側がexecやevalで解釈させてってやってるなら関数型スタイルだと納得するかな
まぁスタイルってぼかされたらこれまた気持ちの問題にしかならないのでここまで

あとファイル作成をモナドとして表現することは可能だけどシェルスクリプトのファイル作成はモナドとして表現されてないからモナドじゃないよ

「関数型スタイル」はいらん。

>>285
でええやん？

>>306
>>314
grepの--color=autoオプションでできました
ありがとうございました

>>320
> でええやん？
だめ。既存の用語を使ってないから、何の説明にもなってない

C言語を関数呼び出し型と言ってるようなもん

「なんちゃって関数型風味」を「関数型スタイル」て呼ぶなや

そんなん言い出したらなんでもありやぞ
Bash依存スクリプトはPOSIX準拠スタイル！(あくまでスタイル)

標準入力/出力/エラーと常にI/Oを伴う関数型スタイル！？

> Bash依存スクリプトはPOSIX準拠スタイル！(あくまでスタイル)
何も問題ないのでは？ｗ

> 標準入力/出力/エラーと常にI/Oを伴う関数型スタイル！？
何も問題ないのでは？ｗ

C言語はオブジェクト指向言語ではないが
工夫することでオブジェクト指向スタイルのプログラミングが可能

この文章は別にどこもおかしくないしなぁ

>>326
そら「オブジェクト指向スタイル」を、言った本人はわかってるつもりだから。ｗ
実際にはよくわからんというか、具体的には通じないな。

>>321
Windows 10, WSL, Ubuntu 18.04 の、.bashrc には、以下のように書いてある

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"

alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'

alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
fi

> 既存の用語を使ってないから、何の説明にもなってない

これに尽きる

>>327
それな

ADTって言葉を知らずオブジェクト指向もよく理解してないから
なんとなくで「オブジェクト指向スタイル」って呼んじゃうんだよね

「オレオレ定義のオブジェクト指向」をスタイルという言葉でごまかしてわかったつもりになってるからタチが悪い

じゃあ、C言語でオブジェクト指向スタイルで設計してる時
それを他の人になんて説明するのさ？

C言語でオブジェクト指向っぽい設計にしていますっていうの？
言い方を変えただけじゃんｗ

ファイルやディレクトリみたいな外部状態に依存するものはステートフル？

常駐型のサーバープロセスとかネットワークプロトコルに使う用語なのでシェルスクリプトに対してステートレスって言うのは少し違和感ある

>>331
ADTとは違うの？

>>332
「状態を持たない」という意味なんだから、それでもええやん。
シェルスクリプトは、あんまり内部で状態を持たずに、ただ上から下へと処理をパイプライン状に実行していく、という流れの話やろ。

パイプラインじゃなくてストリーミング処理と言ったほうが良いな
.NETでいえばLINQだ。LINQも関数型と言われてるな。

ステートレスなバッチプログラムと、スステートフルなバッチプログラムって言われても違和感ない？

元記事読み返したがステートレスの使い方が定まってなくていい加減

>>312
機械翻訳クソサイトを貼るな

>>337
元の英語を読めばいいと思いますよ（笑）

>>336
そういうふうに言うと、違和感がなくはないけど、そこはええがな。ｗ
バッチ処理には、しょせんたいしたステートがないのだ、て言うてるだけやろ？

>>335
「ストリーミング」のほうがいい理由は？
ニュアンスが別すぎる印象だが。

LINQの関数型的要素は、高階関数なところやろ。
メソッドチェインなところではない。

> LINQの関数型的要素は、高階関数なところやろ。
シェルスクリプトの関数型的要素は、コマンドを高階関数として使うところやろ
パイプラインを複数つなげられるところではない。

まだやってるのか、グルー言語だろに
本来もだしほとんどの場合も。コマンドを高級関数だって。なんかPOSIXな人は言語として扱ってるような感じだが。だがawkが主だったりしたり
パイプラインもストリームの一つだろうに、開く閉じる書く読むをほとんど意識しないからパイプラインの方が適切かなあ
変なとこの自説をぶってるなあ

グルー言語だったら、その他は何にも当てはまらないとでも言うつもりだろうか？
グルー言語 かつ 関数型スタイルの言語ってだけだろ

> パイプラインもストリームの一つだろうに
変なとこの自説をぶってるなあ（笑）

関数型スタイルでいいだろ
パイプラインだーって自説をぶるなよ（笑）

関数型スタイルという表現すらも自説のぶん回しだと気づいていらっしゃらない……？

コマンドが高階関数なら >>319 にあるように受け取ったコマンド列文字列を適用するとかそういう扱い方をすることになるんだけど本当に意味分かってて使ってる？

もし本当なら書いてるシェルスクリプトなり任意の関数型言語のコードを見てみたいものだ

シェルスクリプト総合 その33
http://2chb.net/r/tech/1584893550/
なんで埋まってないのにここ使ってるの?

ろくろ回し好きそう

ストリーミング君はいろいろ詳しくは知らない漠然とした知識と他は妄想からの思い込みで言っているだけだな
初歩的なコンピュータサイエンスの知識さえ怪しい。端々にポロポロ出てるのに自覚ないからな

高階関数すら理解してなかったかぁ

>もちろんちゃんとシェルスクリプトのスタイル（関数型）でコーディングするのは大前提

それでよくこんなこと言えたねぇ
シェルスクリプトのスタイルは関数型ww
大前提www

>>349
ほらね、反論なしだね
それが答えだよ
結局、違う気がするけど言い返せないと
お前は言ってるんだよ

>>345
> 関数型スタイルという表現すらも自説のぶん回しだと気づいていらっしゃらない……？

自説のぶん回しで何が悪いのか？
自説のぶん回しで何が悪いといい出したのはお前じゃん
しかも理由もなしで

自説のぶん回しにたいして、自説のぶん回しを持ってきても何の反論にもなってないし
反論せずに、ｗｗｗだけ並べても反論にはならない

>>351
あらごめんこれは私が読み間違えてた
そこに関しては自分の言葉だと分かった上で発言してるようだし、撤回するし謝るわ

ただ私は >>342 ではないので後半には答えようがない

敢えて答えるならその定義を認めるか認めないかの話になってしまっているので、不毛な議論である点は問題かなぁ
悪であるとか間違いであるという意味の問題ではなく、理解を得る納得してもらう認めさせるという目標に対して困難さがあるという意味での問題ね

これが結論

https://qiita.com/piroor/items/77233173707a0baa6360

ところで、「流入してくるデータを加工して返却する」「ステートレスな」処理が得意で、
「内部で複雑な状態を持つ必要のある」「ステートフルな」処理が苦手だというのは、
関数型言語にも見られる特徴です。14

そう考えると、シェルスクリプトで凝った事をしようとする人があまり多くないのも頷けます。
「関数型言語は難しい」と言われる事が多いですが、他の言語とパラダイムが違う言語だと思えば、
これまでのプログラミングのパラダイムに囚われたままでは理解が進まないのも当然です。


14. 実際、関数型言語が得意な人にこの説を披露してみた所、
「関数型言語というのはストリーム型のデータを処理するという所が
キモ（なので、解釈としてそう外してはいない）」という感じの感想を頂きました。 ?

>>352
そういうときは、広く通じたり受け入れられたりしたもののほうが、そうでないものよりも正しいんやで。
声がでかくしつこいほうの勝ちではない。

>>355
「〇〇じゃないかもしれない」は反論じゃないんやで
「○○じゃないと思ってるが反論できない（じゃあ正解なのでは？）」という意味なんやでｗ

>シェルスクリプトに適しているのは〜 フィルタ的な働きが求められる種類の仕事にも適しています
ってあるじゃん、そもそもそういうものでしかなく(それを実現してるのはパイプ＝シンプルなプロセス間通信というUNIXらしいシことで実現)、関数型言語として作られてもいないし発展も変化もしてない
シェルスクリプトに適しているのはフィルタ以外のは単なるジョブらしいぞ

似てる部分があるだけで関数型とするのは無理がありすぎ
単にフィルタの段々ができるってだけでいいのに、なんで関数型と言いたいのか
今までのコメからはなんかそれで一人悦に入りたいらしいけど目的がわからんな

>>357
>なんで関数型と言いたいの
これは自分が使ってる道具が古臭くないぞ、最近流行してる機能を昔から実現してるんだぞと主張することで
自分自身が古臭い老害じゃないぞ、新しい技術だって知ってるんだぞ、優秀なんだぞと暗に主張したいから

老害多めのレガシーな言語スレでよく見られる現象

>>357
> 関数型言語として作られてもいないし

まーた「関数型言語」って妄想してる
だーれもシェルスクリプトが「関数型言語」なんていってない
「関数型スタイル」って言ってんの

何回言えばお前が戦ってる相手が
お前の妄想の中の架空の人物だって理解すんの？

シングルタスク、プログラムを一つ起動して終わって次なしかできない環境では、
command1 > foo.txt
command2 < foo.txt > bar.txt
command3 < bar.txt > foo.txt
command4 < foo.txt
とか、一時ファイルに逐次書いて読んでだろうが。もちろん、面倒くさがりが多いこの業界ではこんなのやってられない繋げてしまえと思うのはいたって普通

関数型なんて関係ない、ただそれだけだろな
前プロセスの標準出力を次(フィルタ)プロセスの標準入力に繋げるというシンプルな仕組みだからスクリプト内でも他の形態でも使えるが、ベースは同じ

確かMS-DOSはパイプもどきを実現してるが(一時ファイルに書き出してって上記のを逐一ってのを実際はやって実現してたはず)、
表記的表記的には同じようにステートレスとやらになるが MS-DOS batch fileも関数型の親戚か？


>>358
そうはっきり言わなくてもw
そんなの透けて見えてるけど、自問させてみようかなと
逆に全然優秀に見えないのはなんでだろうなあ

>>358
え？関数型って新しいんでしたっけ？ｗ
シェルスクリプトと同じぐらい古いものだと思ってるんですがー？

>>359
関数型スタイルでもない、「関数型」なんて意識してないのが明らか
勝手に間違った造語作って偉そうにされても困る

>>361
古くからあるらしいが、そんなの世間に出てもてはやされたのは最近って話だろうに
それはあんなサイトを貼ってるので証明してる

優秀なんだぞと暗に主張したいんだったら、少しは他社の目ももとうな

ふむ。あってるよな

https://ja.wikipedia.org/wiki/%E9%96%A2%E6%95%B0%E5%9E%8B%E8%A8%80%E8%AA%9E
最初の関数型言語といわれてるLISPは1958年、Haskellは1990年

https://en.wikipedia.org/wiki/Bourne_shell
Bourne shellは1976年、POSIX shellはksh88として1988年

関数型が新しい技術？？？

>>363
お前は世間のブームが基準なのかよｗ

自分であんなサイトを自慢げに貼って何を言っているのかな？
そんな古く周知されてるなら、あんなサイトを持ち出さなくてもいいし、一人延々と自説を唱えることはないわな

表記的表記的には同じようにステートレスとやらになるが MS-DOS batch fileも関数型の親戚か？
で結論は出ているから、もうおしまい

自分であんなサイトを自慢げってなんのこと？ｗ
ググって出てきたものを貼ってるだけなんだけど

記事の内容じゃなくて、サイトを批判してるようじゃぁ
説得力ゼロですなぁ

>>366
> MS-DOS batch fileも関数型の親戚か？
ぜんぜん違う

コマンドを実行してみりゃわかることだがWindowsのコマンドは対話型
実行したら「○○を処理しました。」とか標準出力に表示されたりして
ストリーミング処理できるように設計されていない

もちろん並列処理が行われないなどという点もあるがそれ以前の問題
お前はパイプラインの有無で判断しているからバッチファイルも同じだと
考えているようだが、パイプラインは関係ないと最初から言っている

ググる必要もないだろうにって話だが？>>361の反論からは
あんなサイトっていうのは別に書いたのがあなたというわけではないよ

というか>>361以下の反論が反論になってないな、散々反論反論言っていたんだから、自分でちゃんとした反論をしなさいよ

>>368
全然読めてないな、あのサイトも>>360も
あなたがシェルスクリプトを関数型と根拠にしたのはパイプで繋げるだからな、あのサイトの抽出したのもそこだろう、MS-DOSでもそこは表記的表面的には同じ

> あなたがシェルスクリプトを関数型と根拠にしたのはパイプで繋げるだからな
別の人と勘違いしてるねｗ

パイプラインとか言い出したのはこいつ（>>285）
> シェルスクリプトは、フィルタ型とかパイプライン型とか呼べばいいのでは。

重要なのはパイプラインではなく、ストリーミングであるという所だ。
つまり1行1データになってないといけない
MS-DOSはそうなってないので全く的外れ

>>354 って自分で書いたくせに何をおっしゃってるのだが
まさかググっただけ中はよく読んでない、都合の良さげの文があったのでというのか？
ちゃんと自分で改めてあのサイトの内容を見てから言いなさいな、まさしくパイプで繋げることしか書いてないから＝それが関数型に似てるだけだから

なんだか知らんが俺が決める仕様なのか、関数型とやらは。誰も納得しないだろうな、その俺が決める仕様なら

> >>354 って自分で書いたくせに何をおっしゃってるのだが

354にはパイプラインなんて出てきてませんねぇｗ

> ところで、「流入してくるデータを加工して返却する」「ステートレスな」処理が得意で、
> 「内部で複雑な状態を持つ必要のある」「ステートフルな」処理が苦手だというのは、
> 関数型言語にも見られる特徴です。14

なんつーか、設計方針を理解してないみたいだな
「パイプ」があれば、設計が同じだと思ってしまう
その程度の理解力なんでしょうね

自分では「パイプ」とは書いてない、抽出した先で抽出した文がパイプだけのことをを指してあっても、自分は書いてないからかあ
どういう思考してるのか理解できないな

>>374
ますます自分の都合の良い捻じ曲げ方してますねえ
自分で抽出した先でそのことだけを言及して、それを自分で開陳してるなら、抽出した先でパイプで繋げることしかなら同じだろうという、いたって単純な結論になるのは当たり前

しかも「これが結論」って自分で書いてらっしゃるんですけど
ちなみに、よく読めばわかるだろうと思うのだが、あれを書いた人もそんな設計方針が必要なほどのことはシェルスクリプトで書かないよ、そう書いてあるでしょう

ストリーミンガーには、まず「関数型スタイル」というものをあきらかにしてほしい。今さらだけど。

ところで、あのWebページのひと、なんかかわいそう。。。
シェルスクリプトには関数型的な特徴がある、ふつうのスクリプト言語とはちょっと違うような、と言っただけなのに、針小棒大にネタにされて。

> 抽出した先で抽出した文がパイプだけのことをを指してあっても
ストリーミングと書いてますが？

シェルスクリプトには関数型的な特徴がある、
シェルスクリプトには関数型スタイルである、

同じことを言ってますねｗ

>>378
なるほど、話が通じない理由がわかった。
それが同じことだと本当に思っているなら、コンピュータのこと以前に、まず国語を勉強する必要がある。

たまたま似た特徴があるとしても、全体がかなり違っていれば、ふつうは同じものと見なさない。
「スタイル」という言葉は、一部に似た特徴がある程度のものを統合しない。

> 「スタイル」という言葉は、一部に似た特徴がある程度のものを統合しない。

それはどこの誰の定義ですか？


https://docs.python.org/ja/3/howto/functional.html
この文書では、関数型スタイルでプログラムを実装するのにピッタリな Python の機能を見てまわることにしましょう。
関数型スタイルにおいては、内部状態を変えてしまったり、返り値に現れない変更をしたりといった副作用のある関数はやめるように言われています。
関数型スタイルで書いた Python プログラムはふつう、I/O や代入を完全になくすといった極端なところまでは行かずに、
関数型っぽく見えるインタフェースを提供しつつも内部では非関数型の機能を使います。
まずは関数型スタイルのプログラムを書く際の基礎となる重要な Python 機能から見ていきましょう: イテレータです。
これらの章内の多くのデザインアプローチは関数スタイルな Python コードにも適用できます。

こいつって前からいるけど致命的に日本語を読めないな

とまあ、こういうふうに悪口しか言えないわけでｗ

今までので何も読めてないのは確かだな。誰もお前と話が通じてないからな
>>380も読めてないお前にしか見えない何かがお前にだけ見えるだけ

>>380
その引用文はどこもおかしくない。
だが、おまえの話はおかしい。
全然関係ない文をもってくるな。

あのね、たとえ話をするね。

カタコトの日本語をしゃべる人がいたとしても、その人が日本人かどうかはわからないのね。
まったく別のところから、きれいな日本語をしゃべる人を連れてきたとしても、カタコトの日本語をしゃべる人とはあくまで他人なので、なにかがわかるわけではないのね。
そして、きれいな日本語をしゃべる人も、結局、日本人かどうかはわからないのね。

要するに、しっかり理屈でしゃべれ！

おや？またシェルスクリプトとは関係ない話で終りですか？（笑）
内容に対してのコメントはないのに、レスだけはしたいんですね。

コミュニケーションに問題があるということを言うことは
コミュニケーションの場で言うことには何も問題ではない
内容以前の話。内容が無茶振りな理屈でこいつの頭の中でしか通らないからな
そしてすぐにくだらない言い逃れに走るしなw

ここが匿名の場なので仕方ないんだけど、シェルスクリプトのファイル作成はモナドって言う人やコマンドは高階関数って言う人が、シェルスクリプトは関数型ないし関数型スタイルだと言いがち（だし他には散々レスがなされているのに、そこの指摘に対して何の反論もなく、意図的にスルーしていると言われても仕方がないような立ち回りをしている）ので信用が得られていないというのはあるかもね

認めようとさせるなら、例えば「awkやsedの文字列でコマンドを渡すのが無名リテラルとしてのラムダ式に相当してる」とか、「while readによる標準入力受け取りイディオムによってスクリプトがfunctor/mappableになるのだ」とか言いくるめないと

>>385
内容にコメントしたら、話が通じないからね。ｗ
シェルスクリプトが「関数型スタイル」だとか、意味不明な発言をしているうちはムリムリ。

だから意味不明な理由を言えばいいだろｗ
言い訳ばっかりだな

そろそろ次スレ立てましょうか？

>>389
>>376
無限ループかな？ｗ

ま、まともな会話はもう期待してないから、どうでもええで。
人語を理解しないのだからしゃあない。

はいまたシェルスクリプトと関係ないレスをしました

>>392
シェルスクリプトに関係ない話を始めたのはそっちやで。

シェルスクリプトはもちろん、関数型言語にも関係のない、独自スタイルの話をえんえんぶちあげられたんやから。
「関数型スタイル」て。ｗ

人語がしゃべれないのに長々と相手してもらったことを感謝するべき。


そして、>>304はこのことを深く記憶して、これからは相手をよく見て話してほしい。
頼むで！

もう少し推敲しなよお客さん

>>394
シェルスクリプトと関係ないレス。ｗ

あの〜。なんでみなさん「個人の感性」を根拠にできるんですかね。
この世界では学者はそんなに重要じゃないのかな。
そんなことないと思うけど……。

個人の感性以上でも以下でもない話題だからじゃないですかね

個人の感性ですかねぇ？

シェルスクリプトはreturnで数字以外返せない。返すには標準出力を使う。
つまり a=$(hoge) とか hoge | other_command とかするしか無い。

そうすると前者はサブシェルになるから変数、つまり状態を書き換えられない。
正確には書き換えられるけど破棄される。後者もサブシェルだから同様。

前者はストリーミング処理ではないが、大量のデータを扱う場合は遅くなるので推奨されない
しかしこれを改善するつもりはないだろう。なぜなら大量のデータを扱う場合は後者の書き方を使えばいいからだ。
後者の書き方は関数型が得意とするストリーミング処理。

シェルスクリプトで遅くならない書き方をすると自然とストリーミング処理になり
変数が書き換わることもない。そしてパイプラインは並列処理が行われる。
ここも並列処理が得意な関数型の特徴と似ている。

これらの事実はシェルスクリプトが関数型として設計されているとみなすには十分な理由だろう。

またアホが出るのか。。。
たまたま見えた特徴だけから同一視しちゃうとか。ｗ

>>396は、ちゃんと後片付けしていけよ。
頼むで！

な？ちゃんと書いた所でまともな反論が返ってこないんだもんな。

自分で「シェルスクリプトと関係ないレス。ｗ」と言っておきながら
それをすぐ自分でやっちゃうわけだ。
そういうことを自分がしているという自覚がない証拠。

>>400
アホな認識でアホなことを書いてるからな。
事実と関係のない妄想はいらん。

アホなことであるという根拠がないから
>>401がアホだと思ってるだけ←イマココ。そしてココで終り

このページで[機能の/機能する]の意でない(つまり関数型を示唆する意味での)functionalを探してみ
余裕があればshellで扱われている文字通りのfunctionとC言語のfunctionと[機能/働き]のfunctionを除く(つまり関数型言語で扱われる関数の意味を示す)functionも探してみるといい
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

まぁそもそもBourne Shellの作者がC言語の文法をALGOL68に寄せるためのマクロを書くしBourne Shellソースがそれで書かれてるくらいALGOL人間で、シェルの文法もそっちに寄ってる訳だ
cshのようにUNIX本体に使われてるC言語の影響を受けるとか、動的型の点でLispの影響を受けるならまだしも、MLの影響を受ける余地があるかなぁホントかなぁという気持ちになるよ

いや、お前こそ探してみ？

探してみといって、何になるのか？

俺が読んだ限りではなかったけど君は信用しないでしょ？

>>402
事実であることを示すほうが先やで。
でなければ妄想に基づく妄想。

自分の考えはみんなの考え。
相手の考えは相手だけの考え。
というのは、アホの理屈。

といっても、わからんのやろが。

事実は>>398に書いてある。

あとは、>>398が言ってることは正しい、かつ関数型スタイルの設計だねというか
>>398が言ってることは正しいが、関数型スタイルとは認めない。なぜなら〜という感じで
お前が答えるかだろ

関数型スタイルwに拘るのがさっぱりわからん
単に名称に拘ってるのか？そうでないなら、今までと違う関数型スタイルやらをコードで書いてみせれば？もちろん今までと違って読みやすいとかで

>>407
>>398が、シェルスクリプトを実行したときの特徴の一部を指摘しているのはそのとおり。事実として認められる。
今までも、そこを否定したコメはないはず。

しかし、次の文は根拠がない。論理の飛躍というか、「個人の感性」というよりも、個人の妄想。

> これらの事実はシェルスクリプトが関数型として設計されているとみなすには十分な理由だろう。

たまたま一致する特徴だけで、そうなるように「設計」されたとは言えない。
# >>403の指摘も、そこに対する疑問であろう。
副作用がもれないこと、並列動作が期待できることは、あくまで特徴。

ふつうに考えれば、別プロセスで実行する都合、そうなることは必然の結果でしかない。
因果関係を逆転させるには、別の充分な根拠が必要。

また、一般的に「スタイル」は、主でない特徴がたまたま似ているだけのもののグループを統合する言葉として使われない。

たぶん読めない伝わらないだろうなせっかく長文書いたのにw

>>409
> また、一般的に「スタイル」は、主でない特徴がたまたま似ているだけのもののグループを統合する言葉として使われない。

Pythonが関数型スタイルと書かれていることとの違いは？
なぜPythonはOKでシェルスクリプトは駄目なのか

https://docs.python.org/ja/3/howto/functional.html
> この文書では、関数型スタイルでプログラムを実装するのにピッタリな Python の機能を見てまわることにしましょう。

>>411
ぜんぜんちがうことだから。
関係のないことを持ち出しても、しょせん関係のないこと。

また、「スタイル」以前に、「設計」の話は？

>>410
こっちも意地になってるからね。
しかたないね。

>>411
Pythonは根本的に関数がOOP的オブジェクトで自然と第一級オブジェクトなので高階関数が扱えるし、対象ページにある通りラムダ式も扱える（もっというとcallableオブジェクトもその類だが）
カリー化こそないけど部分適用も扱えるし、OOP的イテレータパターンを利用して複数の値に対する個別の適用をmap,reduce,filter,zip,product関数のように一般化した高階関数で扱える

定数名前束縛がサポートされてないのは個人的には理解に苦しむんだけどw閑話休題、集合・辞書・リスト内包表記は数学的内包に由来するだけでなく、実はモナド内包表記の具象化で（つまりこれらの内包表記は対象をモナドまで一般化した上でモナド内包表記として扱われることもある）手続きによる個別の変数や領域確保なしに目的のオブジェクトを表現できる

ジェネレータ/コルーチンそれ自身はスタックフル/スタックレス問わずステートフルなものなんだけど、わざわざ事前に領域を確保しなくても逐次計算して要求された値を返す事ができるオブジェクトとしてのイテレータを扱えるという点で先に記述した面々と相性がよく、嬉しい

>>412
> ぜんぜんちがうことだから。
だからぜんぜん違う理由を言えとｗ

>>414

> Pythonは根本的に関数がOOP的オブジェクトで

func="echo"
$func 1 2 3

これ、動きます。evalいりません

>>416
それはそれで別に良いんだ
途中で勝手に切らないで全部読んでくれ

追加で説明するとPythonはそれらの特徴から
・関数を受け取って別の関数にして返す関数（この時点では引数の受け取りと評価はしていない）
　（ex.関数に必要な引数を部分的に与えて残り必要な分の引数を受け取る別の関数にして返す関数）
・関数を受け取って複数の値が纏まったiterableオブジェクトに個別に適用し、複数の値が纏まった別のiterableオブジェクトないし2引数演算子によって纏められた単一の値を返す関数

っていう関数に帰着させられるし、何よりmapのようにあくまで受け取るのはcallableとiterableでしかないし、partialのようにcallableと対象になる値でしかないという所まで一般化されてるのが重点なんだ（静的型付きの言語なら更にそれの妥当性も検証できて嬉しいんだけどPythonも実行時には最低限型やメソッドのレベルで整合性見てエラー吐いてくれるけど）
一方シェルスクリプト、そのレベルまで一般化されたコマンドはそう多くないし、自分で書く分にはむしろ1つのことを上手くやるように具体的なコマンドをゴリゴリ書くと思うんだ
扱う対象に関してシェルスクリプトだって文字列として一般化されてるじゃないか、という意見もあると思うけど、表現能力が貧弱で一緒になってしまったものと、意味表現された上でこの基準に合えば同じものとみなせるっていうのは違うよね、違わない？

>>415
逆。
同じであることの理由を言うのが先。
理由もなく、全然関係ないことを持ち出してもダメ。

https://ja.wikipedia.org/wiki/%E8%A9%AD%E5%BC%81
おまえの理屈は、詭弁の話しかたのいくつかにあてはまる。
それを説明するのはさすがにイヤなので、このままであればそろそろ相手を放棄する。

ま、がんばれや。
とりあえず国語からな。

functional-styleは日本語に訳すと「関数型風」
関数型と関数型風の違いは中華料理と中華風の料理の違いと同じ

中華風と呼ぶには作り手が意図的に中華料理に寄せる必要がある
意図せず結果的に中華料理に似た特徴をもったものを中華風の料理とは言わない
それは中華っぽい(見た目の/味がする)料理

もちろんどんな料理でも中華風と主張するのは作り手の自由だが
中華風として受け入れられるかどうかは別の問題

関数型風はPythonはコミュニティに受け入れられたけど
シェルスクリプトのコミュニティには受け入れられていない(受け入れられそうにもない)
理由が知りたければ受け入れられている関数型風との違いを知る必要がある

>>419
「○○風」の定義の話ですか？
それはお前の定義ですよねｗ

>>417
質問に答えてないね。
なぜPythonのドキュメンは「関数型スタイル」と書いてあるのでしょうか？

Pythonは関数型として作られたのではありませんね。
使う側が工夫することで関数型スタイルにできるという話です。

ハンバーグは和食ではありません。和食として作られたわけではありません。
工夫することで和風にすることができるのです。
それが和風ハンバーグです。

シェルスクリプトも関数型スタイルにできるのです。

内容のないレス連投

>>421
それは読めて欲しかったな
結論だけ先に言うと「関数型言語では先に述べたような関数とデータの扱いが基本なのでそれをPythonにおいて多用する事を関数型スタイルだと述べても批判は少ないが、シェルスクリプトにおいてコマンドを関数と見立ててデータの1in1outの形態の類似性を見ても、それ以外の先の2つに見られる関数合成・部分適用・一般化された高階関数の取り扱いが多用されていない（し多用するには苦痛を伴う）ので関数型スタイルだと述べて批判が来ることが多い」

まず関数型言語っていう言葉がnot well-definedなんだ
関数が第一級オブジェクトであるとこは必要条件であって十分条件でない
一般的にPythonもC++もマルチパラダイムであって大手を振って関数型言語とは呼ばれないと思う
じゃあ関数型言語ないし関数型スタイル、関数型風他類似の名称が何を指してるのか
スタイルは言語のデザイン方針に依存せず自身の書き方で決まるだとか風は更にふわっと雰囲気だけとか細かい部分はあれども結局言語機能の方針やコミュニティのお気持ちで決まってるんだ
ただより豊かに、つまり制約を多く持たせる事には当然批判は少ないと思う
それは既存の言語を参照して帰納的に（ここお気持ちポインツ）考えられる訳で、MLとHaskell（と少なからずLisp）を見た上で出てきたのが、ラムダ式だったり関数合成であったり部分適用だったり一般化された高階関数だったり、Pythonにないものだとデフォルトイミュータブルだったりカリー化だったり静的型付けだったりHM型推論だったりパターンマッチ（正規表現のそれではない）他リッチな型機能だったりモナドだったりするんだ

（続く、長文ごめんね）

>>424
じゃあその増えた制約のうちどれだけを持っていれば関数型風なのか、どれだけを使って書いていれば関数型スタイルなのか、全くなーんにも決まっていない

その中で君が言っている「シェルスクリプトはいい感じに書くと自然に関数型スタイルになる」というのは「1in1out形式のステートレスなインターフェース（1スクリプトだけ見た時内部的に状態を持っていたとしてもinとoutだけ見るとそれらの関係は一意に定まる）を持っている」がベースなんだと私は読んでいる
次いでコマンドを受け取るコマンドの存在と、文字列をコマンドとして解釈させる事が可能である事くらいか（この辺はむしろ反論に対するアンサーとして出てきた側面が強いが）

これと比較するとPythonがどうかというと、より豊かで多い制約を満たす関数型の要素を持っていて、それらを活用して書くことができる
その多さがどのくらいなら関数型スタイルで書けるのだと喧伝していいのか私も知った事ではないし、全人類に検証可能な必要十分な定義はない
少なくともこんだけ続くくらい批判は来てるし、私は関数を引数と戻り値で（つまりシェルスクリプトなら標準入出力で）引き回してもないのに何が関数型スタイルだという気持ちになっている

これは蛇足だけど標準入出力と引数が切り分けられてるのも実用上は理解するけど、カリー化を導入するくらいの数学や関数型の一般化してく文化とは噛み合わせが悪いなぁと思ってるよ

ね、個人の感性だし気持ちの問題でしょ？

だから、関数型スタイルと言っていいわけですね。Pythonも関数型スタイルと言ってますからね。

分かってて言う分には誰が何を言ってもしゃーないしそもそも君の自由でもあるしそれでいいんじゃない？
知らんけど

>>426
Pythonに頼んな。ｗ
Pythonのほうはきっと困ってるから。
だいたい、Pythonのドキュメントが一般に通用するかも定かでないのに。

自分の言葉で、自力で頑張れよ。

>>427
とつぜんあきらめんな。ｗ

>>422
>工夫することで和風にすることができるのです。

和風にするためにどういう工夫をしたの？
和風と名乗るのは自由だけど食べる側がそれを和風料理として受け入れるかどうかは別問題

シェルスクリプトを関数型風にするのにどういう工夫したの？
関数型風シェルスクリプトを謳ってるけどそれは今のところ受け入れられてないよね
なんでかな？

> シェルスクリプトを関数型風にするのにどういう工夫したの？
関数からの戻り値を標準出力への出力にした
これにより別の関数に流れるようにデータを渡せるようになった

>>431
シェルスクリプトを語る前に、ふつうのシェルでコマンドラインを実行してこい！

無駄だぞ、そのレスで意図してることも多分わからないだろから

lsコマンドをシェルスクリプトの中で使う場合ってなにかある？
ファイルの列挙に関してはfindコマンドや，もっと簡単にグロブとかを使った方が
余計な書式を含まずに処理しやすいし，
ファイルの情報に関してはtestコマンドの方が一発で分かる
（例えばディレクトリかどうかはlsコマンドの場合権限欄の情報を文字列として
解析しなくてはいけない（先頭にdがあるかどうか）が，
testコマンドの場合はtest -e && test -dで完結する）

lsコマンドを使わないとできないシェルスクリプトでの処理ってなにかあるかな。
興味本位でききたい（言わずもがなだけどlsコマンドが不要！とかそういう話ではなく）。

findの困るところ :
ディレクトリをもぐる。
ドットファイルを避けない。

ふつうに見えてるファイルだけを列挙するときはls -1がもっとも便利。

シェルスクリプトの中でlsを使うメリットとしては
可読性が高くなるというのはある
findとかだとごちゃごちゃして見にくい
\が必要になることも多いし

>>434
lsはPOSIX準拠。POSIX準拠でファイルの属性を取得する場合、lsコマンド一択となる

ファイルの属性とは例えばパーミッションやファイルサイズなど
これらを取得するコマンドがls

> ファイルの情報に関してはtestコマンドの方が一発で分かる
testでわかるのは、自分が何をできるか？（書き込み等）だけ
他のユーザーのことはわからない

.sshディレクトリは自分は読み書きできるが
他の人は読み書きできてはいけない
ということを、testコマンドでは確認することができない

これだけの文章を纏められない奴

>>435
それは対話的な使用での話で，
シェルスクリプトの話じゃないです。

>>439
あーこれはあるな。
thx

>>434
> testコマンドの場合はtest -e && test -d
ちなみに、test -eはイランで。
-dに含まれとる。-fとかも同様。

>>442
いや、シェルスクリプトでもやけど？
-excludeとかいちいち書くの面倒。

>>440
ちなみにそれをlsを使ったスクリプトで書くとどうなるんでしょう。

>>446
ちゃんと確認してないけどこんな感じ

case $(ls -dl -- "$file") in
????------*) echo 他の人は読み書きできない
esac

ファイルサイズなんかもstatだとLinuxとmacでオプションが違うからな

自分で読み書きできるのかだったらtestの方が簡単だわな
rootで他のユーザではだったら素直にsudo使えばだしな、自分でごちゃごちゃ書く必要もなく

>>447
SELinuxだとダメなときがあるな。
頭にドットがついたりしよる。

>>449
testではだめな場合があるって話をしてるのに、話を元に戻すな

それからパーミッションと実際に読み書きできるかは厳密には異なる
お前が持ってきた、そのrootがその一例だな

所有者rootでパーミッションが000。パーミッションを見れば
読み書きできないが、実際にはrootで読み書きできる

>>450
lsの出力は（基本的なものは）POSIXで決まってるはずだがSELinuxはドットがつくんか？
SELinuxがPOSIXを歪めてるってことになるんだがそれは本当なのか？
画面でそう出力されているからって、シェルスクリプト（出力先がttyでないとき）でも同じとは限らんぞ

例えばGNUのlsはファイル名に改行などが含まれている時、
画面に表示した時はエスケープされていてこれはPOSIXの仕様を逸脱してる。
しかし出力がttyでないときはPOSIX準拠の動作をするので互換性は保たれている。

まあ本当にドットが付いていたりするなら、それを取り除けばいいだけだが

>>450
軽くググったがドットがつくのは頭じゃなくて後ろじゃないのか？
パーミッションの後ろであれば、追加で何かをくっつけてもPOSIX的にはOK
macOSでも何かくっついてたはずだな
それもちゃんと考慮しての ????------*) アスタリスクだ

>>451
なに当たり前のこと言っているのだか
rootも自分が読み書きできるのかなんだから当然だろ、そう言う権限があるんだから
なに必要もないことしてんだかなってとこだな

>>454
人の話聞こうか？
.sshのように、他の人が読み書きできないことを
チェックするときにtestは使えないって話をしてるの
だから戻すなと言ってるの

testでできることの話はもうしてないの。終わった話なの。
今はtestでできないことの話をしてるの。だから話を戻すなと言ってるの。

>>455
ちゃんとレスを読もうか？>>449って書いてるだろ
rootで他のユーザでは
は
rootで他のユーザの場合ではをチェックする場合では
な。「rootで」って付けたのは余分だがそんなのするのはrootでしかないだろうという

>>457
あ、もしかしてお前、「自分以外には見れない」ことを
（シェルスクリプトで）チェックすることはありえないと思ってんの？ｗ
sshがやってるんですが？