シェルスクリプト総合 その34
レス数が1000を超えています。これ以上書き込みはできません。
シェルスクリプトに関する総合スレッドです。
全般
・荒しは無視しましょう。
・丁寧な姿勢を心掛けましょう。
・ネチケット(死語)を意識しましょう。
・「○○(他の言語)でいいやん」は禁止。他のスレに行ってください。
シェルスクリプト総合 その33
https://mevius.5ch.net/test/read.cgi/tech/1584893550/ ・特記なき場合、POSIX準拠シェルが既定です(古きBourneシェルはほぼ絶滅しました)
POSIX準拠シェルは(d)ash, bash, zsh, (m)ksh, yash, posh, (p)boshです
参考 https://unix.stackexchange.com/questions/145522/
特定のシェルの専用機能に依存する場合は明示しましょう(特にPOSIX準拠シェルではないfish, (t)csh等)
・デフォルトシェルのシバンはBourneシェル時代からの伝統で#!/bin/shを使用します。ただしその実体はOSによって様々です
Debian系 … dash CentOS系 … bash Alpine … ash(busybox) Android … mksh
FreeBSD … ash Solaris,OpenBSD … ksh
macOS … bash(Single UNIX Specification準拠のために一部動作が異なる)
・ログインシェルは/bin/shでない場合があります。例 macOS … zsh
・シェルスクリプトは可搬性を持たせるために可能な限りPOSIXに準拠しましょう
仕様 http://pubs.opengroup.org/onlinepubs/9699919799/
参考 https://en.wikipedia.org/wiki/POSIX
・bash依存はなるべく避けましょう。自覚なきbashism。シバンが#!/bin/shなのにbashに依存する構文を使っていませんか?
#!/bin/shを使うならシェル依存は厳禁です。bash依存するなら#!/bin/bashです
・BourneシェルはPOSIX標準化前に主にUNIXで使われていたシェルで多くの亜種が存在します
Bourneシェル≒Version 7 UNIXのshに一番近いのはOpenSolaris由来のHeirloom Bourne Shell、次点でSchily Bourne Shellのoboshです
Heirloom Bourne Shell: sh http://heirloom.sourceforge.net/sh.html
Schily Bourne Shell: obosh http://schilytools.sourceforge.net/bosh.html
歴史的資料 https://www.in-ulm.de/~mascheck/
・csh/tcshでのシェルスクリプトは*まったく推奨しません*
参考 http://www.speech-lab.org/~hiroki/csh-whynot.euc
・Linux/UNIXにはシェルスクリプトに便利な小さなコマンドがいろいろあります。Manページや各種リンクを見ましょう
aproposやman -kでそれらしい単語による簡単な検索もできます
・ワイルドカード・パターンは正規表現ではありません。正規表現の話題はスレ違い(正規表現スレへ)
・シェル芸はシェルスクリプトとは異なります
・シェルスクリプトのことをシェルってゆうな こんにちは
Macでzshを使っています
フォルダに
memo20200810.txt
memo20200817.txt
memo20200824.txt
のようなファイルがあったとして(週に1つずつ増える)
最新のファイルをechoで見たいとしたらどうするのがいいでしょうか??? すみませんechoではなくcatでした
別にコマンドは何でもいいので最新のテキストの内容を見る方法を知りたいです cat "$(/bin/ls *.txt | tail -1)" ファイルが大量にあった場合には大きい順でソートして1行目を取り出すみたいに書いた方が速くないか? >>7
ちなみにlsだけフルパスなのは? lsがエイリアスである可能性を考慮とか? Unixで「複数のパスを区切る」といえばコロン区切りが普通だと思うんだけど
(例えばPATH,CDPATH,NLSPATHとか)
POSIXの
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03
でも言われている通りコロンが含まれているパスを指定することができない。
もちろん自分で勝手にPOSIXを逸脱して,バックスラッシュでコロンを
エスケープする,みたいなことをしてもいいんだけど,
なるたけ標準に合わせたい。
環境変数で複数のパスを指定するときに,
コロンを含めるようにしているユーティリティの例とか知らない? PATHがコロン含められないのにコロン使えるようにするの?
チャレンジャーだなw
Unixはパスに使えない文字を決めたほうが良かったと思うね
MS-DOS/Windowsはちょっと多すぎだけど >>13
Windowsだとドライブレターにコロンを使ってるから
PATHの区切りは;ですね。 そういや環境変数名に記号とか改行とか使えるの知ってる?w コマンドの戻り値を反転させたい、つまり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
任意のコマンド set -eでエラー終了した時は$?が1とは限らん
trap 'exit $(($? == 0 ? 1 : 0))' EXIT
trap 'exit $(($? > 0 ? 0 : 1))' EXIT # 一文字短縮化w >>21
>>22
ありがとう。
コマンドラインの前に「!」を書けばいいのか。
manページを確認すると、「logical negation」とあったから、こちらの期待どおり。 trap 'exit $(($? > 0 ? 0 : 1))' EXIT
これいいね >>28
あー、その記事読んだ。FSってフィールドセパレータだと思っちゃうよねw
たまたま俺は、レコードとフィールドと、ファイル区切りもいるかなぁ?って
考えながら探してたから、お、4つもあるじゃんって感じで気付いたが >>17
シェルによって書き方違うかも知れないがこんな書き方も可能。
if コマンド [引数 ...]
then
exit 1
else
exit 0
fi
ほぼ >>18 と同じだが、コマンドを if の直後に書けばそのまま戻り値の判定ができる。
こういう書き方もできる。短い場合はこれでも良いかも。(でも後で見て分かり辛くなるかな?)
コマンド [引数 ...] && exit 1 || exit 0
2行に分けても行ける。exit 1 の方が実行されたら下の行には行かないので。
こちらの方が見た目は分かり易いかな。
コマンド [引数 ...] && exit 1
exit 0 あ。上の方からゆっくり読んで下まで読まずに書いたら途中で色々と話が進んでいたorz https://mevius.5ch.net/test/read.cgi/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
というような出力になってしまう。 シェルスクリプトマスターしてしまったので
シェルスクリプト難しいって言ってる人が
何が難しいのかわからなくなった
シェルスクリプトが難しいんじゃなくて
初心者だから難しいだけなんじゃ? >>33
いくつかやり方があると思うがヒントな
位置パラメータが 1 2 3 4 5 の状態から
1 2 3 4 5 2 1 3 4 5 を作り出すことができれば
あとはshift 5をするだけで
2 1 3 4 5 にすることができる
この問題を解くカギは、終了条件をどうするか?なんだよ 1 2 3 4 5 2 1 3 4 5 を作り出すことができれば
スペース入れたつもりだったが見やすくならなかったな 補足 わかると思うけど
この問題を解くカギは、「ループの」終了条件をどうするか?なんだよ >>37 >>40
ちなみに >>33 の解答でも
setやshiftを使ったりしてうまいこと
引数処理をしてはいる。 前スレ止まってると思ったら埋めずに分裂してたんかい >>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の一番最初の処理は実行できるのですが
2番目の処理からがエラーで実行できません。
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といわれてもー
バージョンわからないしー
検証環境用意できないしーw
読んでて思うのはtogetterはツイートをまとめるだけなので
検証内容をまとめるには適してねーわ >>60
同意。
「結局なにが分かったのか」
「解決方法はどうだったのか」
っていう,一番重要な情報もめちゃめちゃ
みにくいところにある。
しかも,まとめ主は
「あとで記事にする」と言っているのに
その後音沙汰がないし
アカウント乗り換えてる模様。
怪しすぎる。 >>61
あとなんかシェルによってシバンの扱いが違うように書いてるように見えるんだけど
シバンを解釈するのてOSだよね?
他の言語から起動することもあるんだから
シェルはOSに丸投げしてるだけ だれかもうずばっと シバンはちゃんと書きましょう。
shを使うなら #!/bin/sh です。このパスがない環境はもうありません
って言ってくれないかな?w
真偽不明でタイトルだけ残ってて困る >>63
ちょっとつっかかるけど
「このパスがない環境はもうありません」
これも根拠なくないか?
POSIXでは定められていない訳だし,
Solarisだと/bin/shはめちゃめちゃ古い。
POSIX shは/usr/xpg4/bin/shにある。 たまたま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 が使えなくなったw
ちなみに /bin はどちらのPATHにも入ってない
getconf PATHをどう使うかもOS依存な気がするけど、Togetterまとめに書いてあるように
PATH="$(command -p getconf PATH):$PATH"
こうすることで、標準を壊すことなくPOSIX準拠に近くするという意味になるんだろう
ちなみにだけどcommandの-pオプションは古いzsh(たしか4.0あたり)で使えなかったりするけどなw
個人的にはgetconfがない環境があるのは知っていたので、そこは何も不思議はない
Togetterまとめに書いてあるPATHの初期化方法は何をやりたいのかよくわからんw
なんつーか一行にしようとして意味不明にしてるとしか思えんな。こんなんでいいやろ?
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使えなくなるよね? >>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は体系的に作られたものではないということ。
それぞれが他人によって作られ、それらを統合しているため、一貫性がないのが普通。
細かい規格も存在していないので、コマンド、スクリプトは環境に依存する。 >>87
>>73
後出しの思い付きを垂れたからやろ。 >>86 って言ってるのに、疑問に思うな思考停止とか読めないやつなんだろな そもそもUNIXは、たまたまこうなったんじゃなくて、合理的な理由があるんだけど、なんでそれを知ろうとしないの?
UNIXはこういう思想で物を作ってますと宣言してるのに。 いやー、たまたまやろ。
根っこにポリシーはあっても、それ以外はかなりのいきあたりばったり。 >>92
それな。"$1" みたいにダブルクォートでくくらないといけないのは
明らかな仕様の失敗だって言われてるし
他の言語と同じようにPOSIXシェル以前やBourneシェル以前との
互換性をある程度保ちながら改良を続けてきた
必ずしも合理的な理由があるわけじゃないよ。作者がたまたま必要だった
必要と思いつかなかった。それだけだろ >>93
二重引用符で囲まない場合,
どういう利点があるの?
あとそれを説明した記事とかある? >>94
> 二重引用符で囲まない場合,
> どういう利点があるの?
ない
やりたいことはevalで代用できる >>94
あるというか、そうしなければならない場合も。
引数がなかったときに、クォートされてると、空文字列になってしまうので、意味が変わる。
make $1
みたいなスクリプトだとクォートしてはいけない。 >>98
試してから言え。
簡単に嘘呼ばわりすんな。 >>97
だと makeに "install uninstall" という文字を渡すと
エラーにならずに実行できるから駄目
試さなくてもわかる >>101
引数がないのに$1を参照してたら
bash: $1: 未割り当ての変数です
っていうエラーが出るだろ
アホかw >>102
でねえわ。
-uを前提にすんな。
クズ。 >>103
お前のようなやつが rm -rf "$path/" とか書いて痛い目見るんだろ
ベストなやり方前提にしろ。ベストなやり方で使えない方法を持ってくるな >>104
勝手に-uをベストに決めつけんな。クズ。
オプションは使うべきときに使え。クズ。
makeみたいな、引数の有無で挙動が変わるコマンドがあって、考えなしに変数をクォートすりゃあいいってもんじゃない、って話をしてんだよ。クズ。 考えなしにクォートしなかったから
バグが増え危険なコードになってんだろが ガッ
なコード書きたいただの甘えん坊だな ID:GM+a9m1V は シェルスクリプト書くうえで、
command
command arg
どちらも(前にチェック無しで)書きたいなんてほとんどないだろうに。ほとんどないのはあげつらってるのはお前だけという点で明らかだな
ls で言えば
ls target
ls
結果が違うんだから目的も違う
ls ''
でエラーになる方が大体の目的にあっているだろうにとしか思えない >>92
だから、そう説明してるんだよ。わざわざ作り直したり、同じようなものを作らないのがUNIXの考え方。 >>111
文盲どもめ。
もともと頻度の話ではない。
クォートしないことにも意義がある、というだけ。
実際、既存コマンドのラッパーみたいなものを書くときなんかでは活用できる。 そこでPlan 9 rcですよ。
引用符の種類が一つしかない。
そしてクソほど使いにくいw >>113
文盲と他人をあげつらってるくせにの文盲はお前じゃ
>クォートしないことにも意義がある
誰も意義がないなんて言ってないだろが
発端は
>それな。"$1" みたいにダブルクォートでくくらないといけないのは
>明らかな仕様の失敗だって言われてるし
だからな。その流れ中にクォートありだけをあげつらっている(?)のは、クォートしないことにも意義があるじゃなく読まれてもしょうがないな 失敗だって言われてるってその例では「全く」wピンと来ないが、
今時名前の中にスペースが入っているの当たり前で、ほぼ必ずダブルクォートで囲まなければならないのがメンドくさいのは確かだな
逆(単にダブルクォート有無の動作が逆ではなく、ダブルクォート無しでもダブルクォート有りの動作、IFSで分かつなら別の表現)っていうのならわかるが、失敗というほどでもねえなとも思われる
多分、伝わってないのは、そういうことだよw >>117
話には流れがあるんだな
で、お前の言うことには言うほどでもないってこともあるだろう、そのしつこく延々と>>94にたいしてって言うのは。自分で案に認めてるように 頻度 はそうないらしいしw
文盲の意味を履き違えてるなwてかよくわかってないだろう $1と書いてるのに$1がないとみなされるのは
利点ではなく欠点 >>119
シェルの変数は、ただのテキスト置換なレベルだからな。
今さらそんな理想を言っても始まらん。 >>118
いや、あきらかに文盲であることがはっきりした。w >>120
> シェルの変数は、ただのテキスト置換なレベルだからな。
それはウソ >>121
流れに関係なく、俺の突然言い出したことを理解できないのは文盲というのなら、お前から見たら文盲なんだろな
文盲という意味(厳密な意味じゃない)を理解してないアレだと俺は思うけどな
っていうことで明らかに終わりだな、その投げやり言い放ちだけのレスでw 仮にお前が賢い人間だとするじゃん
仮に相手が馬鹿な人間だとするじゃん
その場合だと争いにならないわけだから争いになってるということはその過程は合っていなかったわけだね
つまり
お前らは馬鹿だってことさ >>122
コードをどう解釈するのかはシェル内部の仕様。
変数名を文字列として指定し、文字列で指定された変数の値を参照する仕組みもシェルの仕様。
これは結果的にわかりにくい表現、使ううえで間違いやすい仕様として認識されている。
UNIXはたいしたことない欠点をあとから変更する文化はない。
マイクロソフトのように次から次へ新しいものを作っては捨て、作っては捨てということはしない。 単に互換性のために修正できないだけ
欠点は欠点。修正できない可哀想
だからPOSIXに新しい言語も追加できない > 変数名を文字列として指定し、文字列で指定された変数の値を参照する仕組み
ウソ 行為主体(発言主体)の意思ではなく事柄の客観的事実に言及したいのであれば、「ウソ」ではなく「間違い」「事実ではない」といった言葉を用いるべし >>126
そうね。でもそれで大成功をおさめているのがUNIX系。もうすべてがUNIXになりつつある。WindowsのUNIX化もとまらない。
そもそもシェルスクリプトに不満があるのなら、別のスクリプト言語を使えばいい。 仕事でシェルスクリプトを触りはじめたけどすぐに地雷を踏む macのローカルで作ったシェルをLinuxで動かしたら悲しいことになった >>132
> そもそもシェルスクリプトに不満があるのなら、別のスクリプト言語を使えばいい。
/bin/shが他のスクリプト言語になることなんてあるんか?
最小構成で他のスクリプト言語が含まれることなんかあるんか?
POSIXが改定して別のスクリプト言語が使えるようになることなんてあるんか?
現実的にありえない話をしても意味がない >>133
まあ初心者さんは何でもそうだよね
>>134
だからPOSIX準拠しろって話だ >>133
ワナだらけだからね。
しかたないね。
本当に。。。 >>135
じゃあPOSIXなんか無視すりゃいいんだよ。
自分で好きなのをインストールすれば。
poshが普及したりはしないかな?w 自分は良くても他人のイメージを使うときに困るだろ
posh?好きなら自分でイントールしてろw >>140
そのposhとかいうのをmacにインストールしたんだが
$ cd /
posh: cd: too many arguments
で動かないんだがwww
こんなバグソフト普及するわけねーだろwww poshを終了しようとして
$ exit
posh: exit: bad number
www >>141
POSIX互換ならなんでもすべて同じ、ではないから、そんな配慮はムダ。
>>142
ツンデレだな?w
まあがんばれ。 >>144
全て同じではないから/bin/shはdashかbashしかありえない >>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.
はい撤収w >>149
今話をしてるのはシェルスクリプトでやることの話だろ よくわからないのが、シェル関数や外部プログラムを作って、呼び出せばいいんじゃないの。
シェルスクリプトの見た目がどうこうという話は不毛だよ。 シェルスクリプト(の文法)に不満がある
→別のスクリプト使えばいい。あちこちに頼んで入れてもらえ
馬鹿なの?
どこにシェルスクリプト以外のスクリプト言語が
予めインストールされている世界があるというのか
現実を見たほうがいい >>154
「予め」とか言ってるのが馬鹿。
自分でインストールしようと思えばする。
でなければしない。
それだけ。 だから他人が作ったイメージでは無理だろ
なんでもroot持ってると思うな >>154
そのOSの基本シェルがインストールされていないわけがない。
そもそもシェルがなんなのかわかっているのか? >>154
だからシェルスクリプト以外を使えないだろって話をしてる 間違え
>>157
だからシェルスクリプト以外を使えないだろって話をしてる >>147,148
ありがとう
>>147
PS???は初見だったんで調べてみます
>>147
先頭のhttpを除外しようと、頭が固くなってた >>160
PSはPowerShell、Windowsのやつなので関係ない
調べるだけ時間の無駄 >>163
This project is a work in progress >>159
そもそもおまえはUNIX、Linuxをインストールしたことがあるのか?
かなり不思議なことを言っているぞ?
sedやawkは何か説明できる? Linuxをインストールしたら、Perlもデフォルトでインストールされることも知らないんだろうな。
そもそもシェルの概念がわかってないと、シェルスクリプトがシェルのスクリプトだとおそらく理解できない。 別にシェルからすれば、シェルスクリプトではなく、実行ファイル形式を橋渡ししてマシン語でやり取りしてもらってもかまわない。
ただし、UNIXは既存のものの組み合わせでできるのであれば作らないという思想なので、C言語でゴリゴリ作るやつは批難される。 >>172
デフォルトって何?w
Perlはインストールされなくてもおかしくないやろ。 >>173
ゴリゴリつくるヤツがいたから、Gitが存在するんやで!w
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の話をしましょうよw
$ 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の哲学を語ることに現実の意味はない。
考古学者以外は。w Alpine は、5MB しかない。
何も入っていない
それに、Ruby on Rails, Node.js などを入れて使うもの >>178
サーバー用最小ならおかしくない。
まさかデフォルトって、GUIデスクトップ用のことを言ってないよなあ? >>184
おまえさ、CUIの画面があるのがあたりまえだと思っているだろ?
CUIそのものがシェルなんだよ。 コンピューターの仕組みを理解していないのにいちいち見当違いのことを書くんじゃない。 >>185
だから何?
>>186
自己紹介乙。w Perlが入ってないLinuxがあるってこともしらんのか >>178
どうしてperlかなかったら画面真っ暗で文字が打てないわけ? シェルがなかったらと書いてあるだろ。
しつこいけどシェルは人間とのユーザーインタフェースだよ。
シェルがなければ人間は何もできない。 コンピューターは必ずCUIの画面があると思ってしまうのだろうか? シェルはLinuxに必ずインストールされているが
Perlはインストールされてないものが実際に存在し使われている
話はこれだけだろ >>192
お前コミュ力なさすぎ…
perlがインストールされてなくてもおかしくないってレスに対して、
なんでシェルがなかったら画面真っ暗なんて回答になるんだよ このスレの人ってどうでもいい事になんでこんなすぐ必死になるの? >>197
そしてなぜ黙ってればいいのに
こんなことを書き込んでしまうの? 真面目で、相手の誤りを修正してあげたいから。
バカで、自分の誤りを認識できないから。
とか、人それぞれに理由があるやろ。
まあ、最大の理由はヒマだから。w
おまえもな。 >>196
デフォルトというのはLinuxだったら、bashシェルがインストールされて起動するということ。PerlはLinuxの大半のインストーラが標準設定でインストールしてしまう。 >>200
もとの話とつながってないぞ!w
やりなおし! >>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を生やすでもコンテナを建てるでも何でも使える手は使って、自分の手段と環境の中で一番楽な地獄を使うのがいい
手を尽くしてもシェルスクリプト以外使えないか、手を尽くすのがダルいならそりゃそのままシェルスクリプトを使うしかないのはそれはそう
ただ現代においてシェルスクリプトしかスクリプト言語を使えない上に新規導入もできない案件が多数派だし普通だよって言われると本当?って思うしその立場に同情するまである 最近はコンテナ系がはやって、ガチガチの最小構成も現実的やろ。
昔なら、とりあえずあれこれ入ってるし入れるのがふつうだったが。 >>197
1つの道具しか使えない人や1つの道具への依存度の高い人は
その道具の必要性を下げる話や短所を指摘されると
無意識に自分の存在意義を否定された(攻撃された)と感じるので必死になる
特定の道具への精神的依存度の高い人たちが集まってる所ではよくあること コンテナ向け最小構成ならそれこそコンテナ生やせばいいじゃん… >>210
PerlコンテナとかPythonコンテナとかつくるの?
粗なの?密なの?w >>209
C++23で書こう!w
しかし、今さら使いやすそうになってきたな。。。 >>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
そりゃああるやろ。w
あるからなんなの?
コンテナのまま実運用で使うの? ほんとに必死だね
よほどコンプレックスが強いんだろうな
シェルスクリプトに固執しないとダメな状況ってそうそうないだろうに シェルスクリプトに固執っていうか、シェルスクリプトが最善な場合に
シェルスクリプトを使うってだけだよね >>224
スレタイが読めないの?w
どっちが固執してるんだか。。。 >>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
シェルスクリプト自体に文句があるのはしゃあない(つーか、ないヤツはおらんやろw)が、全否定したらこのスレではただのあらしでしかない。
さらに、最近の一部のヤツはとくにバカっぽかったからな。 状況に応じて使う道具を変えなよって言われてるのに、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ならぬ、空白区切りのファイル形式を使うという前提があって
そのデータ操作するためのコマンド群でしかないことに気付いた ユニケージのコマンドに絶望した後
クソコマンドをまともにしてやろうと思ったが
クソな理由はコマンドではなくデータ形式だったので
どうしようもないというねw
データ形式を空白区切り前提にしなければ、
通常のシェルスクリプトで使うコマンドを使うことになるが
ユニケージのコマンドとは全く異なる仕様になる
直しようがない >>255
>a more structured language
↑ここがポイントだろうね ポイント? なんでそう思ったの?
根拠がないから具体的ではないだけ どうでもいいんですけど,
シェルスクリプト以外の話題なら他所でやってもらえません?
もちろんシェルスクリプトの存在論も含めて。
テンプレくらい読んでくれよな〜頼むよ〜 長々とどうでもいいこと書き綴ってスレ荒らしてたのお前じゃん >>264
わかる人にはわかる。
わからない人のほうがその理由を内省するべき。
ただ、Bashは関数と連想配列のおかげで、それなりの構造化はできてるな。
逆に言うと、よっぽどややこしいデータ構造を組むのでなければ、シェルスクリプトでも可、ってことか。w >>267
分かる人が理由を書くべきだろ
こういう意味不明なこと言うから信用されないんやで まあ結局
「シェルスクリプトでおかしな書き方をするやつは
Pythonで書こうがRubyを使って メタプログラミング() をしようが
下手な書き方をすることに変わりない」
ってことよね。 シェルスクリプトから○○言語に変更したってやつは
変更した結果どうなったのか、そのコードを見てみたいんだが
シェルスクリプトで一体何をしていたのか? Pythonさえやっておけばシェルスクリプトやる必要ないってことじゃないですかやったー! Pythonの関数(特別に作られたものではなく標準関数)を使うという前提の
シェルが作れるものなら作ってみて欲しいね
Python以外でもいいけど >>268
べつに信用せんでもええで。w
相手にしないだけの話やから。 >>273
信用されないというのは「その他大勢の人から」という意味だよ
>>268の内容は俺がお前を信用しないという宣言じゃなくて
その他の人に対して、お前は信用に値しないという宣言をしている >>267
POSIX準拠じゃないから使えないねw >>274
そんな個人的アホ宣言はいらんで。w
「その他大勢の人から」とか少数側が主張しても意味なんかあらへん。 bash特有の機能を使おうと思った時点で
それはシェルスクリプトでやるべきことじゃないんだろうな
もちろんちゃんとシェルスクリプトのスタイル(関数型)でコーディングするのは大前提
ようするにシェルスクリプトはPOSIX準拠の機能で十分なんだよ シェルスクリプトのスタイルは関数型!
さすがシェルスクリプターの考えることは次元が違うぜ >>278
https://qiita.com/piroor/items/77233173707a0baa6360
ところで、「流入してくるデータを加工して返却する」「ステートレスな」処理が得意で、
「内部で複雑な状態を持つ必要のある」「ステートフルな」処理が苦手だというのは、
関数型言語にも見られる特徴です。14
そう考えると、シェルスクリプトで凝った事をしようとする人があまり多くないのも頷けます。
「関数型言語は難しい」と言われる事が多いですが、他の言語とパラダイムが違う言語だと思えば、
これまでのプログラミングのパラダイムに囚われたままでは理解が進まないのも当然です。
14. 実際、関数型言語が得意な人にこの説を披露してみた所、
「関数型言語というのはストリーム型のデータを処理するという所が
キモ(なので、解釈としてそう外してはいない)」という感じの感想を頂きました。 ? 関数型Elixir は、map・パイプラインばっかり
元の要素を変更しない。
新たに要素を作りながら、変換していく >>279,280
関数型言語にも見られる特徴があることを関数型とは言わない
知らないなら関数型なんて書かずにパイプでつなぐスタイルとでも書いとけば恥かかずに済んだのにね 関数型言語と同様の特徴があるなら、関数型スタイルでいいだろw
関数型言語だって言ってないんだからさぁ > パイプでつなぐスタイルとでも書いとけば恥かかずに済んだのにね
パイプ以外も関数型にみ見られる特徴があるので
関数型スタイルでいいだろw >>283
ダメ。
関数型は、結果を呼び出し側に戻すことに意義がある。
処理の流れも記述の形式も、むしろ何も似ていない。
もとの文で「特徴」と言っているが、カテゴリの基準にしていい意味ではない。
シェルスクリプトは、フィルタ型とかパイプライン型とか呼べばいいのでは。 > 関数型は、結果を呼び出し側に戻すことに意義がある。
結果を呼び出し側に戻すなんて、どの言語でも同じじゃん
正しく説明することすらできない程度なら語らないようがいいよ
墓穴掘るだけだから その理屈で言うなら
C言語は「C言語型」だし
Elixirは「Elixir言語型」だし
F*は「F*言語型」だね。
言語使うたび,パラダイム増えるね♪ >>286
まともに理解することすらできない程度なんだね。w
シェルスクリプトでは、関数式のように値を返すのではなく、パイプラインのように出力を流していくように考えよう、とリンク先は主張してる。
ステートレスでというほかの主張とあわせて一貫している。
うむ。
これは、たしかにわかりやすいな。
覚えておこう。 >>288
> シェルスクリプトでは、関数式のように値を返すのではなく、パイプラインのように出力を流していくように考えよう、とリンク先は主張してる。
> ステートレスでというほかの主張とあわせて一貫している。
まさに関数型の動作だねw
初心者でよくいるんだわ。関数を使うのが関数型だって思ってるやつ
お前がそれだな シェルスクリプトは手続き型
他言語との一番の違いは処理の入力と出力が文字列に固定されていること
処理の合成を容易にした代わりに入出力に関わる部分で一般的な手続き型言語とは異なる作法が必要
その作法はプログラミングパラダイムというほど大げさなものじゃない >>290
アホには通じなかったか。。。
まあ、そんでええんちゃう。w >>293
理解力が足りへんもん。w
ワイはおまえの先生やないからな。
しゃあない。 >>294
俺に説明しろって言ってないよ
他の人にわかるように説明しろと言ってる
それがないから、他の人はお前のことを○○だと思う >>295
ほかのひとてだれやねん。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
え,ファイル作成って副作用としてしか表現できないと思ってんの? 常識で考えればわかるだろうに、関数型言語でファイルの作成ができるならそれは副作用でしか無いんだよ。
関数型言語でファイルの作成が副作用に当たらないという屁理屈を言えるなら言ってみるが良い
知ってるなら「○○で表現できる」と断定する言い方をしてみろよ
知らないから>>310のような言い方をしてごまかしている >>305
scriptで実行してからtypescriptをgrepすれば? また延々と恥さらしなレスがはじまった
>>304は責任取って ステートレスなパイプでの受け渡しをする様が関数型的という表現に同意しない訳ではないが、関数が第一級オブジェクトじゃないので関数型言語ではないです
evalで取り扱うのはあくまで文字列です
まぁこれ以外にもないない尽くしだしその一点のみで関数型言語だと主張するのは無理があると思うよ
副作用云々に関しては副作用を明示する事を大事にする関数型言語が純粋関数型言語としてあるよねくらいで終わり >>316
> 関数が第一級オブジェクトじゃないので関数型言語ではないです
知ってます。ってか常識です。
だから関数型スタイルって書いたんです。
考え方の話です。 >>318
スクリプト内でコマンド列組み立てて文字列で標準出力に投げて標準入力から受け取った側がexecやevalで解釈させてってやってるなら関数型スタイルだと納得するかな
まぁスタイルってぼかされたらこれまた気持ちの問題にしかならないのでここまで
あとファイル作成をモナドとして表現することは可能だけどシェルスクリプトのファイル作成はモナドとして表現されてないからモナドじゃないよ 「関数型スタイル」はいらん。
>>285
でええやん? >>306
>>314
grepの--color=autoオプションでできました
ありがとうございました >>320
> でええやん?
だめ。既存の用語を使ってないから、何の説明にもなってない
C言語を関数呼び出し型と言ってるようなもん 「なんちゃって関数型風味」を「関数型スタイル」て呼ぶなや
そんなん言い出したらなんでもありやぞ
Bash依存スクリプトはPOSIX準拠スタイル!(あくまでスタイル) 標準入力/出力/エラーと常にI/Oを伴う関数型スタイル!? > Bash依存スクリプトはPOSIX準拠スタイル!(あくまでスタイル)
何も問題ないのでは?w
> 標準入力/出力/エラーと常にI/Oを伴う関数型スタイル!?
何も問題ないのでは?w C言語はオブジェクト指向言語ではないが
工夫することでオブジェクト指向スタイルのプログラミングが可能
この文章は別にどこもおかしくないしなぁ >>326
そら「オブジェクト指向スタイル」を、言った本人はわかってるつもりだから。w
実際にはよくわからんというか、具体的には通じないな。 >>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言語でオブジェクト指向っぽい設計にしていますっていうの?
言い方を変えただけじゃんw ファイルやディレクトリみたいな外部状態に依存するものはステートフル?
常駐型のサーバープロセスとかネットワークプロトコルに使う用語なのでシェルスクリプトに対してステートレスって言うのは少し違和感ある >>332
「状態を持たない」という意味なんだから、それでもええやん。
シェルスクリプトは、あんまり内部で状態を持たずに、ただ上から下へと処理をパイプライン状に実行していく、という流れの話やろ。 パイプラインじゃなくてストリーミング処理と言ったほうが良いな
.NETでいえばLINQだ。LINQも関数型と言われてるな。 ステートレスなバッチプログラムと、スステートフルなバッチプログラムって言われても違和感ない?
元記事読み返したがステートレスの使い方が定まってなくていい加減 >>337
元の英語を読めばいいと思いますよ(笑) >>336
そういうふうに言うと、違和感がなくはないけど、そこはええがな。w
バッチ処理には、しょせんたいしたステートがないのだ、て言うてるだけやろ? >>335
「ストリーミング」のほうがいい理由は?
ニュアンスが別すぎる印象だが。
LINQの関数型的要素は、高階関数なところやろ。
メソッドチェインなところではない。 > LINQの関数型的要素は、高階関数なところやろ。
シェルスクリプトの関数型的要素は、コマンドを高階関数として使うところやろ
パイプラインを複数つなげられるところではない。 まだやってるのか、グルー言語だろに
本来もだしほとんどの場合も。コマンドを高級関数だって。なんかPOSIXな人は言語として扱ってるような感じだが。だがawkが主だったりしたり
パイプラインもストリームの一つだろうに、開く閉じる書く読むをほとんど意識しないからパイプラインの方が適切かなあ
変なとこの自説をぶってるなあ グルー言語だったら、その他は何にも当てはまらないとでも言うつもりだろうか?
グルー言語 かつ 関数型スタイルの言語ってだけだろ > パイプラインもストリームの一つだろうに
変なとこの自説をぶってるなあ(笑)
関数型スタイルでいいだろ
パイプラインだーって自説をぶるなよ(笑) 関数型スタイルという表現すらも自説のぶん回しだと気づいていらっしゃらない……?
コマンドが高階関数なら >>319 にあるように受け取ったコマンド列文字列を適用するとかそういう扱い方をすることになるんだけど本当に意味分かってて使ってる?
もし本当なら書いてるシェルスクリプトなり任意の関数型言語のコードを見てみたいものだ ストリーミング君はいろいろ詳しくは知らない漠然とした知識と他は妄想からの思い込みで言っているだけだな
初歩的なコンピュータサイエンスの知識さえ怪しい。端々にポロポロ出てるのに自覚ないからな 高階関数すら理解してなかったかぁ
>もちろんちゃんとシェルスクリプトのスタイル(関数型)でコーディングするのは大前提
それでよくこんなこと言えたねぇ
シェルスクリプトのスタイルは関数型ww
大前提www >>349
ほらね、反論なしだね
それが答えだよ
結局、違う気がするけど言い返せないと
お前は言ってるんだよ >>345
> 関数型スタイルという表現すらも自説のぶん回しだと気づいていらっしゃらない……?
自説のぶん回しで何が悪いのか?
自説のぶん回しで何が悪いといい出したのはお前じゃん
しかも理由もなしで 自説のぶん回しにたいして、自説のぶん回しを持ってきても何の反論にもなってないし
反論せずに、wwwだけ並べても反論にはならない >>351
あらごめんこれは私が読み間違えてた
そこに関しては自分の言葉だと分かった上で発言してるようだし、撤回するし謝るわ
ただ私は >>342 ではないので後半には答えようがない
敢えて答えるならその定義を認めるか認めないかの話になってしまっているので、不毛な議論である点は問題かなぁ
悪であるとか間違いであるという意味の問題ではなく、理解を得る納得してもらう認めさせるという目標に対して困難さがあるという意味での問題ね これが結論
https://qiita.com/piroor/items/77233173707a0baa6360
ところで、「流入してくるデータを加工して返却する」「ステートレスな」処理が得意で、
「内部で複雑な状態を持つ必要のある」「ステートフルな」処理が苦手だというのは、
関数型言語にも見られる特徴です。14
そう考えると、シェルスクリプトで凝った事をしようとする人があまり多くないのも頷けます。
「関数型言語は難しい」と言われる事が多いですが、他の言語とパラダイムが違う言語だと思えば、
これまでのプログラミングのパラダイムに囚われたままでは理解が進まないのも当然です。
14. 実際、関数型言語が得意な人にこの説を披露してみた所、
「関数型言語というのはストリーム型のデータを処理するという所が
キモ(なので、解釈としてそう外してはいない)」という感じの感想を頂きました。 ? >>352
そういうときは、広く通じたり受け入れられたりしたもののほうが、そうでないものよりも正しいんやで。
声がでかくしつこいほうの勝ちではない。 >>355
「〇〇じゃないかもしれない」は反論じゃないんやで
「○○じゃないと思ってるが反論できない(じゃあ正解なのでは?)」という意味なんやでw >シェルスクリプトに適しているのは〜 フィルタ的な働きが求められる種類の仕事にも適しています
ってあるじゃん、そもそもそういうものでしかなく(それを実現してるのはパイプ=シンプルなプロセス間通信という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
え?関数型って新しいんでしたっけ?w
シェルスクリプトと同じぐらい古いものだと思ってるんですがー? >>359
関数型スタイルでもない、「関数型」なんて意識してないのが明らか
勝手に間違った造語作って偉そうにされても困る >>361
古くからあるらしいが、そんなの世間に出てもてはやされたのは最近って話だろうに
それはあんなサイトを貼ってるので証明してる
優秀なんだぞと暗に主張したいんだったら、少しは他社の目ももとうな 自分であんなサイトを自慢げに貼って何を言っているのかな?
そんな古く周知されてるなら、あんなサイトを持ち出さなくてもいいし、一人延々と自説を唱えることはないわな
表記的表記的には同じようにステートレスとやらになるが MS-DOS batch fileも関数型の親戚か?
で結論は出ているから、もうおしまい 自分であんなサイトを自慢げってなんのこと?w
ググって出てきたものを貼ってるだけなんだけど
記事の内容じゃなくて、サイトを批判してるようじゃぁ
説得力ゼロですなぁ >>366
> MS-DOS batch fileも関数型の親戚か?
ぜんぜん違う
コマンドを実行してみりゃわかることだがWindowsのコマンドは対話型
実行したら「○○を処理しました。」とか標準出力に表示されたりして
ストリーミング処理できるように設計されていない
もちろん並列処理が行われないなどという点もあるがそれ以前の問題
お前はパイプラインの有無で判断しているからバッチファイルも同じだと
考えているようだが、パイプラインは関係ないと最初から言っている ググる必要もないだろうにって話だが?>>361の反論からは
あんなサイトっていうのは別に書いたのがあなたというわけではないよ
というか>>361以下の反論が反論になってないな、散々反論反論言っていたんだから、自分でちゃんとした反論をしなさいよ
>>368
全然読めてないな、あのサイトも>>360も
あなたがシェルスクリプトを関数型と根拠にしたのはパイプで繋げるだからな、あのサイトの抽出したのもそこだろう、MS-DOSでもそこは表記的表面的には同じ > あなたがシェルスクリプトを関数型と根拠にしたのはパイプで繋げるだからな
別の人と勘違いしてるねw
パイプラインとか言い出したのはこいつ(>>285)
> シェルスクリプトは、フィルタ型とかパイプライン型とか呼べばいいのでは。 重要なのはパイプラインではなく、ストリーミングであるという所だ。
つまり1行1データになってないといけない
MS-DOSはそうなってないので全く的外れ >>354 って自分で書いたくせに何をおっしゃってるのだが
まさかググっただけ中はよく読んでない、都合の良さげの文があったのでというのか?
ちゃんと自分で改めてあのサイトの内容を見てから言いなさいな、まさしくパイプで繋げることしか書いてないから=それが関数型に似てるだけだから
なんだか知らんが俺が決める仕様なのか、関数型とやらは。誰も納得しないだろうな、その俺が決める仕様なら > >>354 って自分で書いたくせに何をおっしゃってるのだが
354にはパイプラインなんて出てきてませんねぇw
> ところで、「流入してくるデータを加工して返却する」「ステートレスな」処理が得意で、
> 「内部で複雑な状態を持つ必要のある」「ステートフルな」処理が苦手だというのは、
> 関数型言語にも見られる特徴です。14 なんつーか、設計方針を理解してないみたいだな
「パイプ」があれば、設計が同じだと思ってしまう
その程度の理解力なんでしょうね 自分では「パイプ」とは書いてない、抽出した先で抽出した文がパイプだけのことをを指してあっても、自分は書いてないからかあ
どういう思考してるのか理解できないな
>>374
ますます自分の都合の良い捻じ曲げ方してますねえ
自分で抽出した先でそのことだけを言及して、それを自分で開陳してるなら、抽出した先でパイプで繋げることしかなら同じだろうという、いたって単純な結論になるのは当たり前
しかも「これが結論」って自分で書いてらっしゃるんですけど
ちなみに、よく読めばわかるだろうと思うのだが、あれを書いた人もそんな設計方針が必要なほどのことはシェルスクリプトで書かないよ、そう書いてあるでしょう ストリーミンガーには、まず「関数型スタイル」というものをあきらかにしてほしい。今さらだけど。
ところで、あのWebページのひと、なんかかわいそう。。。
シェルスクリプトには関数型的な特徴がある、ふつうのスクリプト言語とはちょっと違うような、と言っただけなのに、針小棒大にネタにされて。 > 抽出した先で抽出した文がパイプだけのことをを指してあっても
ストリーミングと書いてますが? シェルスクリプトには関数型的な特徴がある、
シェルスクリプトには関数型スタイルである、
同じことを言ってますねw >>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
内容にコメントしたら、話が通じないからね。w
シェルスクリプトが「関数型スタイル」だとか、意味不明な発言をしているうちはムリムリ。 だから意味不明な理由を言えばいいだろw
言い訳ばっかりだな >>389
>>376
無限ループかな?w
ま、まともな会話はもう期待してないから、どうでもええで。
人語を理解しないのだからしゃあない。 >>392
シェルスクリプトに関係ない話を始めたのはそっちやで。
シェルスクリプトはもちろん、関数型言語にも関係のない、独自スタイルの話をえんえんぶちあげられたんやから。
「関数型スタイル」て。w
人語がしゃべれないのに長々と相手してもらったことを感謝するべき。
そして、>>304はこのことを深く記憶して、これからは相手をよく見て話してほしい。
頼むで! あの〜。なんでみなさん「個人の感性」を根拠にできるんですかね。
この世界では学者はそんなに重要じゃないのかな。
そんなことないと思うけど……。 個人の感性以上でも以下でもない話題だからじゃないですかね 個人の感性ですかねぇ?
シェルスクリプトはreturnで数字以外返せない。返すには標準出力を使う。
つまり a=$(hoge) とか hoge | other_command とかするしか無い。
そうすると前者はサブシェルになるから変数、つまり状態を書き換えられない。
正確には書き換えられるけど破棄される。後者もサブシェルだから同様。
前者はストリーミング処理ではないが、大量のデータを扱う場合は遅くなるので推奨されない
しかしこれを改善するつもりはないだろう。なぜなら大量のデータを扱う場合は後者の書き方を使えばいいからだ。
後者の書き方は関数型が得意とするストリーミング処理。
シェルスクリプトで遅くならない書き方をすると自然とストリーミング処理になり
変数が書き換わることもない。そしてパイプラインは並列処理が行われる。
ここも並列処理が得意な関数型の特徴と似ている。
これらの事実はシェルスクリプトが関数型として設計されているとみなすには十分な理由だろう。 またアホが出るのか。。。
たまたま見えた特徴だけから同一視しちゃうとか。w
>>396は、ちゃんと後片付けしていけよ。
頼むで! な?ちゃんと書いた所でまともな反論が返ってこないんだもんな。
自分で「シェルスクリプトと関係ないレス。w」と言っておきながら
それをすぐ自分でやっちゃうわけだ。
そういうことを自分がしているという自覚がない証拠。 >>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
> ぜんぜんちがうことだから。
だからぜんぜん違う理由を言えとw >>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
「○○風」の定義の話ですか?
それはお前の定義ですよねw >>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に頼んな。w
Pythonのほうはきっと困ってるから。
だいたい、Pythonのドキュメントが一般に通用するかも定かでないのに。
自分の言葉で、自力で頑張れよ。 >>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
それは対話的な使用での話で,
シェルスクリプトの話じゃないです。 >>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
あ、もしかしてお前、「自分以外には見れない」ことを
(シェルスクリプトで)チェックすることはありえないと思ってんの?w
sshがやってるんですが? なに言ってるの?sshのシェルスクリプトでやってるってどのシェルスクリプト? >>459
どうもお前は話が理解できないようだから
数字で答えてくれ
あるファイルが「自分以外のユーザーから読み書きできるかどうか」を
確認したいことは
1. ありえる
2. ありえない
3. 想像力がない
4. 言ってることが難しすぎてわからない(笑)
レスするのは数字だけな。それ以外の言葉はいらんから(全部言い訳としてみなす) はあ...
答えるのもアホくさいが、>>449って書いてんだから 1 に決まってるだろ
>>449、また、読めなさそうなお前のために>>457って書いてんだろに
読めればそんなアホくさい問題を出さないだろうに(わざわざそんな何行もかけてw)
実はお前のなんか知らんが偉そうなw自説はダメなはずだぞ。なんででしょう?
(sshのシェルスクリプトでやってるってどのシェルスクリプト?ってのも答えてな、そのアホな質問にこんだけ答えてやったんだからw)>>459
>sshのシェルスクリプトでやってるってどのシェルスクリプト?
なんか制限を勝手に付けたが、いつもの自分の都合の良いように反論押さえ込むだけの馬鹿な言葉なので無視 ああ、
あるユーザ=管理者権限がある=sudoが使える
な
一般ユーザはそんなことする必要もないしするべきでもないから、2 な >>461
言い訳するな。数字だけ答えろ
「自分以外のユーザーから読み書きできるかどうか」をtestでは調べることができない
1. YES
2. NO > 一般ユーザはそんなことする必要もないしするべきでもないから、2 な
うわーw
一般ユーザーが、自分以外はファイルにアクセスできないような
パーミッションになってるかを確認する必要はないって
いっちゃったよこいつwww 答えたぞ。読めない読まないのは知らない
質問するのはいいが馬鹿な偉そうな素人のような態度での質問のしかたは辞めなさいw
言い訳でもなんでもいいから俺の質問にも応えてねw
sshのシェルスクリプトでやってるってどのシェルスクリプト?
実はお前のなんか知らんが偉そうなw自説はダメなはずだぞ。なんででしょう? >>464
逆にある場合を具体的に言ってみてほしいな
俺の言うことはあり得ないとそんなアホのように馬鹿にした表現するなら > sshのシェルスクリプトでやってるってどのシェルスクリプト?
sshのシェルスクリプトでやってるなんて一言も言っていません。
自分の都合のいいように読み替えるのはやめろ >>466
> 逆にある場合を具体的に言ってみてほしいな
こいつヤバイなぁw
ファイルに他人には秘密にして置かなければいけないような
パスワード等を保存したとしても、パーミッションが
問題ないかを確認したりしないって言っちゃってるよw
ドコモ口座とかこういうやつが原因なんだろうな >>467
なんだ
>あ、もしかしてお前、「自分以外には見れない」ことを
>(シェルスクリプトで)チェックすることはありえないと思ってんの?w
>sshがやってるんですが?
って、括弧付きでわざわざ シェルスクリプト って書いていて、続いて、sshって書いてるから、そんなのあるかと思った
sshが〜なんて、sshって別次元のある意味当たり前の話だからな
sshも作るときはパーミッションを設定するが、読み書きは読み書きできるかどうか(単なるopenできるかどうか)じゃないのかなあ、知らんけど
ともあれ、すっきりしたwから、どうも >>468
>ファイルに他人には秘密にして置かなければいけないような
>パスワード等を保存したとしても、パーミッションが
>問題ないかを確認したりしないって言っちゃってるよw
イミフすぎw
何でそれを管理者権限もない一般ユーザが他のユーザのそれをしなきゃならん??のだか?
何言ってるの??
なんか管理がむちゃくちゃなシステムを作ってそうなお前がやりそうだけどw > 何でそれを管理者権限もない一般ユーザが他のユーザのそれをしなきゃならん??のだか?
こいつ理解力ゼロじゃねw
管理者(root)の話を持ってきたのはこいつだけど、
俺の話には管理者という登場人物は出てきていない
くり返し言うね。
「自分(=一般ユーザー)以外のユーザーから読み書きできるかどうか」を
(自分=一般ユーザーが)testでは調べることができない
この話をしていたという理解力はありますか? もちろん俺は
「管理者権限もない一般ユーザが他のユーザのそれをしなきゃならん」
などと一言も言ってません。
こいつはいつも、自分の思い込みで発言を改ざんしています。 だから既に答えたことを質問すんなって
ちゃんと管理してる(てかいたって当たり前の)環境では、「必要ない/すんな/あり得ない」よ、当たり前に
同じ質問繰り返してばかり堂々めぐりではなくて「逆にある場合を具体的に言ってみてほしいな」に応えた方が話は進むと思うぞw
あと、悪いが、
実はお前のなんか知らんが偉そうなw自説はダメなはずだぞ。なんででしょう?
も、よろしくw >>469
こいつには、かっこの使い方も説明しないといかんのか(呆)
丸括弧
https://kotobank.jp/word/%E4%B8%B8%E6%8B%AC%E5%BC%A7-636089
文章表記中などで用いる( )の記号。補足説明や省略可能などを表すのに用いる。
「(シェルスクリプト)」は補足説明であり省略可能なんだから
重要な言葉じゃねーんだよ。はー、こいつ日本人じゃないだろw >>473
お前に言っておく。
自分で作ったファイルに他人には見られてはいけないパスワードなどを入れるなら
パーミッションに問題がないか必ず確認しろ
このように「自分以外が見れないことを確認する必要」はあるんだからな >>474
お前はいつも指摘の仕方が異常
お前自身ががその程度なのかもしれないがという話にかならんぞ
なに当たり前のことを言っているねん
それに、逆に補足するということはそれもある意味重要ということだぞ?別にどうでもいいなら補足もしないからな 重要なときには ”ダブルクォートで” とか「かぎかっこ」でくくるんだよアホw >>475
>自分で作ったファイルに他人には見られてはいけないパスワードなどを入れるなら
パーミッションに問題がないか必ず確認しろ
なるほど、むちゃくちゃなシステムなんだな
自分では確認できない、他人になり変わらないとわからないってかw
大丈夫、お前の使ってるようなお前が作った変な環境なのは使ってない作ってないから
てか、lsで確認できる程度なら全然関係ない話だろうがっ。それも自分のではなくて他人のって話だろうが、お前のは(一般ユーザがすることではないな)
無理がありすぎな設定だな。また妄想の世界に入ってるのか
>lsで確認できる程度
ここのヒントがあります(ナゾw) >>478
もう「testでは自分以外が見れないことを確認することができない」って話をしてること忘れちゃったの? >>477
括弧付きでも保続で書くのは「[ある意味]重要」な
本当にお前は読めないヤツだな
だからそんな当たり前のようなことを書くのは、お前自身が〜だってw >>469で自分から括弧の話題を初めたのに↓
> って、括弧付きでわざわざ シェルスクリプト って書いていて、
何を言ってるんだろうこいつはw >>479
わかった、話が通じないのは
test なんて自分で読み書きできるかどうかだけの話、それを他のユーザが読めるか確認するために使おうとする奴なんていない
ls(他)使うのは当たり前(ていうか普通コマンドなどで確認するよなw)
お前のいうtestをそんなので使うシチュエーションなんてハナからあり得ないから俺の頭に入ってこなかった
あくまでも、ファイル読みたい書きたいの話でしかしてない、俺は
なんか悪かったなw
悪かった答えの一つとしてACLを調べればいいよ。lsで確認できない、ACLはパーミッション無視してACLでのになるシステムもあったず
(めんどくさいからお前のいう目的でもsudo+test使った方が簡単だと思うぞw ダミーユーザ作ってもな、コマンドで確認しても後で変わるような変なシステム使ってるなら) >>481
あああぁ
「で」は「だが」のつもりだったんだが、なんでか「で」と打っていた
そりゃお前が噛み付くのも仕方がないな、そこはスマン >>434の質問に対して、>>482という答えを言うバカでしたね(笑)
434 名前:デフォルトの名無しさん[sage] 投稿日:2020/09/23(水) 13:32:17.22 ID:BgUeNus/ [1/3]
lsコマンドをシェルスクリプトの中で使う場合ってなにかある?
ファイルの列挙に関してはfindコマンドや,もっと簡単にグロブとかを使った方が
余計な書式を含まずに処理しやすいし,
ファイルの情報に関してはtestコマンドの方が一発で分かる
(例えばディレクトリかどうかはlsコマンドの場合権限欄の情報を文字列として
解析しなくてはいけない(先頭にdがあるかどうか)が,
testコマンドの場合はtest -e && test -dで完結する)
lsコマンドを使わないとできないシェルスクリプトでの処理ってなにかあるかな。
興味本位でききたい(言わずもがなだけどlsコマンドが不要!とかそういう話ではなく)。 お前が質問とは関係ないシチュエーションの話をいきなりしだしたのがだな
質問者もそんな目的でtest使おうとは思ってないだろうw 質問と関係ないシチュエーション?
自分以外から読み書きできないことを確かめるというシチュエーションは
testではできずlsではできるので、質問と関係ありますが?
> 質問者もそんな目的でtest使おうとは思ってないだろうw
すでに、礼を貰ってるんだがw
> 443 名前:デフォルトの名無しさん[sage] 投稿日:2020/09/23(水) 16:43:09.16 ID:BgUeNus/ [3/3]
> >>439
> あーこれはあるな。
> thx
な?こいつ色々やばいだろ?w だから、それもそのユーザがという話だろう。それが俺の言う
質問者がどっちかというのは知らんけど、さすがにtestを使ってるならお前の言うようなシチュエーションはないなっていう、そう書いてるだろ >>487
>そう書いてるだろ
俺がな。いちおうw
>>486
しつこく自説を書き偉ぶりたいなら、お前のは重大なミスw(なんか急にドモモが〜とか言い出すんだから重大なんだろうw)があると思うからちゃんと調べてから書いてね、せっかく「教えてやったw」んだから >>487
俺のシチュエーションは質問者が「あーこれはあるな。」と言いました。
それとは関係ないお前のが考えたシチュエーションの話を始めないでください(笑) ドコモ口座のくだりは「自分以外が見れないことを確認するというシチュエーション」を
あなたが思いつかなかったからですねw 質問者「lsコマンドをシェルスクリプトの中で使う場合ってなにかある?」
ORLEAcPg「testを使ってるならお前の言うようなシチュエーションはない」
な?会話になってない シチュエーションは書いてないね
だから、それも その別のユーザが読み書きしたいときにできるか確認=読み書きできないのかではなくて読み書きしたいができるのか という話も全然ありえるね
多分、>>446もそうだと思うよ「スクリプトで書くと」と書いてるしね
質問者も。理由を書いてるように
お前のようにはなりたくないけどw、多分俺の方じゃないかなあどうかなああ
お前はそのシチュエーションに当たった想像した時にtestを使おうと思ったの?そんなに自説に拘るとは > だから、それも その別のユーザが読み書きしたいときにできるか確認=読み書きできないのかではなくて読み書きしたいができるのか という話も全然ありえるね
質問者「lsコマンドをシェルスクリプトの中で使う場合ってなにかある?」
俺「他のユーザーが読み書きでないこと確認したいときはls使うしか無いよ」
質問者「 あーこれはあるな。tkx」
ORLEAcPg「読み書きしたいができるのかというシチュエーションがー」
意味不明w >>492
>理由を書いてるように
俺がな。いちおうw
大げさに急にドコモが〜とか騒ぎだしたくせに、責任転嫁か、意味不明すぎ
脊髄反射のような内容のない連投は辞めろよw 自説は一歩も引きません、俺の頭の中で思ったことは全て正解ですそれしかありません
モードに入ったか
すでにそれだけじゃないと書いたので ちゃんとそれに対して 反論してね(なんて言いたくはないが誰かの常套句なのでw) 会話のキャッチボールができてないんだろうね
俺は質問者の質問に対して、testではできずにlsでしかできないという一例を
言ったのにこいつは何が言いたいんだろうかw
ORLEAcPg「testを使ってるならお前の言うようなシチュエーションはない」 >>495
お前は質問者の質問に対して何を言いたいのか
それだけを書いてみてよw
無理だろ?お前は質問者を置いてきぼりにしてるからね >>497
だから質問者の質問に答えろってw
2回目 すでに書いてる。堂々巡りだな、それでよくキャッチボールとかw
そして ls はお前の言うようなのでも俺の言うようなシチュエーションでも不備があるともなw > すでに書いてる。
聞いてるのは質問者への答えだが?どのレス?
言えないはず >>499
イミフ
ls は使うよ。使う場合はお前じゃない人が書いてる場合とか
あえて言うなら、お前のそれだけじゃ使えない場合もあるよってことかな
てか、なんでお前がそんなレスするのかイミフすぎw > そして ls はお前の言うようなのでも俺の言うようなシチュエーションでも不備があるともなw
質問者にlsを使う場合を聞かれたから、その答えである「lsを使わなければいけない場合」を俺が言ったのに、
なぜか「lsでは駄目な場合もある!」と言い出してけんかを売ってくるアホw >>502
だから俺じゃなくて質問者の質問に答えろってw
3回目 >>501
お前の頭の構造は計り知れない。わかるかっw
そしてイミフなことを急に言われても困惑するだけ 「質問者の質問に答えろ」の意味がわからないらしいw >>503
補足だよw
ホントにお前は自分のミス/抜けなりを絶対に認めないマンだなw
>>504
堂々巡りw キャッチボールとはなんなのか。お前のは壁当て(?)だ 質問者の質問に答えてみろっていっても、やっぱり俺にレスをするw
4回目 >>506
なんで「お前が」「俺に」命令してるのか、全くわからんな
真っ当な根拠をちょっと言うてみ >>508
>質問者の質問に答えてみろっていっても、やっぱり俺にレスをする
>質問者の質問に答えてみろっていっても、
>やっぱり俺にレスをする
超絶イミフすぎw イミフという言葉でごまかして
質問者の質問に答えないw
6回目 しょもな。さすが自称キャッチボールできるが実はしたことがない人だなあ
ショーーーもなっ 質問者の質問に答えないからキャッチボールできてない
7回目 >>512
>>509
以下のレスに対しても
てか同じレス繰り返してるだけだと 荒らし だよ >>515
心当たりないと思うけど、 ID:ORLEAcPgはレスを返したつもりらしいよw >>515
こいつ とは 誰もが こんな風になる何度も繰り返してるパターンだから気にすることないよ
>>517,518
よく言うよww何言ってんだか どっちの味方をする訳でもないんですけど,
私の質問を別の言い方で表わすなら
「(対話的でない)シェルスクリプトにおいて
私はlsコマンドを使う意義をあまり感じないんだけれど
(なぜならlsコマンドを使うほぼ全ての状況において
やりたいことをもっと簡単に実現できる
コマンドが用意されてるから。例: find, test),
lsコマンドを積極的に使わないといけない場合はありますか」
ということで,それに対して
「ある。lsコマンドでないと他人の権限を確認できない。
(testコマンドは自分の権限のみ)」
という解答を頂いたので,それで十分です。
ありがとうございました。 どういたしましてw
lsは対話型で使うようなイメージだけど
POSIX準拠コマンドは最低限だが必要なコマンドを網羅しているはずという観点から見ると、
もっと簡単に実現できるコマンド(findやtestじゃなくてstatなどね)の多くは
POSIX準拠ではないので、じゃあどうやって実現するんだ?と考えると
lsコマンドでできるじゃんという結論に達するんだよ
その結論を前提としてlsコマンドの仕様を再確認すると
lsコマンドの出力形式はちゃんと決まっており
(対話的でない)シェルスクリプトから使うことも
想定されてることに気づく
lsコマンドは一覧表示だけではなくファイルの属性を
取得するためのコマンドでもあるんだよ >>434
何万ファイルもあるディレクトリ以下の実際のファイル数をカウントしたい時とか。
ls -U ディレクトリ | wc -l
が速くて良いかな。
これじゃディレクトリも一緒にカウントしちゃうか・・・ うう。リロード忘れてとっくの昔に終わった話にレスを・・・orz あ、まだ終わってなかったかな?
まあでもたいした事書いてないからどうでもいいや。俺のことは忘れてくれ。 普通に使うな。逆になんで使わないと思うのか不思議
lsで問題があるようなら言うような別のをにするけど いろんなコマンドを臨機応変に使うことが気になる質だったんやろ。
好き好きとしか。 >>526
POSIX限定コマンドじゃないなら
ls以外でほとんどのことができるからでしょ
macOSがオプション違っていて面倒くさすぎるってのを除けば
パーミッションとかもstatコマンドで取得できるし
それにしてもWindowsはLinuxに対応したから楽になったけど
macOSはBSD系だからローカルでテストして
そのままサーバーに持っていくってのが難しくなってるなw 訂正
POSIX準拠コマンドに限定しないなら
ls以外でほとんどのことができるからでしょ >>527
ls使わないだからな、臨機応変ではなさげ
好き好きにとしかは同意 >>530,527
ああ、
>コマンドを臨機応変に使うことが気になる質
は、他の人を指してるとも読めるな。そっちのつもりならすまん >>531
使うことが気になる(から使いたくない)質 >>532
>>531の、
>コマンドを臨機応変に使うことが気になる質
は「ことが気になる質」余分だった「コマンドを臨機応変に使う」だなと書き込んだ後で気がついた。まあいいかとほっといた(真逆(?)なんだが)。すまん
なんとなくw理解。どうも&重ね重ねすまん 誰とは言わんけどツイッターで永遠と古い記事繰り返し流してるボットいるよね
リンク切れてるし邪魔なだけなんだけどああいうの消し去りたい https://zenn.dev/mattn/books/bb181f3f4731920f29a5/viewer/5
> 既にシェルスクリプトのみでやる領域を超えてきています。
> 本来ならば正しいプログラミング言語を選んで正しくフィルタリングすべきだと思います。
と書いてありますが、これを「正しいプログラミング言語」で書くとどうなりますか?
シェルスクリプトだけでやるより分かりやすくなりますか? >>535
Windows のRuby で、JSON ファイルをダウンロードして保存する、部分だけを作ったが、
85KB のファイルの中身には、日本語は無く、
ほとんど、\u6708 みたいなユニコード・コードポイントの表示ばかりで読めない。
{{\u30ab\u30ec\u30f3\u30c0\u30fc 10\u6708}}
ダウンロードする際の、オプションでも間違ったのかな?
download_file = "wikipedia.json"
# ファイルが存在しない時だけ、ダウンロードして保存する
unless FileTest.exist? download_file
require 'open-uri'
require 'cgi'
require 'date'
today = Date.today.strftime( "%-m月%-d日" ) # 今日の日付。1桁表示。例、10月1日
url = "https://ja.wikipedia.org/w/api.php?format=json&action=query&prop=revisions&rvprop=content&exintro&explaintext&redirects=1&titles=" +
CGI.escape( today ) # URL encode
# ダウンロードしたファイルを保存する
open( url ) do |file|
open( download_file, "w" ) do |out|
out.write( file.read ) # 書き込み
end
end
end >>537
やっぱり逆に長くなってるし分かりやすくなってないですよね? Ruby の方が、一般的な関数を使っているから、分かりやすい。
例えば、CGI.escape で、URL encode してる
元のサイトだと、date +%-m月%-d日
の部分を、何かでエンコードして、以下のようにして、
date +%-m%%E6%%9C%%88%-d%%E6%%97%%A5
それを、titles の所に書いている。
titles=$(date +%-m%%E6%%9C%%88%-d%%E6%%97%%A5) > Ruby の方が、一般的な関数を使っているから、分かりやすい。
その理屈だとシェルスクリプトにもそのような関数(コマンド)があればいいって話になるよね? シェルスクリプトの場合はJSONからデータ取るのにjqのミニ言語を覚えなきゃいけないというのはあるけど
Wikipediaのように構造化しにくいデータをテキストのまま加工するならそこまで大きな差はないよね
便利な関数が用意されてるかどうかやエラーハンドリングがやりやすいかどうかくらいの違い
Wikipediaのデータ用のパーサー使ってテキストじゃなく構造化したデータを扱えるなら差が出てくる jqのミニ言語 vs 言語のパーサー?とかだろうけど
結局、jqのミニ言語の方が小さくならね?
それでも言語のパーサー使うってことは
大きくなったら、さくっと複雑な正規表現一発よりもも
愚直に文字や単語を検索していって処理を書いたほうが
分かりやすいと言ってるのと同じようなことなんかな? 答えを教えてくれという質問に答える必要があるのか? なんでRubyなのか。初心者ならどのプラットフォームでも動くPythonを勧めておけよ。 >>543
答えたくないなら何も話さなくていいのに
そのような質問をする必要があるのか?w macOSがzshに変わっても/bin/shはbashなんだしzshでコード書くやつなんておらんだろと
思っていたけどzshrcとかで書くことはあるんだな 何言ってるのかと思ったら、zsh固有のを使ってことか
誰も好き好んでそうシェルはそう変えないけど、デフォがzshになったらそれなりに出てくるんじゃね
だいたいがデフォだからそのシェルを使ってるって理由にならない理由wだからな
>zshに変わっても/bin/shはbashなんだし
bashismに慣れているんだったら脱却した方がいいぞ。あくまでも過渡期(変えた直後)だからそうしてるだけで、そのうち無くなるぞ。絶対何かに変わる。dashとか(dashとは言ってない) なくならないほうに賭けるぜ!
Bashはもうなくせんやろ。w bashはなくならないが、インタラクティブシェル
/bin/shはdash、もしくはPOSIX準拠のシェルだろ
dashよりも速いシェルって作れる気がするんだよな
JITとか取り入れてさ メンテするのめんどくさくなって消してしまうのが定番だからなあ
必要なら自分で入れろになると思うよ。いつも通りならw dash dash dash
bash and dash bashismは嫌いだから/bin/shはdashにしてbashをオプショナルにするか
POSIXで標準化して欲しい >>553
既存シェルスクリプトの動作検証よりはマシやろ。w
BashとかPerl5とかはすでにインフラみたいなもんだし。
まあ、Python2も消せないやろ、と思ってたら、意外と3のみになったもよう。 >>556
何を言っているのかイマイチわからん
現在の bash 3.2 ですら時代遅れだし、Apple自身でメンテしなくてはならない
macOS内でApple製のスクリプトがあるんだったらもちろん代替になるので問題なく書き換えられるだろう
今まで通りならmacOSバンドルとしてはインストールされなくなるのは当然のような帰結 macOSの/bin/shのbash3.2はもう負債だよねw
これからAppleはどうするつもりなんだろ
zshは互換性ないし、dashにしたら機能低下だしw >>557
あー、アポーの話だったか。。。
まあ、今までも互換を壊すときには平然とぶち壊してきたし、マジメに考えてもしょうがないのでは。w いつ無くなってもいいように今からしとこというマジメに考えたらの話だけど
マジメってどういう意味なのか知らんけど Appleは突然Swift出してきたりMetal出してきたりArm出してきたりであらゆる分野で考慮するだけ無駄というスタンス >>561
そうそう。w
Bashをなくしたとして、POSIX互換シェルをわざわざ残すのかと。
そんな心配をするよりも、今使えるBashを謳歌したほうが合理的やろ。 その今使えるbashっていうのがmacOSでは3.2なのよね・・・
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/migration_planning_guide/sect-migration_guide-package_changes-bash
Bash-4.0 およびそれ以降のバージョンは、 プロセス置換の構成をブレース展開を使って変更せずに渡すことができるようになるため、
内容の展開はすべて別々に指定し、 各プロセス置換を別々に入力しなければならなくなります。
Bash-4.0 およびそれ以降のバージョンでは Posix が指定するのと同様に、 SIGCHLD が wait の組込みに割り込みを許可するため、
全ての子を待機するよう「wait」を使用する場合、 子を終了したら SIGCHLD トラップは常に呼び出されることがなくなります。
Bash-4.0 およびそれ以降のバージョンは、 クローズ用の区切り文字 $() コマンド置換を検索する場合に
Posix のルールに従うようになり、 旧バージョンのような動作はしなくなりますが、
より多くの構文および解析のエラーを先に捕らえてからコマンド置換を評価するためのサブシェルを生成します。
Bash-4.0 およびそれ以降のバージョンでは、 パイプラインのコマンドのひとつがコマンド一覧を実行している間に
SIGINT によって終了させられた場合、 シェルは割り込みを受けたかのような動作をします。
Bash-4.0 およびそれ以降のバージョンでは、 set -e オプションの処理法が変更されるため、
パイプラインが失敗すると (失敗したパイプライン内の最後のコマンドが単純なコマンドでない場合も) シェルは終了します。
これは Posix が指定するものとは異なります。 この部分の基準を更新する作業が進展中です。
Bash-4.0 の動作はリリースの時点での合意を得ようとしている動作です。
Bash-4.0 およびそれ以降のバージョンでは、"." がシステムの PATH に存在しない場合でも、. (source) ビルトインが
ファイル名の引数を現在のディレクトリで検索してしまう原因となっていた Posix モードのバグが修正されています。
Posix では、このような場合シェルによる PWD 変数内の検索は行われるべきではないと述べられています。 >Bashをなくしたとして、POSIX互換シェルをわざわざ残すのかと
何もわかってないのに口出す馬鹿 シェル上で別の種類のシェルが動いたり、種類が異なるシェルが別のシェルの動作をエミュレートしていることを知らないんだろうね。 >>564
まあ見とけ。w
どうせあと数年でコロッと変わるんやろ。 変わるも何も現状及びその対応の予測の理解が間違ってるってことなんだがw POSIXという標準があるから変わるわけないんだよな
多く使われてるdebian/ubuntuがPOSIXに準拠を頑なに守ってる
/bin/shがdashが多いからPOSIX準拠で書くしかない
そうすればmacOSでも動く 1行目と2行目以降が繋がらない
bashのエミュレーションがちゃんとしてたら問題がなかったのにな
GNUはライセンスにうるさいwくせになぜあんなのなのだかな >>554
chown chown smbd
zip xargs smbd シェルスクリプト関連のツイート見てたらGPT-3?か知らんけど
AIで文章を生成して日本語に翻訳してるボットを発見したw
https://twitter.com/5hc7PFFLfvjD88V
https://twitter.com/5chan_nel (5ch newer account) 素人ですが世話になります
POSIXってシェルの最低限の共通規約って認識でいいんだろうか
機能を拡張しても所詮は方言だから封印しとけと grep -L pat file > /dev/null って捨てると返り血が変わる…? >>572
POSIXに準拠しておけば、Debian、Ubuntuの/bin/sh(dash)や
Alpine Linux(busybox)やmacOS(古いbash 3系)やmacOSのユーザーシェル(zsh)
でもそのまま、もしくはわずかな修正で動くようになるというメリットが有る
世の中全部bashやろーとか言ってるやつは、Debianで実際にシェルが変わったときや
macOSのbashが古いなどで変化に耐えられず、最新のbashしかしらん
どうせbash使うもんって言いはる羽目になってる
bash依存してるやつは、なにか理由があってbash依存してるのではなく
無知ゆえに必要もないのに[[ ]]を使ったりfunctionキーワードを使ったり
独自のforの書き方をしたり配列を使ってたりするだけ
ちゃんと知っていればbashスクリプトの9割は簡単にPOSIX準拠で書ける
もしPOSIX shではなくbashを使いたくなったら、他の言語を使ったほうが良い
POSIX shの機能は本当に必要なものだけを実装している。それがUNIXの思想
素人はまずPOSIXの機能だけ勉強しとけ
最初にbashから入ると、これはPOSIXで使えるんだっけ?って悩む羽目になる そういや日本人が作った口先だけのPOSIXの原理主義みたいな変なのがありましたねw
3人ぐらいのグループでPOSIXにしろーしろーと叫ぶだけで何も生み出さない
それを使って自分たちは商売してるから
本人にとっては生み出してるんでしょうが
あれに洗脳された学生とかは可哀想です。
だってそのグループ界隈以外ではまったく使われてないものだから >>576
いやいや、ニオイどころか、まるだしやろ。w
現実の動作確認もろくにできない机上のPOSIXを夢想してもしかたない。
んなこと、いちいちやってられんからな。 現実の動作確認ならDebianやmacOSやAlpine Linuxでできますが? >>578
原理主義者といえばそうかもしれんが、臨機応変なことができないのは確かそうだな >>579
それは、あくまで個々の実際であって、POSIXの証明にはならんやろ。 >>581
POSIXの証明って何の話?
bash拡張機能はbashでしか使えない。POSIX shの範囲でならどのPOSIXシェルでも使える
実際にbash拡張機能はDebianの/bin/sh(dash)やAlpine Linuxの/bin/sh(busybox)では使えない
という当たり前の話しかしてないが
俺に何を証明して欲しいん?
動かない命令でも書いてほしいんか?
array=(1 2 3)
↑DebianやAlpine Linuxで動かない。ほらPOSIXの証明になったろw POSIX STRICTチェックみたいなものないの?
もしくはピュアPOSIXの実装とか >>583
shellcheck
こういうエラーが出る
$ shellcheck posix.sh
In posix.sh line 3:
array=(1 2 3)
^---^ SC2034: array appears unused. Verify use (or export if used externally).
^-----^ SC2039: In POSIX sh, arrays are undefined.
For more information:
https://www.shellcheck.net/wiki/SC2034 -- array appears unused. Verify use ...
https://www.shellcheck.net/wiki/SC2039 -- In POSIX sh, arrays are undefined.
> もしくはピュアPOSIXの実装とか
それがdash WSL(Ubuntu)の/bin/shもdash、ピュアPOSIXの実装 dashの目的は、それまで使われていた/bin/shの代替
高速で軽量でPOSIX互換を目指している
この目的と目標は実現され /bin/shの代替として
Debian系(Ubuntu含む)などで多く使われている
FreeBSDやNetBSDでもashが使われてる
dashはそのashをDebian用に移植したもの
bashはインタラクティブシェルとしては一番使われてるだろうが
shebangのは/bin/shが使われることが多いので
シェルスクリプトを動かす場合はdashが一番使われているシェルだろう https://twitter.com/col_richie/status/1316543524569903111
リッチー大佐の中の人
@col_richie
「シェルスクリプトによる○○」と銘打ちながら、必要なものにPythonやGoが含まれるというなら、
それは「Pythonによる○○」あるいは「Goによる○○」に他ならな
なぜ「シェルスクリプトによる○○」と語ることにこだわるのか?
他言語に頼る時点で既にそんな資格はない。当たり前だろうが!!!
↓
郵便番号から住所欄を満たすアレを、シェルスクリプトで実装
https://github.com/ShellShoccar-jpn/zip2addr
https://github.com/ShellShoccar-jpn/zip2addr/blob/master/commands/parsrj.sh
※ これはシェルスクリプトではなくawk(笑)
# #
# === Generate the JSONPath-value with referring the head of the ======= #
# strings and thier order #
awk ' #
BEGIN { #
# Load shell values which have option parameters #
alt_spc_in_key=ENVIRON["sk"]; #
root_symbol =ENVIRON["rt"]; #
key_delimit =ENVIRON["kd"]; #
list_prefix =ENVIRON["lp"]; #
list_suffix =ENVIRON["ls"]; #
# Initialize the data category stack #
datacat_stack[0]=""; #
delete datacat_stack[0] #
# Initialize the key name stack #
https://twitter.com/5chan_nel (5ch newer account) https://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
NAME
awk - pattern scanning and processing language
awk - パターン走査および処理言語
DESCRIPTION
The awk utility shall execute programs written in the awk programming language,
which is specialized for textual data manipulation.
awk ユーティリティは,テキストデータ操作に特化した awk プログラミング言語で書かれたプログラムを実行する.
_人人人人人人人人人人人_
> awk プログラミング言語 <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄ >>591
awk ユーティリティは,テキストデータ操作に特化した
awk プログラミング言語で書かれたプログラムを実行する.
_人人人人人人人人人人人_
> awk プログラミング言語 <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄ たっくん
シェルスクリプトでTwitterBotっていうのを見かけたけど、「コマンドの実装にGoを使う」って書いてあって「うーん?」となってしまった
リッチー大佐の中の人
まったくだ。なめてるのかと。我らの小鳥男こそシェルスクリプトによる最強のTwitterクライアントアプリだ。
もちろん、別途シェルスクリプトを組めばbotも好きなように作れる。 https://github.com/ShellShoccar-jpn/kotoriotoko
↓ https://github.com/ShellShoccar-jpn/kotoriotoko/blob/master/UTL/base64
# Main
(cat ${1+"$@"}; echo '') |
awk ' #
BEGIN { #
# --- prepare #
OFS = ""; #
ORS = ""; #
# --- prepare encoding #
for(i= 0;i<256;i++){c2p[sprintf("%c",i)]=sprintf("%%%02X",i);} #
c2p[" "]="'"$instead_of_spc"'"; #
for(i=48;i< 58;i++){c2p[sprintf("%c",i)]=sprintf("%c",i); } #
for(i=65;i< 91;i++){c2p[sprintf("%c",i)]=sprintf("%c",i); } #
for(i=97;i<123;i++){c2p[sprintf("%c",i)]=sprintf("%c",i); } #
c2p["-"]="-"; c2p["."]="."; c2p["_"]="_"; c2p["~"]="~"; # POSIX準拠コマンドの中で言語と言えるもの
(セミコロンや改行区切りで "複数の命令" を手続き的に実行できるものを言語としています)
awk - pattern scanning and processing language
bc - arbitrary-precision arithmetic language
ed - edit text
sed - stream editor
他にもあるかな?
bcは複数の命令を実行できるから言語だけど
exprは式を評価するだけだから違う exでもできるん?
sedとか"s/a/b/"みたいに一行のコマンドを実行してるように見えるけど
実際には
s/a/b/
s/c/d/
みたいにsedスクリプトを実行できるわけだよね
sedは置換をベースとしたかなり独特な言語だけど
awkなんてBEGINで全部書いてしまえば
完全に普通のスクリプト言語になる
bcも実際はスクリプトを使って計算する
https://linux.die.net/man/1/bc の中間あたりにある例は
関数定義やif文while文も使っていて実は言語であることがわかると思う
まあ言いたいことは、シェルスクリプトからPythonやGoを呼び出していて
そこがメインで処理してるのがシェルスクリプトでないように
awkやsedでメインの処理を行ってるなら同様にそれもシェルスクリプトではない じゃCで書いてるコマンド呼び出したらシェルスクリプトじゃないね >>598
そのとおりだよ
シェルスクリプトで階乗を行うコードを実装しましたと言っておきながら
C言語でコードを実装して、シェルスクリプトではそれを呼び出すだけなら
それはシェルスクリプトで実装したとは言えない
シェルスクリプトで実装というのなら、シェルスクリプトで
定義されているものだけを使って使って作らないといけない
例えば変数展開(を利用した文字列処理)や算術式展開を使った四則演算や
case文を使った文字列パターンマッチング処理で作る
外部コマンド呼び出しは(そのコマンドを自分で実装してないなら)
外部コマンドと組み合わせてシェルスクリプトで実装したと言えなくはないが
そもそもその外部コマンドがPythonやawkのような"別の言語"を使うものなら
そこから別の言語に切り替わっている イチャモンつけるならmakeがチューリング完全って話にまで火花が散るので、適当な落しどころは
POSIXに規定されておらず、それ自身が汎用プログラミング言語であることを目的として実装されたインタプリタやランタイムに対して、目的の処理を委譲しているのをシェルスクリプトだと表現されると気に食わない人が居る
くらいでいいでしょ
イチャモンつけるのも程々にしとかなきゃただ相手の意図を汲み取るつもりのない人間でしかなくなるぞ >>600
厳密な境目を見つけたいんじゃなくて
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
The awk utility shall execute programs written in the awk programming language,
awkユーティリティは、awkプログラミング言語で記述されたプログラムを実行します。
と書いてあるんだから、awkは「awkプログラミング言語」 make は内部的にシェルを呼び出してるので
GNU拡張は無視するとして、makeの範囲だけでなにか作れるんですかね?
GNU拡張を含むなら沢山の関数があるので
それらを使って作ったものは当然シェルスクリプトで実装したことにはならないですよ あとイチャモンの内容は、Pythonで作ったものはシェルスクリプトではないのはそのとおりだけど
同じ用にawkで実装したものもシェルスクリプトではないんだから
awkで実装ばかりしてるお前(リッチー大佐)は自分のことを棚に上げてるwwwって言ってるだけ >>599
C言語でsystem()関数を使って、Bashを呼び出したら、シェルスクリプトだな! >>605
そりゃそうよw
そのシェルスクリプトでメインの処理を行ってるんでしょ? >>603
だーからそういう揚げ足取りがしょーもないって話してんのが分からんかね
awkがプログラミング言語であるのは否定しない
ただ発端の話者はPOSIX狂いで有名な上awk多用してるんだから、対象のツイート中で言うプログラミング言語がPOSIXを除くものについての言及と考えれば辻褄は合うし、そう考えるのも突飛な発想と言うほどおかしくはないでしょ
確かにその人は語り口が横柄な事があるし好かれる性格キャラ作りはしてないさ
でも個人憎しでしょーもない揚げ足取りしてんのは同等かそれ以上につまんねーことしてんなって感じだよ >>607
だから結論としては、awkはシェルスクリプトじゃないんだから
お前(しょっかー)もawk使ってるくせにシェルスクリプトって言ってるじゃん
ってことでしょ
それ以外になにか言うべきことあんの?
ないでしょ
それで話は終わりだよね >>608
意図的に悪意を持って相手の意図を読もうとしてないんだと思ってたら本当にただ単に日本語読めないだけだったんだね…
なんか…ごめんね? >>609
なんで相手の意図とか読んであげようとしてんのw
相手をかばう必要なんかないじゃん
awkはシェルスクリプトではない
事実だけを言えばいい >>610
意図を読む事を相手をかばうとか言ってる時点でコミュニケーションする気なし、端っから粗探ししてdisる気満々じゃん
そういうスタンスを俺は見てて気に食わないよ
それだけ >>611
意図じゃなくてお前の願望だろw
awkは明らかにシェルスクリプトじゃないし
POSIX準拠のコマンドだけを使って作ったというのなら、そう言えばいいだけで
そう言わない理由はあるわけがないので、単にそのことを理解してないってだけ
それをお前はかばおうとしてるだけだろ >>612
>>607 に対しての時点でその返しが来てたら分からんでもないけど、そこでスルーしてんのに今更言ってんのが議論とか意見出しがしたいんじゃなくて粗探ししてますって自白してるようなもんでしょ
そう言わない理由があるわけないは言い過ぎだよ
人間誰しも無意識の前提を置いてしまうことはある 恥ずかしいよねw
自分がシェルスクリプトといいながら、awkで書いちゃってるのに
他に人にはPythonはシェルスクリプトじゃないと言っちゃってるわけだw >>614
awkやsedはシェルスクリプトの一部とみなす慣例は大昔からだから。 シェルスクリプトに混ぜて書く場面が多ければほぼシェルスクリプトのようなものと思ったって何の問題もない それはお前の願望ですよね?
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
The awk utility shall execute programs written in the awk programming language,
awkユーティリティは、awkプログラミング言語で記述されたプログラムを実行します。 >>618
そうだよ。UNIXでもそう説明される。ただし、実態は単独では使われない。 awkをシェルスクリプトと組み合わせて使っても
awk言語がシェルスクリプトに変わるわけがないって話ですよね?
いつから単独で使われるかどうかの話にすり替わったんですか? シェルスクリプトがシェルのスクリプトだとわかってない? シェルのスクリプトから呼び出す
外部コマンド(awkやpython)が
シェルではないことぐらい知ってるよね スクリプトの意味がわかっていない墓穴掘り書き込みですね。 シェルのスクリプトはシェルが実行している
シェルとはdashとかbashとかzshのこと
そのスクリプトをシェルが実行していないなら
それはシェルスクリプトではない >>623
いやぁ、そこは「スクリプトの今は○○だ!」って
お前が宣言するところだよ
宣言しちゃったら、間違ってたときに恥ずかしいから言えないんでしょ?
相手のミスを待つんじゃなくてさ、自分の意見を言ってみなよ https://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
It was pointed out that with the rules contained in early drafts, the following 【script】 would print nothing:
BEGIN {
y[1.5] = 1
OFMT = "%e"
print y[1.5]
}
> the following 【script】 would print nothing: >>623
そのレスは何の目的があってしたの?
俺が本当のスクリプトを教えてやるぞってことなら、早く言って欲しい
ただの負け犬の遠吠えなら、そのまま黙ってくれると助かるね pythonのコードを描いてそれをログインシェルにしても良いんだぜ シェルスクリプトの話しかしてません
ログインシュルの話なんかしてません ほらね
馬鹿がバレただろ?
※理由を言わないテクニック(笑) dashはダッシュ
bashならバッシュ
zshはなんと読む? dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash
dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash
dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash
dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash
dash dash dash bash dash dash dash dash dash dash dash dash dash dash dash dash
dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash
dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash dash foo() { echo $A; }
A=1
A=2 foo
echo $A
ってやった時、1行目に2が表示されると思ってる。
そして2行目には1が表示されると思ってたんだけど
dashだと2と表示される。これってバグ? >>640
bashやzshでは1が表示される
dashでは2が表示される
ということです。 bashやzshが仕様通りだと思うけど
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01
If the command name is not a special built-in utility or function, the variable assignments shall be exported for the execution environment of the command and shall not affect the current execution environment except as a side-effect of the expansions performed in step 4 そもそも変数に代入しつつコマンド実行って
POSIXで規程されてない? あ>>642を読む前に書き込んだ。今から見てみる。 >>642
これは?
If the command name is a function that is not a standard utility implemented as a function, variable assignments shall affect the current execution environment during the execution of the function. It is unspecified:
Whether or not the variable assignments persist after the completion of the function
Whether or not the variables gain the export attribute during the execution of the function
Whether or not export attributes gained as a result of the variable assignments persist after the completion of the function (if variable assignments persist after the completion of the function) >>584
>> もしくはピュアPOSIXの実装とか
>それがdash
とりあえずこれはダウトということ? for music in `cat $OUT`; do
のようなループを書いている
1行ごとに仕事をさせたいのだが
1行の中には空白があり、1行の要素が分断されている
どうすれば分断を防げるだろう? tputってさどこまでがPOSIX準拠なの?
色はPOSIX準拠じゃないでしょ? AWKがシェルスクリプトに含まれるかどうかは
(定義不十分だし)勝手に議論しとけと思うけど,
GNU・BSD拡張を使っていないAWKで何か実装した場合それは
「POSIXに準拠している」と言えるわな。
だから「シェルスクリプトで〜」と言わずに
「POSIXに準拠したやりかたで〜」と言っておけば,
くだらない揚げ足取られずに済んだ訳だ。
時すでにお寿司🍣 >>655
あの人は何でもシェルスクリプトでできるって思っちゃってる人だから無理でしょ
POSIXと言いながら、C言語メインとかにはならない
1. シェルスクリプトでやるのがいい (基本)
2. できない? POSIXならC言語とか使ってもOKなんだよ!
POSIXは、シェルスクリプトではなできない事の言い訳として利用してるだけ
だからawkで作ってるのにシェルスクリプトだと言いはる C言語使ってって小さなフィルタープログラムをだろ
既存でないフィルターは自分で作るというある意味シェルスクリプトの本道でもあるだろう >>657
シェルスクリプトってまさにこの
「C言語で書いた早くて小さいプログラム」
を組み合わせる為の言語だと思ってる。
もちろんシェルスクリプトの制御機構は計算完備なので
シェルとしての機能だけでプログラムを書くこともできるけど,
Unix哲学≠ノ従うならそれはちょっと違うんじゃないかと思う。
シェルスクリプトで完結する人ってUnix哲学をやたら推すし,
Unix哲学自体は今でもある程度参考になるとは思うけど,
ほんとうにUnixらしいやりかたは
「主処理はC言語で書いて組み合わせはシェル」っていうことだと思う。 自分の中でのシェルスクリプトって
新たにプログラムを位置から作るんじゃなくて
既存のコマンドを使って繋ぎ合わせて
間に合わせのプログラムを作るものだと思ってる
自分はプログラミングできるから普通にプログラム書けるけど
コンパイルとかの煩雑な手順を考えると
シェルスクリプトをぱっと書いてすぐ使えるってのはすごい手軽
パイプ処理が肝かなと思ってる >>658
シェルスクリプトをシェルスクリプトで完結する必要はない。
例えば、C言語で作った何かや「awkで作ったなにか」を呼び出すのもあり
それは当然の話だし、否定していない
言いたいことは、それは「awkで作ったなにか」であって
シェルスクリプトではないということだけ
みとめよう。それはawkプログラミングだ シェルスクリプトで外部コマンドを呼び出すのはありだし
全ての環境で動かすならPOSIX準拠にしろと思うが
POSIX準拠にこだわる必要もない
例えば、dockerやgitはPOSIX準拠ではないコマンドだ
POSIX至上主義かなにかしらんが、シェルスクリプトから
使っていいのはPOSIX準拠コマンドだけだというのなら
dockerやgitすら使えないということになる
んなばかな(笑)
環境が限定される(つまりdockerやgitが入っていること)という前提で
シェルスクリプトでPOSIX準拠ではないコマンドは普通に使う
つまり何が言いたいかと言うと、シェルスクリプトで読みやすさのために長いオプションを使えという話だ
長いオプションはPOSIX準拠ではないからショートオプションを使え?アホか
どちらにしろPOSIX準拠でないコマンドを使うのだ >>658
あえてわざわざプログラムをCなりでつくるというのは、Unixらしいとは思わんな。
>>659のいう、既存プログラムを組み合わせることのほうがUnixらしい。
速度や特殊な処理のためにプログラムの開発が必要であればできるしするのは、Unixよりは(Windowsでもするしな)、いかにもハッカーらしいという感じ? "既存プログラム"を組み合わせるのはUnixらしいが
新しいコマンドを作って組み合わせて使うユニケージはUnixらしくない
しかもそのコマンドが完全に特殊用途向けのコマンドであり
Unixでいうシェルスクリプトにはまったくもって応用できない
今、ユニケージ開発手法にギークが熱狂するワケ【USP研究所代表&オープンソースOSコミッター対談】
【PR】2020.09.25
https://type.jp/et/feature/14070/
はは、クソ開発手法だ。ギークのだーれも熱狂してねーよ
せめてマニアとかオタクとかいえ、ギークと言ったら海外用語だ
海外に進出してないユニケージが熱狂とか嘘作んじゃねーよ Power-Shell は unix らしさの極みか?
漏れはそうは思わんが Power-Shell は反Unixだろ
そもそもWindowsにはまともなコマンドがないから
コマンドの連携ということがしづらい
あっても、正常終了時に「処理が完了しました」とかでて連携ができない
あれはコマンドを連携させずに、ただ並べるだけ
そういう世界だからシェルだけ改良しても意味がない
Unixでいうコマンド相当のものが必要
それが.NET framework。しかし.NET frameworkはAPI
APIだから普段CLIから実行するものではないし
コマンドとして使うのは面倒
Power-Shellはシェルスクリプトとしての特徴と
メリットである簡潔さが失われた「普通の言語」に相当する >>665
PowerShellを使ったことがないだろ?w
ヘンにハイフンを入れたりしてるしな。
コマンドによってはちゃんとオブジェクトを返すし、パイプで処理することもできる。
.NETを直接実行することもできるし、テキストベースでしかないUnixシェルよりも使いやすいこともある。
「反Unix」というよりは、それを越えたところもあるWindowsらしいシェルと言える。
ただ、いつまでどのようにサポートされるのか、最近はちょっと不安。。。
poshとのかねあいとか。 フィルターは、Ruby で作る
Linux のPowerShell は、Azure しか使われていないだろ? >>666
> ヘンにハイフンを入れたりしてるしな。
俺に言うな。俺はコピペしただけだ スペースがあると誤解しているのと、スペースをハイフンに置き換える習慣があるジジイの命名 >>668
で、使ったことはないんやろ?w
であればわざわざPowerShellについて述べずともよい。 >>670
PowerShellで作ったプログラムをオプソで公開してるがなにか? >>671
であれば、>>665みたいな理解にはならんがなあ。w
ま、オプソにもいろいろあるからな。 これだけマルチコアになった今日び、コマンドの方も対応して欲しい気がする。
ファイル圧縮のコマンドとか、マルチスレッドで処理したら速くできるはず。
あるいはどこまでもマルチプロセス主義でいくというなら... 例えば並列パイプ? というか
今のパイプだとデータフローが一本道だがこれを並列に分散して走らせて最後データを
一本にまとめるような処理の仕組みがあってもいいのではないかと。
ちなみに一本道は「いっぽんみち」で「いっぽんどう」ではないからな、って聞いてないか あまりわかってなさそだな>>675は
並列パイプとかも簡単に言ってそう 最期に一本にまとめるというのならGNU parallelやろ?
バックグラウンドプロセスを使って自分でまとめてもいいが パイプって元々非同期処理(これはPOSIXで規定)だから,
実装によっては普通にマルチスレッドで処理してんじゃないの? そもそもUnixにはforkというコマンドがあってだな 多くの言語が並列処理を行うように明示的に書かなければ並列処理されないのに比べて
シェルスクリプトは普通に書いてもかってに並列処理が行われる言語の1つ >>683
そうそう。
だから >>675 の主張がよくわからんのよね。
もしかしてパイプが非同期処理ってことを
知らなかったのかもしれない。 >>683,684
お前らもプロセスとスレッドの違いがわかってないようだがな >>685
わかってるが、何を根拠にいちゃもんつけたの?w お前はどっちなの?
まだ ID:NAroBJuS ならそうわかってはないようでもあるが、ID:zcWN9+mU は明らかにわかってないなw 質問を質問で返すな
まずお前が根拠をいえ
言わないで質問する理由なんかないだろ まあ、>>680の「マルチスレッド」はおかしいな。
言うなら「マルチタスク」とかやろ。 前者だが?はい、言いましたーw
次はお前の番だが、ここまでやっておいて
お前は答えられないってことはないよな そりゃすまんかったな。>>687と書いてるのに、なおおきに召さずに>>688なんて返すとは思わなかったわ
他の言語はあくまでも一つのプロセス内で行うことを記述するのが目的。プロセス内でのルーチンを呼ぶとか
シェルスクリプトは、最初からプロセスを起動する記述するのが目的。(マルチタスクだから複数同時起動して、パイプで繋げて「同期」って簡単に実現できるだけ)
明らかに全然違うし、「多くの言語が並列処理を行うように明示的に書かなければ並列処理されない」なんてわざわざ書くのはあんまわかってなさそうだなってとこ >>692
誰が同じことを繰り返し言えって言った?
> 「多くの言語が並列処理を行うように明示的に書かなければ並列処理されない」なんてわざわざ書くのはあんまわかってなさそうだなってとこ
の理由を書けといったんだが? 書いたというのなら、引用できるはずだなw
新しい言葉を追加せずに、理由を引用してみろ 読む気なさそうだからなあw
すでに書いた後は知らない 「こいつ分かってない」って言葉ってほんとうに便利よね。
それだけで
・自分が分かっている人間≠セと暗示できる
(でもあくまで暗示だから言質を取られる恐れもないw)
・相手より上の立場に立つ(という錯覚が)できる
わけだからさ。 ていうかシェルスクリプトで簡単にできるのは「マルチタスク」であって,
マルチタスクというのは非同期的な処理だから「非同期処理が簡単にできる」
という言説は正しいと言えるのかも知れないが(それでも違和感がある),
普通「マルチスレッド」といったときの同一プロセス内での複数スレッド処理に関しては
そもそもCPUの機能を全部抽象化されてるようなシェルスクリプトでは
外部コマンドを使ったりしないと実現できんのでは。
もしかしたら俺が知らんだけで
POSIXかどっかで「この動作はマルチ*スレッド*で処理されますよ」
というのが規定されている可能性もあるが,
ちょっと考えにくい。 シェルの内部コマンドでマルチスレッド化したほうが効率的なら勝手にやりゃいいんじゃねーの?
具体的にどのコマンドを対応させたいの?
もう誰か作ってんじゃないの? >同一プロセス内での複数スレッド処理に関しては
>そもそもCPUの機能を全部抽象化されてるようなシェルスクリプトでは
>外部コマンドを使ったりしないと実現できんのでは
何を言いたいのかイミフ
複数のスレッドで作業を分割して同時並行で実行するが、終了は順番に受け取るとかめんどくさいだとかで普通にできるだろう。単にやる必要もないってとこだな
>POSIXかどっかで「この動作はマルチ*スレッド*で処理されますよ」
>というのが規定されている可能性もあるが,
>ちょっと考えにくい。
なんか純粋なUnix系のOSを理解してないっぽい。純粋部分はマルチスレッドはOSで「勝手に」はやらんだろう。CUIレベルだと必要なさげだからな。GUIなOSでは勝手にはあるけど シェルスクリプトはHaskellと同じで自動的にマルチスレッド化するプログラミング
言語ですよ!
素晴らしいですよ!
ってこと? >>700
イミフな部分は シェルの内部コマンド をマルチスレッドでという話か
内部コマンドっても単にコマンドを内包してるだけで、外部コマンドと変わらない(いや、変わらないと困る)もんだろと思ってるから、そういう読みはできなかった。なるほどね
ksh,zsh でも確かマルチスレッドではなかったような
i=0
command | while read j; do
i=$((i+j))
done
って、i がちゃんと変わるようにしてるのに(確かネストしても大丈夫だったような)。実現方法はなんだっけ でも、自動的にマルチスレッド化してC言語の64倍高速化する可能性も、ワンチャンあるって事ですよね?
試してみるバリューあるのでは? ないよw
C言語でもOpenMP使えば割と見た目簡単にできそうだが、OpenMPもそれほど流行ってない
プロセス=特に何か意識する必要もない
スレッド=常時何かを意識する必要がある
そう簡単な話ではない
Haskellとかはマルチスレッドでなきゃそもそも実現できない言語なのだからそれと比べても意味はないな。Haskell出したのはそう意味あるわけではないだろけど >そもそも実現できない言語なのだから
というわけでもないのね
出し受けがどでかいばかりじゃないからそりゃそうか シェルスクリプトがマルチ高速化のアビリティを持つのは否定しようがないファクトですよね? >>708
マルチ高速化?
アビリティ?
ファクト?
個々の言葉はそれほどでもないが、にもかかわらず、全体から漂うバカっぽさ。w 並行・並列とプロセス・OSスレッド・軽量スレッドと同期・非同期の切り分けがごっちゃになってそう知らんけど 並行と並列はいまだにうまく使い分けられていない印象
正確な定義はどこかにあるんだろうが、人によって使われ方が違う コンカレントとパラレルの違いはアジア人にはわかり辛いですからね。
キリスト教的考え方が普及していないからですね。 並行と並列は使ってるCPUで決まる。
プログラムの書き方に違いはない。 $@みたいな擬配列変数に格納されている値 一つ一つに対して
何か処理を行なう時に,別の変数を用意しない(使わない)方法って原理的に可能かな。
普通は
for args in $@; do
なにか処理
done
というスクリプトを組むと思うんだけど,
argsみたいな変数を使わずに済む方法があれば知りたい。
(シェルスクリプトは基本的には変数の無駄遣いを避けなきゃいけないので。
まあそれが「欠陥」かどうかは別として) PowerShellってKshとかPerlとかUnixのシェルやスクリプト言語を研究してベースにして作ったって、昔QuoraかどこかでMSの社員が答えてた
begin/endブロックとか、昔からUnix使ってればそのまま活かせる知識かなりある >>717
$@を書き換えるのでないなら
while [ $# -gt 0 ]; do
なにか処理 "$1"
shift
done >>720
shiftを使うのか,頭になかったw
ありがとう! > (シェルスクリプトは基本的には変数の無駄遣いを避けなきゃいけないので。
これはなんで? 変数名がぶつかるとかいう話? ちなみにそれダブルクォートがあったほうがいい
for args in "$@"; do
なにか処理
done
もしくは逆に省略
for args; do
なにか処理
done ちなみにそれダブルクォートがあったほうがいい
for args in "$@"; do
もしくは逆に省略
for args; do >>723
そういうことです。
Bashとかの独自機能に頼れば
局所変数を使えるみたいだけど
それを踏まえても,
例えばC言語よりは「変数の使い過ぎ」には
注意しなくちゃならない(よね?)
>>725
for文ってin省略したら$@を暗示するのマジか!
知らんかったけどちゃんとPOSIXでも規定されてたわ。
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04_03 > for文ってin省略したら$@を暗示するのマジか!
他にはgetoptsもそうだな。こっちは逆によく省略されるから
逆に指定できたのか!になると思うが
今は解決してるかもしれないが、$@が0個の時、
set -u状態で"$@"を参照するとエラーになるシェルがあったから
for args in "$@" じゃなくて省略してfor argsと書くようになった >>719
実際、PerlとBashに慣れてると、かなり書きやすいからな。 昔Perlやってて関数の$1とかいちいち変数に入れるのダサいよなぁと思っていたけど
シェルスクリプトをPOSIX縛りしてたらローカル変数なくて、そのまま$1とかでいいやって思ってたら
どうせ関数は小さく書くのは当たり前だから別に$1とかで問題ないと思うようになったな
外部からどういう引数で渡ってくるのか分かりづらいものはコメント書いてるけど そうはならないよ。アセンブリは短く書こうとしてもどうしても長くなるから
「どうせ関数は小さく書くのは当たり前」が実現できない 名前の話なら、昔は名前が長いだけで容量が取られるから短くしていただけで、いまとなっては短いメリットはあまりない。 poshを「POSIXシェルスクリプトがちゃんと動くか」というのを
確かめるのに使ってる人いる?
シェルスクリプトの妥当性をshellcheckみたいに静的じゃなく動的に検証したい。 >>731-732
perl とか ruby で関数の戻り値が(敢えて描かれていないとき)
最後に評価されたレジスタ(アキュムレータ)の値が戻り値になる
ってのはアセンブラの尾骶骨だと思う POSIX準拠してるかを調べたいならdashを使ったほうが何倍もマシ >>736
ないない。
最後の式の評価結果を返しとくのがだいたい自然で合理的なだけ。 シェルスクリプトも最後のコマンドの評価結果をそのまま返す >>739
dashはDebian・Ubuntu系の/bin/shだよ
クラウドで一番よく使われてるディストリ いまどきのシェルスクリプトはほとんど/bin/bashでしょ シバンに使われるのは/bin/shだろ?
そしてそれがDebian・Ubuntuだとdashになる
なぜ今どきはbashだと思ったのか? 初めはそうだったんだけどな
ディストリによっては/bin/shが/bin/bashなのでそれと気づかずbash拡張を使う奴が出てきて、debianやbsd等の/bin/shが/bin/bashじゃない環境じゃ動かなくなってきて
「bash拡張使ったスクリプトはshebangもちゃんと/bin/bashにしよう」ってなってきた その結果bashが入ってないAlpine Linuxで動かないという問題が発生するわけで
さっさとPOSIX準拠に変更したほうがいい。bash依存は甘え。
っていうか俺勉強したくないんだーと言って必要もないのに/bin/bashにして
動かなくて後悔してるやつが増えてきてる。自業自得だが。 シェルスクリプトはPOSIX準拠にしておけ
bash特有の機能を使いたくなったら別の言語を使うべきだ そもそも>>2に書いてある
・デフォルトシェルのシバンはBourneシェル時代からの伝統で#!/bin/shを使用します。ただしその実体はOSによって様々です
Debian系 … dash CentOS系 … bash Alpine … ash(busybox) Android … mksh
FreeBSD … ash Solaris,OpenBSD … ksh
macOS … bash(Single UNIX Specification準拠のために一部動作が異なる)
・ログインシェルは/bin/shでない場合があります。例 macOS … zsh >>748
大きなお世話だな。w
BashがいいところはBashがいい。
どのUnixでも動かないといけないようなスクリプトは、シェル以外にも心配事は多いし、いちいち気にせずとも。 なんでbash使うんですか?bashじゃないとダメなことでもやってるんですか? 自分のためのスクリプトなので書きやすいように書くだけ 代替になり得てないだろう
いつものPOSIXなやつか >>756
Bashがふつうに使えるし、適度に高機能だから。
わざわざあえて別のシェルで動作確認するのは面倒であり無駄。 >>765
なんて言ってると、シェルがdashで
動かないーとか言ってるやつが多すぎるんだがw
bashを使うにしろ、必要最小限にしてればいいだろ
POSIX準拠の命令も、bashの命令なんだから だいたいbashスクリプトじゃなきゃダメなんだみたいに
言ってるやつのスクリプトはfunctionをなくして
[[ ]] を [ ] に置き換えるだけで8割はそのままPOSIX準拠にできるんだがw >>765
そもそも前提が違う
シバンに /bin/sh と書いてるならPOSIXで書くべきってだけだな
特定のシェルが好みでその機能を使って、シバンもそれにしてるなら好き好きにでしかないわな
なぜか、
>シバンに使われるのは/bin/shだろ?
とだけになり、シェルの派生は使うなそれなら他の言語をとか言い出すいつもの。自分がPOSIXに拘ってるのだけだろうがただうざいだけw /bin/shはどこでも入ってるが、
/bin/bashはAlpine Linuxなど入ってない環境がある 好き好きなんだから環境も好きにすんだよ、融通の利かない臨機応変出ないお前にはわからんだろうけど
問題があったら動かないし、シバンを変えるだけでもあるしな POSIX準拠で書いていれば
シバンを変えるだけで動くんだよね 反論しろや
POSIX準拠で書いていれば
シバンを変えるだけで動くのは事実だろうが イミフだからだぞ
>シバンを変えるだけ
ってなんのこっちゃ なんだこいつwww
770 名前:デフォルトの名無しさん[sage] 投稿日:2020/11/02(月) 19:51:03.74 ID:aDX4tDqS [4/6]
好き好きなんだから環境も好きにすんだよ、融通の利かない臨機応変出ないお前にはわからんだろうけど
問題があったら動かないし、シバンを変えるだけでもあるしな
↓
774 名前:デフォルトの名無しさん[sage] 投稿日:2020/11/02(月) 19:57:02.06 ID:aDX4tDqS [6/6]
イミフだからだぞ
>シバンを変えるだけ
ってなんのこっちゃ bashが無ければインストールする、パスが違っていればシバンを適切に書き換えるだけ
後者なんて、それこそシェルスクリプト(というほどでもない)でのお仕事で簡単なこと
好きで使ってるならそんなの気にしないぐらいの
>>775
なに言ってるの?w なおさらナンノコッチャ
まだ「シバンを変えなくても」だったらわかるが、ますますわからんw
まさか「シバンで /bin/bash とか書いていてもPOSIX準拠してたらどう変えても動く」とか言いたいわけ?まさかなあwww シバンを変えるだけといいながら、
bashをインストールしなければいけないと前言撤回w
誰もがbashをインストールできるわけではない いつものパターン
自分の何かがマズいと別の口実へとw シェルスクリプト使ってると精神が破壊されでもするのか echoの挙動すら統一できてないのに何がPOSIXだよ >>767
8割じゃねえか。w
個人的には、ほかに-o pipefailとかlocal -rとかも使うから、ほかのシェルは想定外。
いちいちほかを心配するのは無駄。2回目。 >>782
> -o pipefailとかlocal -rとかも使うから、
それを言ったのは1回目ですねw > 756 自分:デフォルトの名無しさん[sage] 投稿日:2020/11/02(月) 18:35:32.48 ID:pNDhR5km [7/17]
> なんでbash使うんですか?bashじゃないとダメなことでもやってるんですか?
注文ですね コマンドラインから実行したら自動的に色が有効になるのって
あれどういう仕組で実現してるんですか? isatty()が真なら、エスケープシーケンスで色設定する。 C言語の類推で考えれば,POSIXに従うというのも分かる話だと思うんだがなぁ。
「原理主義」とかはちょっとやりすぎ(Webサービスとかはさすがに……)と思うけど,
例えばMicrosoft製のclとかでしか動かないプログラムは別に悪い訳ではないけど,
C99やC11に従ってGCCでもpccでも動くようなプログラムの方がいいよね,
というそれだけの話。 エスケープシーケンスって仕組みダサいよな
パイプ通したときはどうとか面倒だし混乱するだけ そこで新たにエスケープの代わりにHTMLを流すことを提案しますとか
unicodeを拡張してすべての文字に色を付けられるようにします
とか言うの? >>791
かなり異なるものに「類推」とか言ってもダメ。
それに、C/C++だって、環境やターゲットが違えば、#if/#endifはあたりまえに使う。 >>793
そこで、PowerShellのオブジェクトパイプだ!!! https://qastack.jp/superuser/1259900/how-to-colorize-the-powershell-prompt
カラーエスケープシーケンス
さて、Windowsの10 をサポートANSIエスケープコードのconhostでは、と24ビットカラーは 1703年以降でサポートされています。
ANSIエスケープコードのいずれかを使用するには、リテラルESC文字が必要です。
これは、033進、またはbashで小数点以下27である、あなたは使います"\033"か"\e"。
PowerShellには直接同等のシーケンスはありませんが、代わりに式を埋め込むことができます。"$([char]27)" C言語にとってのPOSIXは、ほとんどすべてのことができるのに対して
シェルスクリプトにとってのPOSIXは必要最小限のことしかできない
ここ、大きな違いな >>796
そのクソ翻訳サイトを今すぐ
uBlacklistへ放り込め 最近使う機会のあったTinyCoreLinuxはashで >>2 のリストからしたらPOSIXみたいだけど
コマンドが無かったりして/proc依存しまくりで何の意味もなかったわありがとう! ・TinyCoreLinuxに入っているashはPOSIXシェル
・TinyCoreLinuxにPOSIXコマンドがない・/procに依存している
この二つは何の関係もないんですが……
皮肉を言うのはいいけど,ちゃんと勉強してからにしような! >>800
理想主義者にとっては関係がなくとも、現実に実装を行う開発者にとっては関係がある。
シェルだけがPOSIX準拠であっても意味がない。 >>801
開発者にとってはシェルがPOSIX準拠であれば
安心して使えるんだが?
POSIX準拠してませんってシェルを使う気になるか?
開発者死んだらどうしようって思うだろ? >>802
安心の根拠にできるのはPOSIXだけではない。
メジャーさとかアクティブさとかのほうが。 んなもん、あたりまえやw
そして、数少ない原理主義者以外にとってもな! POSIXよりもうちょっと実用的な標準作られないの? ここの住人って本気で
POSIXを越える規格を作って
それを世界が受け入れてくれる!
って思ってそうよねw いや、POSIXを発展させようと思ってるだけだが。
POSIXに影響を与えれば、POSIX自体が成長する。
POSIXを超えるのではなく、POSIX自体がPOSIXを超える。
だからそれはPOSIXのままだと言える POSIXを越えられるのは、POSIXだけだ!
熱いな 当たり前じゃん。アレだけおもちゃと馬鹿にされた
JavaScriptを超える言語はJavaScriptだけだった >>810
いや、そんな規格にはそれほど意味がない、と思うやろ。
目安程度にしかならんというか。
淘汰圧にはならんというか。
WebブラウザやC++コンパイラみたいに、非準拠なら非難轟々、とはなってないからな。 非準拠なら単に使われないってだけだな
WebブラウザやC++コンパイラが非難轟々なのは
準拠してますって宣言した上で、非準拠なことするからだよ
最初から準拠していませんって言っていれば
同じように使われないってだけ これ >>815
原理主義者が鬱陶しいのは同意するけど
だからといってPOSIXを無視していれば
損するのは自分よ。
たとえ「世界中の人間に使ってほしい」とか
そういう意図がなくても,POSIXに準じてたほうが
維持管理・保守の面だけでもどれだけの労力を減らせるか。 検証不能だけどな。
まあ、ひょっこり出てきたものがかっさらう可能性もあるからなんとも。 昔々、TinyCoreLinuxの日本語訳をバイナリでしか公開しなかったライセンス違反のおじさんがいたな POSIX に自信ある人おるっぽいから質問なんだけど!
date コマンドの POSIX 仕様書を見てみると、出力フォーマットに %F とか %z がないんだけど、これって使うとまずい?
%T は載ってるんだけどなぁ
strftime のほうには全部載ってるんだけど 「POSIXに準拠する」なら,マズい。
「俺はPOSIXなんか知らねえ! 俺の手元ではdateコマンドに%zを使えるから
使うんだ!」っていう考え方なら,全然使っても構わない。
ちなみに私は前者。 ちなみに%zみたいな数値型の時差なら,POSIXに準拠しつつ出力できる。
https://git.io/JkTnV 正直言うと z 使うと保守が面倒臭くなる
手離れ悪い >>821
なるほど、と思ったけど %z を得るための労力がでかすぎるな...
POSIXLY_CORRECT 知らなかった!勉強になる
POSIXLY_CORRECT=200809 date '%z' したら +900 が取れちゃったけど... (´・ω・`)
>>822
ISO 8601 が便利でなぁ、これに合わせたいんだよね >>823
POSIXLY_CORRECTはあくまで引数の処理規則とかにしか影響しない
…筈。
はっきりした典拠がある訳じゃないが。 >>825
なるほど... ありがとうございました! >>659
グルーランゲッジだな
パイプ間の1つ1つのプログラムは言語が別別でもよい 結局シェルスクリプトが一番適切だって思うから、みんなシェルスクリプトを使うわけで
そのあとシェルスクリプト使って後悔するなら、シェルスクリプト力(技術力)をつけたほうが良いってことだよ
他の言語に乗り換えるってのは、適切じゃない言語を使うってこと。単に慣れてるだけ。 >>831
論理があべこべだな
認知に相当の歪みがあると推察されるので、その事実を自覚するのは難しいだろうけど... 真面目に反論する気にもならないアホな論てあるんやで
自覚ないとおわかりになられんでしょうけど シェルスクリプトの欠点の一つとして
シェル変数を気軽に上書きできるという点がある
うっかりシステムに関係する変数を書き換えると
大騒ぎになるかも システムに関係するシェル変数ってなに?
他の言語じゃその変数を書き換えることは無理なの? うっかり=意図せずにだろ
他の言語では環境変数を書き換えるという明確な意思がなければ変わらないだろう え?システムに関係するシェル変数って環境変数のことだったの?
環境変数を書き換えても、他のプロセスには影響ないんだけど?
それでシステムに影響がある環境変数の名前はなに? 自分が読めないだけだろ
そしてそのしつこさは...w シェル変数といったり環境変数といったり
めちゃくちゃだよなw path=...
があるだけで、以降の処理はだいたい残念なことになってまう、みたいなシェルはあったような。
でも、しゃあない。
そういう事故は飲むしかない。
イヤでもあきらめろ。 シェルスクリプトが環境変数の書き換えに弱いというのはまだ分かるんだが,
それを「シェルスクリプト特有の」欠点みたいに呼ぶのはよく分からん。
・環境変数を「意図せず」書き換えてしまうこと
・環境変数を「悪意を持って」書き換えられること
こういう事態に弱いのは別にシェルスクリプトに限ったことじゃないでしょう。
具体例を出さなきゃ納得できない人もいそうなんで一つだけ挙げますね。
$LD_LIBRARY_PATH。 環境変数を意図せず書き換えてしまうとは、環境変数を触るつもりが全くないのにってことでしょ
シェルスクリプトに限らずって、他にそういうのなんかあったっけ 環境変数ってUnixやLinuxに限らず
Windowsにだってめちゃくちゃ使われてるぞ 環境変数PATH、有名なので間違えて書き換えたりしない
LD_LIBRARY_PATH、名前がかぶることはまずない
なぁ、実害あるん? シェルスクリプトは変数と環境変数のアクセスする違いがないってことだろうに
あくまでもローカル変数と使うつもりだったのにうっかりという
システムでの環境変数って言ってもそんな有名どころのではなくてもオレオレでというのはあるだろうに
視野が広いのか狭いのかなんなのか、ズレテルな プログラムのテストでシェルスクリプト使うだろ。
使わないのはテストしないからか >>849
変数には小文字を使いましょうってだけだなw
システムに関する環境変数なんてわずかしかないのに
その程度で苦労してんのか? >>851
「苦労」の話を誰かしたか?
シェルは、あやしいところがあるよなあ、と言い合ってるだけなのに。 >>845
> ・環境変数を「意図せず」書き換えてしまうこと
シェル以外にある?
思い当たるのはmakefileくらいか。
だいたいは、環境変数はかなり特別扱いされてるよなあ。 環境変数を「意図せず」書き換えてしまうことはあるが
その結果、問題が発生することはないって話だよ
だって環境変数を書き換えたとしても、最悪でも
自分とその子孫のプロセスにか影響がないから
システムを壊したりすることがない >>854
> システムを壊したりすることがない
誰がそんな話を? >>836でかいてあるだろ
> うっかりシステムに関係する変数を書き換えると
> 大騒ぎになるかも
システムに関する変数を書き換えても、自分のプロセスとそれ以下にしか
影響がないから大騒ぎになんかならん
それにシステムに関する変数といっても数えられる程度しかない >>856
大物の起動スクリプトとかでやらかすと、騒ぎにはなりうる。
init系とか.*rcとかcronとかでも。
初見ではわけがわからんかったりするしな。
まあ、個人的には、そういうものだと思ってるが。
おかげでラクなところもあるし、しゃあない。 WindowsだとADと連携させたりして、レジストリのアクセス制御が容易とか、そういう話? >>859
> 大物の起動スクリプトとかでやらかすと、
だから何をやらかすんだよw
環境変数PATHを書き換えてしまったんだ
って「だけ」の話をしてるんか?
何をやらかしたのかを言わずに、
ずっとやらかししまうって言ってるだけじゃんか ↑ こいつの知見の無さが半端ない。なのになぜか偉そう。頭悪そう わからないから質問してるのに
それにたいしてわからんのかと言われても
最初から、わからんと言ってるんだがとしか言えない
それで、何をやらかすんだ? 具体的なケースはわりとどうでもいいから。
パスでもプロキシでも、環境変数はちょくちょく影響がある。
それが想像つかんのなら、もうからまんでええんちゃう? 複数のシェルスクリプトをカスケードで読む場合
変数の管理がめんどくさくなるかな
sourceしたりして他のシェルスクリプトと非同期で
動かすとさらに複雑になる >>864
逃げるなよw
具体的なケースが重要
PATH変数とHTTP_PROXY変数だっていいたのだろうが "それだけ" だろう?
しかもシステム設定を変えるわけじゃない。
何度も言うが自分と子プロセスにしか影響がない。
意図せず変更してしまう可能性がどれだけあるのかと
あと環境変数じゃないなら小文字使えや >>865
また知ってる単語を使ってみましたみたいな文章だなw
カスケードで読むってなんだよ。誰がそんな用語使ってるんだ?
シェルスクリプトが別なら変数は共有されない
非同期で動かすというなら、それぞれ別のサブシェルになるから
これも変数は共有されない
sourceしたりというなら、グローバル変数のことだろうが
それなら、シェルスクリプトはグローバル変数しかないから
大規模に向かないって言えばいいだけのことだろ?
グローバル変数しかなくてもプリフィックス(を名前空間として考える)を
変数名につければいいだけだがな。それはPOSIXにこだわらないなら
localとかtypesetでローカル変数作れるし >>866
影響のでかたについては説明済み。
http_proxy系環境変数は一般的に小文字。
逃げてるというならそれでいい。
めんどくさいアホの相手はもうおしまい。 結局,「自分が思う(無根拠な)あやうさ」
を放言した結果,鉞が四方八方から飛んできて収集付かなくなった感じかね。
元の発言
> シェルスクリプトの欠点の一つとして
> シェル変数を気軽に上書きできるという点がある
> うっかりシステムに関係する変数を書き換えると
> 大騒ぎになるかも
からしてまあシェルスクリプト分かってんのかってツッコみたくなる点が幾つもあるし。
もう散々上で叩いたからこれ以上は責めるのを止すが。 それは双方同等。
「自分が思う(無根拠な)大丈夫さ」だから。
ま、一回事故らんと身に染みないことではある。 >>868
だから影響の出方は
"僅かな"有名な環境変数を書き換えると
自分と子プロセス"だけ"に影響があるって話でしょ?
ずーっとそういってる
大した影響がないと >>870
実際に事故ったときの
環境変数の名前は? 自分の体験談を言えばいいだけだと思うんだがねぇ
たまたま自分のアプリで LD_LIBRARY_PATHという変数を使っていたら
これと同じ環境変数を○○アプリが使っていて困りましたとかさぁ
実際の体験談ね。架空の体験談じゃなくてw PATHを書き換えて、コマンドサーチパスの優先順位変わって意図しないバージョンのコマンドを実行してしまって、コマンドの互換性に問題あって、大事なファイルを破壊してしまったとか
そういうのはあるんじゃない >>874
それはあると思うよ。
だからうっかりシステムに関係する変数を書き換えると大騒ぎになるかもというが
実際には注意が必要なのはPATH変数ぐらいの話だよねという結論に俺はしたいわけw >>869
>四方八方から飛んで
そのレスの前で飛ばしてるのは一人だと思うが >>870
どっちもどっち論に逃げずにさ,
一つだけでもいいから実例をあげてくれるだけでいいんだよ。 >>877
もうええから。
おのれが事故るまでわかるまい。 ここまで問いつめて一つも実例が出ない……。
あのね,自分の考えを矯正せざるえない正しい情報は耳障りかも知れないけど,
もう一度聞いてくれ。
「環境変数(⊂シェル変数)を外部から書き換えて,システムに損害を及ぼす」
ことは可能だけど,
シェル引数がプロセス間でどう引き継がれるかというのはPOSIXで定められていて,
要すれば「変数の書き換えの影響が及ぶのはその書き換え後にそのプロセスから
遂行したシェル(スクリプト)のみ」っていう決まりなのよ。
で,「変数を書き換えるとシステムに損害を及ぼす」ようなシェルスクリプトっていうのは
「システムを管理するシェルスクリプト」であって,
そんなシェルスクリプトを「遂行する前に」変数を書き換えられるような状態においては,
もはや「環境変数の書き換え」なんていう攻撃℃闥iを取らなくても,
簡単にシステムをぶっ壊せる。
逆に例えばマトモな許可設定がなされてるサーバーに対して,
クライアントが環境変数を書き換えてサーバーのシステムを壊すなんてことはできない。 はぁ〜〜無駄な熱量を使っちまった……
バカは放っておくのが一番なのは理解しているんだが,
初学者がもしもこのバカの発言を間に受けたら
勉強が進んで己の知識を修正するまで
間違った知識で行動する訳で,それは可哀そうなのでね。 シェルスクリプトはセキュリティホール
揺るぎない真実に向き合え >>879
攻撃の話はしてないよ
単に環境変数を書き換えることで他のプロセスに影響を与えることはできるけど
そもそもその環境変数なんてわずかしかないんだから
大騒ぎするまでのことはないよねって話してる
それに対して問題がー、問題がーってしつこく言ってるやつが居るから
お前実際にどんな問題が起きたことあるんだ?って聞いてるんだが
その答えは帰ってこないし、帰ってきてもそれだけだよね?程度の話だった
これがここまでの結論 日本語がぎこちないので ID:ZrW/GOpe は馬鹿確定 俺が実際どんな問題があった?って聞いてるんだから
俺の話を横取りするな セキュリティの問題ではないけど
PWDをシェルスクリプトの中で変数として使うと
システムに勝手に書き変えられて
思ったように動かないかもしれないな >>888
そうそう,こういう具体例でいいのよ。
ちなみにこの場合,変数$PWDじゃなくて
命令としてpwd(1)を使うとかすれば回避できる。 シェルスクリプト以外でPWDを使うことってあるんだろうか?
そもそもPWDはシェル変数ではあるが環境変数なのか?
他の言語でPWDがあることを前提としていいのだろうか?
またシェルスクリプトとかでは起動時に現在のカレントディレクトリに
設定されると思うので影響があるのは自分自身だけだろうな ん? 相対名でファイルをオープンするときとかどうなってると? >>892
PWDはただのカレントディレクトリを
変数に入れただけだよ
カレントディレクトリのことではない
cdしたときにシェル変数PWDとOLDPWDに
カレントディレクトリを入れるだけのこと
他の言語ではPWDやOLDPWDは参照しない
環境変数でしかないから ていうかシェルでもPWDを参照することは少ないでしょう。
「カレントディレクトリ」を指し示したかったらpwdを使うかな。
ちなみに,当然分かっているとは思うけど,
C言語やPythonでも$PWDは参照できる。
ただまぁ,それをやってるプログラムは,$PWDを参照している
シェルスクリプトと同じくらい数少ないと思うけどね。 なるほど。
カレントディレクトリを知りたいときにPWDを参照したら楽かもねってだけか。
それ以外には影響を及ぼさない。
勝手にPWDに依存するスクリプトやコマンドはあるかもしれんがw え?普通$PWDの方を使うでしょ
pwdにメリットなんてあるの?
デメリットならいくつか言える
外部コマンドなので遅い
ほどんどの場合、結局変数に入れて使う
変数に入れる時に標準出力経由でやるから更に遅い
変数展開が使えないから、/foo/bar/baz からbazだけを取るのが面倒で遅い
(まずありえないけど)改行で終わるディレクトリが正しく取れない(工夫すれば取れるけど)
唯一のメリットはPWDの内容と実際のカレントディレクトリが違う場合が
あることだけど、PWDはシェルスクリプト起動時に初期化されるので
意図的に変更しないとそうはならない。どうしてもPWDを
カレントディレクトリに初期化したいなら cd . でも実行すればいい
> C言語やPythonでも$PWDは参照できる。
それはPWDが環境変数としてエクスポートされてる場合でしょ?
unset PWDしてから起動しても参照できるって保証はあるの? pwdはカレントディレクトリを画面に表示するだけのときにしか使わないな
カレントディレクトリを利用する(変数に入れる)場合は$PWDを使う https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
> PWD
> Set by the shell and by the cd utility. (...) Assignments to this variable may be ignored. $ mkdir x
$ ln -s x y
$ cd y
$ pwd
/work/tmp/y
$ echo $PWD
/work/tmp/y
$ pwd -P
/work/tmp/x 書いておいてなんだけど、改行で終わるディレクトリなんて作ったことないからやってみたw
cd /tmp
mkdir "abc
"
こんな感じで普通に作れるね。移動して(移動するときも cd "abc
" ってやらないとだめw)
echo "[$PWD]" したらちゃんと改行が入ってる
pwdもコマンド打つだけなら改行が入ってるけど
dir=$(pwd) とかすると末尾の改行が消えてdir変数に入る
回避方法は dir=$(pwd; echo _); dir=${dir%_} とすること
末尾の改行が消えないように _ とかを追加しておいて、変数展開を使って消す >>898
> Assignments to this variable **may** be ignored
つまり無視されるかもしれないし、無視されないかもしれないってことね。
事実 PWD にカレントディレクトリと異なる値を入れることはほとんどのシェルで可能 >>899
何がいいたいのか知らんけど、
pwd -P の結果をPWDを使わずにほしいという話なら
cd -P を実行すればいいよ
dir=$(pwd -P) ・・・ 外部コマンド(遅い)+コマンド置換(遅い)
で二重に遅くなるけど
cd -P; dir=$PWD なら 内部コマンド(速い)+コマンド置換なし(速い)
カレントディレクトリが移動してしまうという副作用があるけど必要なら戻せばいい 訂正
pwd -P の結果をpwdを使わずにほしいという話なら
cd -P を実行すればいいよ bash$ type pwd
pwd is a shell builtin お、pwdはビルトインコマンドだったかw
じゃあそこは訂正
コマンド置換になるから遅い だけだな
これで数千倍ぐらい遅くなる $ dash
$ readonly PWD
$ cd x
dash: 3: cd: PWD: is read only
$ echo $PWD
$ /home/hoge
$ pwd
$ /home/hoge/x >>906
嫌だからそれがどうかしたんか?w
自分の結論を言わんと
ただ必死な姿にしか見えんぞ お遊びに付きあってあげているだけさ。気にするなよw >>905
>お、pwdはビルトインコマンドだったかw
一応/bin/pwdもあるね。
これの場合、子プロセスのディレクトリは親から引き継がれてるからおk,ということかな。 >>896
cd .してから$PWDを利用
←これやなシェルスクリプトの親プロセスで
readonly PWDされても問題ないし。 > readonly PWDされても問題ないし。
readonly するのは誰?
いや、自分でやっておいて
誰かにreadonly されたー!って叫ぶのかなと(笑) 改行コードってディレクトリ名とかファイル名の禁止文字じゃないのかω
勉強になったわωω findとかxargsとか
改行コードが禁止文字じゃないから
1行1ファイル名にできなくて
仕方なくNULL文字区切りができたんだよな
1行1ファイル名ならそんな機能いらなかったのに
NULL文字区切りって改行対策だけの機能だから >>912
「¥0」「/」以外の全バイトが有効なんだっけか。
Windowsは締めすぎだが、UNIXは緩すぎ。w >>913
find使うなら、xargsじゃなくて
-exec使った方がいいと思う。
ファイル区切りとか考える必要がない。 >>914
ちなmacOSではUTF-8として正当かチェックがあった気が....
あとFinder上でならスラッシュも使える。がコロンが使えない。
いえ、macOSはUNIXですw >>916
-execはファイル一個ごとですよね、と一瞬思ったけど、
それが気になる場合は {} + ですか。
しかし {} + って昔からあった?
ネットで見つけた4.3BSDのマニュアルには {} + の記述はないっぽい。
http://www.retro11.de/ouxr/43bsd/usr/man/cat1/find.0.html PWD を環境変数にするという発想は無かったな。
しちゃいかんとまでは思わないが意義があるとも思わない。 >>917
それは、ファイルシステムじゃなくて、シェルやろ。
UNIXというよりアポー互換のためだからしゃあない。w >>920
変数展開とか置換で使いやすいからやろ。
意義ならそれで充分。 >>922
変数展開とかするならシェル変数で十分じゃん
環境変数にする必要がない readコマンドと同じようなことを,変数を新たに生成することなく実現する方法ないかな。
当然,入力結果は変数に格納せずに,そのまま標準出力に返す。
(←べつにこの仕様じゃなきゃいけない訳じゃないけど,変数なしだとこれくらいしかないかな?)
例えば引数を付けないcatだと近い挙動を実現できるけど,
入力を終了する時に<Enter>じゃなくて<C-D>を入力しないといけないので,
利用者側の操作が違ってきちゃう。
↑このあたり,sttyとかで設定できないかな〜と思いつつも,
stty eof ^Jとかしても無理なんで詰まっている。 変数を新たに生成しないなら、決め打ちのグローバル変数を使ったら?
それも嫌ならPS1とかPS2を使うとかw
どうせシェルスクリプトの中では使わないだろうし お、思いついたw
read workとやってwork変数を使う
だけどそうすると上書きされちゃうから
set -- "$work"として$1にバックアップしておく
そいでecho "$work"してから$1を$workに戻す
ただしwork変数はread前に定義されてない可能性があるから
そこは変数が定義されてるかどうかで処理を分ける(めんどくさいから任せたw)
これで一時的には変数を使うけど使うけど最終的に副作用はない この方法を使えばreadの結果を$1とかに入れることもできそうw >>924
単にサブシェルにするのでは駄目?
( read a; echo "$a" ) みたいに >>926
sttyとか使ってなるべく代入を減らそうとしてたんだけど,
この方法でも「変数を節約する(使わない)」という目的は
普通に達成できるな。
ありがとう。 Macは昔は:がフォルダの区切り文字だったんだよな
ファイルのリソース情報が本体ファイルと別になってて2個1だった >>921
macOSのファイルシステムはユニコードで規定されているのでそういうチェックも
あるというか。
ま、ある意味文字列の中身を厳密に規定しないできた流れのFSと、
ユニコードの普及を推進していた(る)会社が作ったFSの違いかな? ちなみにWindows 10ではクソみたいな方法で,*一見すると*コロンや不等号を
ファイルに名付けられるような仕様になっている。
https://youtu.be/vE8jL9Fz9h0
誰得なのこの機能? >>932
誰得もなにも動画のとおりだろ
NTFSではPOSIX対応が必要だったため、本来はコロンとかを
ファイル名に入れられるんだがWindowsでは互換性のために禁止されてる
しかしWSLの登場でコロンや不等号のファイル名に対応する必要が出てきた
誰得ってのはこのWSLユーザーに決まってる
NTFSではこれらの文字を使おうと思えば使えるのだが、それだと相互運用で問題が出る
だからWSLでコロン等をファイル名に使ったら、Unicodeの特殊な文字に名前を変更して記録している
そしてこの仕様はもともとCygwinで考え出されたものだ
WindowsでLinux的に使おうとすれば、どうしてもそういう文字に対応する必要があるので
Cygwinで考え出された仕組みをWSLでそのまま取り入れてるだけ 普通にcygwinで:というファイル名を作ったら
Windowsからはどう見えるんだ?って調べればわかることだな
もう何年も前の話だよ
俺にとってはWSLでも同じでワロタ状態 あとwslpathコマンドも、昔からCygwinにcygpathというコマンドがあるのを知っていれば
同じような仕組みにしたのねって思うはず
MS独自の仕組みじゃなくて既存の仕組みを流用する当たり
今のMSがオープン的な考えになってることがよく分かる 全角と半角を同一視したらダメだろ
だから通常使われてない文字にわざわざしてるんだが wslpathがcygpathと同じ仕組みなのってなんで分かったん?
いや,つっかかる訳じゃなくて,
wslpathってソース公開されてないからさ。 a.txt
a x Nov 17 2020 aaa
b x Nov 18 2020 bbb
c z Nov 19 2020 ccc
cat a.txt | awk -v hy="-" '{if("$2"=="x"){"date -d "$3hy$4hy$5" ¥"+%Y-%M-%D¥" | getline var ; print $1","var","$6}}'
これ実行するとvarの内容がたまに前の行の値のままになったりするんだけど
|が悪いの?
結局 while IFS=' ' read 〜に変えたらやりたいことはできたけと何故上手くいかなかったのか分からなくて >>940
コロンとかのファイル名の話な(これはwslpathやcygpathとは関係ない)
cygwin「cygwin環境でHOME以下に作ったファイルはC:\cygwin64\home以下に作るで」
cygwin「 cygwin環境で : とか * という名前のファイル作れるで」
10年前の俺「え?なんで?エクスプローラーから見たら文字化けしとるやんけwww なんだこりゃ」
数分後 → 「ふーん」
WSL「/mnt/c/Users以下に作ったファイルはC:\Users以下に作るで」
WSL「WSL環境で : とか * という名前のファイル作れるで」
俺「エクスプローラーから見たら文字化けしとるやんけwww 既視感ぱねぇwww」
数分後 → 「同じじゃねーかwww」
wslpathは別にcygpath使ってればコマンド名とかオプションとか真似してるってわかるだろ?
WSL(Linux)にパスを変換するときのオプションが何故か-uな所とか
(cygwinでは-uの長いオプション名は--unix) まあもしかしたらcygwinよりも前にSFU(の前身)とかがやってたのかもしれんけどさ >>940
「仕組み」は、具体的な実装のことではなく、全体的なやりかたのことやろ。 > 俺「エクスプローラーから見たら文字化けしとるやんけwww 既視感ぱねぇwww」
> 数分後 → 「同じじゃねーかwww」
この同じじゃねーかwwwっていうのは : などのWindowsでは使えない文字のマッピング先の文字コードの話ね
そういや文字コードが同じであることは確かめたけど、実際にcygwinで作ったファイルをWSLで見たことなかったわ
んで、今やってみたけど、当然なんだけど、cygwinで作った : というファイルはWSLでちゃんと : になってたw
cygwin(たぶんmsysも同じ)との相互運用も考えてこうしたんだろうな >>941
>"date
" がいらない
>\"+%Y-%M-%D\"
2つの\ がいらない
これを実行しても、何も表示されないけど。
なんで? >>941
>\"+%Y-%M-%D\"
ひょっとして、この\ は、キーボードのバックスラッシュじゃないのかも?
ちゃんとキーボードで、入力してみれば? >>941
Ruby で、CSV なら、
require 'csv'
CSV.foreach( "a.csv", col_sep: " " ) do |row| # 1行ずつ処理する
p row[ 1 ]
end
出力
"x"
"x"
"z" >>946
>>947
すまんスマホで打ったので間違ってた
cat a.txt | awk -v hy="-" '{if($2=="x"){"date -d "$3hy$4hy$5" +%Y-%m-%d" | getline var ; print $1","var","$6}}'
+%Y-%m-%dは¥(バックスラッシュ)"で囲まなくてもOKだった
出力が3行以上あると>>941の現象になる気がする >>949
なら、下のように出力された
a,2020-11-17,aaa
b,2020-11-18,bbb >>950
出力される行数10行くらいに増やした場合は?(もちろん全て日付変えて) 正しく出力される。
実際には、c, d, f などは出力されていないけど
a,2020-11-17,aaa
b,2020-11-18,bbb
c
d
e,2020-11-21,eee
f
g,2020-11-23,ggg
h,2020-11-24,hhh
i
j,2020-11-26,jjj
k,2020-11-27,kkk
l,2020-11-28,lll
m
n
o,2020-12-01,ooo
p,2020-12-02,ppp
q,2020-12-03,qqq
r
s,2020-12-05,sss
t,2020-12-06,ttt
u フィールド数が想定がところがあるとエラーで getline が呼ばれなくて
var がそのままになったりするのかも? >>954
これかも
1列目にブランク入りのデータが入ってた AWKのgetlineってめっちゃ便利よね。
これ使い始めたらもうシェルスクリプトじゃなくてAWKスクリプトになるけどw >>956
いや違うわ
ブランク入ってたらそもそも$2がxにならない 元ネタの人じゃないけど以下のデータでおかしくなった。
a.txt
a x Nov 17 2020 aaa
b x Nov 18 2020 bbb
c x Nov 18 2020 ccc
d x Nov 19 2020 ddd
d x
e x Nov 19 2020 eee
f x Nov 20 2020 fff
d の行以降の日付が今日の日付になった。Ubuntu 16.04.7。
なんかデータをちょっといじると再現しなくなるような感もある。 >>960
d x
という変な行も、データに入れるのか?
Windows 10, WSL2, Ubuntu 18.04 では、下のように出力された
a,2020-11-17,aaa
b,2020-11-18,bbb
c,2020-11-18,ccc
d,2020-11-19,ddd
d,2020-11-19,
e,2020-11-19,eee
f,2020-11-20,fff >>961
そう。わざと壊れたデータで遊んでみているw
確実に再現できるバグは、ある意味治すのは易しい。
再現方法がよくわからんバグは...どうしたら再現するかを考えるのも一興かとw
あしまった、データが違ったかも。こうかな。
a x Nov 17 2020 aaa
b x Nov 18 2020 bbb
c x Nov 18 2020 ccc
d x Nov 20 2020 ddd
d x
e x Nov 20 2020 eee
f x Nov 20 2020 fff ちなみにdateコマンドは日付が空だと今日の日付を入れるようなので
Nov 20になる前に試すのがおすすめw このデータでやった。
b が今日の日付になる
a x Nov 03 2020 aaa
b x
c x Nov 05 2020 ccc
d x Nov 06 2020 ddd
出力
a,2020-11-03,aaa
b,2020-11-20,
c,2020-11-05,ccc
d,2020-11-06,ddd >>964
うん、それは単に >ちなみにdateコマンドは日付が空だと今日の日付を入れるようなので
だと思う。
自分の環境で >>962のデータを食わせたら
a,2020-11-17,aaa
b,2020-11-18,bbb
c,2020-11-18,ccc
d,2020-11-20,ddd
d,2020-11-19,
e,2020-11-19,eee
f,2020-11-19,fff
となった。e, f で空のdの所で得た日付を使われている感じ。ちょっとおもしろい。 ループ処理をバックグラウンドで流すと500個ぐらいプロセスができて
まったく動かない。いい方法ないかな。 >>966
500並列処理でもしてるんか?
そりゃ普通のCPUじゃ無理だろうよw
制限でもしろ 10万行のループ処理にかかる時間は、while は5秒、for は9分。
それらを、awk, perl に書き直せば、0.1秒
forの時間のほとんどは、プロセスの起動・終了処理。
そもそも、bash はループ処理に向いていないので、dash を使う。
それでも、シェルスクリプトはループ処理に向いていない
awk, perl, Ruby などは、1プロセス内で処理するから、
シェルスクリプトよりも断然速い 古いCorei7だけどbashで0.5秒で終わるぞ?
$ time -p bash -c 'i=0; while [ $i -lt 100000 ]; do i=$((i+1)); done'
real 0.53
user 0.51
sys 0.00
dashなら0.15秒だな
$ time -p dash -c 'i=0; while [ $i -lt 100000 ]; do i=$((i+1)); done'
real 0.15
user 0.14
sys 0.01 > forの時間のほとんどは、プロセスの起動・終了処理。
forでプロセス起動なんてしないけど? >>968
どう見てもそういうシェルスクリプトを書いたとしか見えんな
バックグランドプロセスを自分で管理するのがめんどくさいとかだったら、なんか上の方のレスであったな GNU Parallel か
>>966
GNU Parallel で簡単に解決できそ >>970
漏れは、6年前のパソコン工房の初心者向けノートPC、
Windows 10 Home, 64 bit, 20H2(2020 秋)
WSL2, Ubuntu 18.04
CPU は、i3-3120M。2 core, 4 thread のエコモード。
8GB メモリで、
bash
real 1.53
user 1.53
sys 0.00
dash
real 0.42
user 0.42
sys 0.00 >>970
$ time -p bash -c 'i=0; while [ $i -lt 100000 ]; do i=$((i+1)); done'
real 0.30
user 0.30
sys 0.00
$ time -p dash -c 'i=0; while [ $i -lt 100000 ]; do i=$((i+1)); done'
real 0.11
user 0.11
sys 0.00
OS: Gentoo via WSL2 on Windows 10 (build 20262.1010)
CPU: AMD Ryzen 7 3700X
RAM: 16 GiB, 2666 MHz 多分ね,遅いのはシェルのせいじゃない。
組み方がおかしい。 テキストファイルの中にカレントディレクトリを基準にしたファイルリストがあります。
このテキストファイルのファイルリストのファイルを~/backap/以下にディレクトリ構造を
維持したままコピーする方法を教えてください。
ファイルリストに含まれるパスは全てファイルです。ディレクトリで終わるパスは含まれません。
./file/jidori.jpg
./nikki/2020/11/01.txt
↑こんな感じのがたくさんあります $ rsync -a ―files-from=./file_list.txt . ~/backap $ cp -pr ./* ~/backup
ではいかんのか? このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 111日 17時間 39分 13秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。