シェルスクリプト総合 その30
■ このスレッドは過去ログ倉庫に格納されています
シェルスクリプトに関する総合スレッドです。
全般
・荒しは無視しましょう。
・丁寧な姿勢を心掛けましょう。
・ネチケット(死語)を意識しましょう。
前スレ:
シェルスクリプト総合 その29
https://mevius.5ch.net/test/read.cgi/tech/1537540487/ Windowsに最初から入ってるのは vbs とか js とか、あとバッチファイルとかパワーシェルかな。よく知らんけど。
HTAってのもあったっけ。 powershell考えた奴は頭おかしいんじゃね
なんでいちいちコマンドとかあんな長いんだよ
無能にもほどがある adduserとuseraddどっちがどっちかたまに使うとき毎回調べるみたいなクソ下らないことしたくないからじゃない? それをいうなら、Windows、Macで、どの言語でも構わないが
ユーザーを追加する方法を調べないでわかるっていうの? POSIXってUNIX系OSの規格なのに
なんでWindowsの話になってんだよw >>188
>Javaなら一度書けばどこでも動くのに
とあったから
Windows は標準でいれてるのかなと javaのコンセプト
write ones, test everywhere Windows, WSL, Ubuntu16.04 では、Python, Perl は最初から入っている。
Ruby は、apt でインストールした
ls −l /usr/bin/python
/usr/bin/python −> python2.7
ls −l /usr/bin/python3
/usr/bin/python3 −> python3.5
ls −l /usr/bin/perl
/usr/bin/perl
ls −l /usr/bin/ruby
/usr/bin/ruby −> ruby2.3
注意。サーバーエラーになるので、全角に変換した そういえば IBM の z/OS ではどうなっているんだろうと
思ったら z/OS シェルってのがデフォルトでインストール
されてて、こいつは POSIX compliant らしい それだ WSL が標準で最初から入っているようになると
昔のニュースで見たが、どうなっているの?
標準は取りやめ? Windows の最新情報追ってないからわからない Windows10 を普通にアップデートしていれば、WSL は、最初から入っている。
ストアから、Ubuntu18.04 (長期サポート版)などをインストールして、日本語化すればよい
漏れはまだ、古いUbuntu16.04 の方を使っているけど >>184
あれは、普段使いのCUIではないからな
単なる開発用 個人的には、*nixとWindowsの違いは、
シェルと馴染んだコマンド群の有無、シェルスクリプトの実行可否だけなので、
それさえできれば、どちらでもいいや。
Cygwinはややストレス溜まったけど、WSLはだいぶ快適になった。 cmdのオプションが/なのは当て付けなんだろうか
XENIXを売ってた頃のMS知らんけど 階層がないファイルシステムだと - でも / でもどっちでも違和感が無いのだろう
単に好みでそれにしたってだけじゃないかな
階層があるようになって / を好みで選んで失敗したと思ったけどどうにもならななかったよう
手立ては用意したがサードパーティがそれを使わないとか ああ、どうにもならなかったのは、
オプションを/にしてしまったからとりあえずパス区切りはバックスラッシュにしたよ、でも、/ にもできるよ
だった。オプションを - に変えるのは今でも前のいつでもできるだろうな
コマンドによっては別の意味を持たせてとかありそうだが、なんの拘りなんだかよくわからんな 同じPCで一つがWSL1上のUbuntu、もう一つがDocker上のUbuntuで
lsb_release -aしてどちらも同じUbuntu 18.04.2 LTSなのに
kshのシェルに入ってから以下のコマンドを実行すると違いがある
echo $((99999999999999999))
=> 100000000000000000 # WSL
=> 99999999999999999 # Docker
KSV_VERSIONは両方とも同じ Version AJM 93u+ 2012-08-01
カーネル関係なさそうなのに、なんでだろう? ディレクトリごとの正確なファイル数が高速に知りたいです。 ls より find が早い
再帰ディレクトリ探索とファイル名出力はそれに任せて
その出力をパイプで変換していったらいいんじゃないか? なぜduでファイル数も調べられるようにしなかったのか? やるべきことは最小限の1つ
UNIXの哲学でしょ
小さいから早い
小さいからパイプでつなげていろいろ実現できる
小さいから保守できる その理屈だと、lsコマンドはファイルの名前だけじゃなくて
ファイルサイズまで表示している。
最小限になってない。findコマンドを見習え
って話になるんだがw >>209
ファイルを数えるのはduの仕事じゃないから ファイルを数えるのは誰の仕事?
仕事は一番うまくできる人がするべきですよ そういやファイル名に改行が含まれる場合、
POSIX準拠コマンド&オプションだけで数えられるの? やるべきことは最小限っていったら
duコマンドなんていらんよな
findでファイル検索して、lsでファイルの情報出して
awkで加算すれば良い
パイプでつなげていろいろ実現できる >>205
>>206
long doubleを使っているんだと思う。long doubleは昔のx87 fpuで計算されることになるが、これは精度を設定できて、確かデフォルトがlinuxでは80bit、windowsでは64bitになっていたと思う。 >>217
でもWSL版Ubuntuと通常のUbuntuでバイナリは同じはずでしょ?
FPUモードの設定とかあるってこと?
同じ命令でもモードによって精度が違うとか 元々、浮動小数点は誤差があるから、どっちでも良い
誤差無しなら、プログラミング言語で、Decimal などのライブラリを使わないといけない >>212
ls 凄いよね
呼びだした端末の表示限界まで調査して
整列してくれる
最小限だけではものたりないから Emacs とかできたんじゃない? >>207
$ find 〈対象ディレクトリ〉 -type f | wc -l bcコマンド使いなよ。POSIXで定められたほとんど唯一といっていい任意精度演算ができるコマンドだぜ。
残念ながらなぜかUbuntuには初期状態で入っていない……。 >>207
find ~/web -type f | perl -pe 's{[^/]+$}{\n}m'|uniq -c
27 /home/web/
11 /home/web/elona/
5 /home/web/elona/.git/
9 /home/web/elona/.git/hooks/
1 /home/web/elona/.git/info/
... やっぱりシェルスクリプトのパイプやばい
たった1行の短いのでそこそこ早いのが書きあがっちゃう >>220
emacsは出自がUnixじゃないから ちなみにPlan 9(Unixの後釜)のlsはもっと洗練された体系になってる。
あとPlan 9のEmacsの手引書がおもしろい Plan 9も最初からGPLで公開していればLinuxと肩を並べてたかもね >>218
FPU制御レジスタをFLDCW命令で変更すると計算精度や丸め方向が設定でき、同じ命令でも動作が変わる
プログラムが明示的に設定しなければ、当然OSが設定した値になる >>223
こういうの見るといつも思うんだけど、全部Perl(など)で全部完結して書くのとどっちがいいのかな?
殊に「高速で」条件があるなら。 >>230
パイプ有利でしょ
なぜなら perl は C の 10% 程の速度
シェルスクリプトの基本ツールは C で書かれているから早い
そしてパイプは並列プログラミングだ 並列「プログラミング」ではないな
単に仕組みとしてプロセスが同時並行しているだけで >>230
どうでもいいけど
>>223は基本的なコマンドで完結してるシェルスクリプトなので
Perlで「全部完結する」というのは対比する表現としてはちょっとおかしく思えるな 単機能のコマンドを組み合わせて処理するのがシェルスクリプトだからな
それで速度が遅いだの言うならシェルスクリプトなんか使わなければいい >>223
uniq -cの前にsortしなくていいの? >>235
別のところで動かしたらだめだったよ
sort 必要 ソートはたぶん早くないから
つまりコストが高いから
たぶん定番のあれやったほうがいい
1行ずつ読みこんだそれでハッシュ作って インクリメントしてくあれ 実はPOSIX sortならsort -uでuniq | sortと同等ことができるのでuniqは実質要らない子 uniqは重複したのを抽出する目的での利用が多いな
純粋にuniqで使う機会の方が極端に少ない uniq | sortって使い方分かってない奴かよw
uniqくらいソース読んでみなよ >>240
そんな揚げ足取らんでも。。。
sort | uniqの間違いです。 ls .-lのrwxに8進数表記も追加できないかな あ、setuid/setgid/sticky bit のこと忘れてたわ find ~TEST -type f -printf "%h\n" |sort |uniq -c
これは早いわ duのファイル版は俺も作ったけど未熟なんでこんな出来に
find ./ -type d -printf "%p " -exec bash -c 'ls -b "{}" | wc -l' \; | sed -r 's/(.* )(\w+)/\2\t\1/g' >>207
Ruby の、1-liner で、特定のディレクトリ以下を再帰的にたどりながら(find)、
ディレクトリ以外(reject)を表示する。
%Q("〜") は、" を、Windows のPowerShell に解釈させないために、クォートする
-r で、pathname モジュールを読み込む
ただし、途中で改行しているけど、実際には改行しないで下さい!
ruby -rpathname -e 'Pathname( %Q("C:/Users/Owner/Documents/Ruby/test") ).find
{ |path| if File.directory?( path ) then; puts path, path.children.reject( &:directory? ).length end; }'
出力
C:/Users/Owner/Documents/Ruby/test
11
C:/Users/Owner/Documents/Ruby/test/a
4
C:/Users/Owner/Documents/Ruby/test/a/b
0 stat -c '%A %U %G %z %n' .*
↑こういうのどう? lsのパーミッション表示を8進数に
まあPOSIXに規定されてないけど >>245
sort を差し替えた
~/ 対象にしたら倍速
find ~/ -type f -printf "%h\n" | perl -ne '$dirs{$_} += 1; END{for $key (keys %dirs) {printf "%5s %s", $dirs{$key}, $key } }' 途中だった
最後に | sort -k 2,2 入れても入れなくてもあまり変わらない
やはり指数関数的にsort に大量渡すと遅くなる POSIX の find って -printf がないのな。
難しいことは -exec でなんとかしろということか。 >>252
perl の中で sort やれば良いのでは?
sort keys %dirs にして。 Perlようわからんけど、findのところもまとめていわゆるVisitorパターンでやると?
シェルだと時間掛かる。
#!/bin/bash
shopt -s dotglob
walk() {
local c=0
for p in "$1"/*; do
if [ -d "$p" ]; then
walk "$p" # recursive call
elif [ -f "$p" ]; then
((c++))
fi
done
echo "$1: $c"
}
start_dir=$(basename "$1")
walk "$start_dir" どうせPerl使うんならPerlに用意されているfindコマンド的な関数使えばいいのに。
いや正直Perl書けないので外部コマンドのほうが効率いいのかも知れんけど 今回たまたま perl が早かったのは
>237
ということ
つまり C は10倍ぐらい早いけど
何十倍も無駄なことやってたら遅くなってしまう
高速な find の出力を |sort |uniq -c したら一応答えでるけど
そのsort がウルトラ処理多い
だったらperl で1行ずつ読んで正しいアルゴリズムで処理したほうが早いだけ awk版。ディレクトリ名でソートするなら sort -k2
find . -type f -exec dirname {} + | awk '{c[$0]++}END{for(i in c){printf"%4d %s\n",c[i],i}}' | sort xargs使ったほうが良いかな
find . -type f | xargs dirname | awk '{c[$0]++}END{for(i in c){printf"%4d %s\n",c[i],i}}' | sort やってることが同じなら、Perlとawkは比較するまでもないのでは? 数分で書けるのがシェルスクリプトの良いところなんだし
数百万のファイルを何分以内で処理せよとか性能要件があるなら
そもそもシェルスクリプトなんかで書かないわ なんかシェルスクリプトを貶す人間ってシェルスクリプトを本来の目的とは違う方法で使った結果失敗して
その恨みを自分の無能さではなくシェルスクリプトにぶつけてる印象。 このパーツは意外と頻度多いからCで書いておいてもいいかもね
| perl -ne '$dirs{$_} += 1; END{for $key (sort keys %dirs) {printf "%5s %s", $dirs{$key}, $key } }' 端末の応答(例えば$ printf '\e]11;?\e\\'で返ってくる\e]11;rgb:〈赤〉/〈緑〉/〈青〉\e\\っていう文字列)を
sedやらなにやらで加工できるように標準出力に流したいんだど
そのままの状態だと端末そのものに文字列が渡ってしまって加工できない。
$ printf '\e]11;?\e\\' | od
みたいにすると(当然だけど)\e]11;?\e\\という文字列がパイプを通ってしまう。
個人的にはsttyとかをうまくやりくりしたらいけそうな気もするのだけど
そういう文書や記事がないのと俺があまり端末の処理に詳しくないのとで今のところ成功していない。
端末応答を標準出力として処理できる方法知らないですかね。 >>272
色というものが何者かわかってないんじゃね?
色を付けるためのエスケープシーケンスっていうのは、
エスケープ文字、ASCIIコード表でESC(0x1B)の文字8進数だと033
ESC文字から始まる一連の文字列の流れ(シーケンス)ってだけだよ
だから0x1Bで始まるその文字列を加工すりゃ良い。
\e]11;の ]11;は単なる文字だけど、\eは(シェルによりけりだが)
0x1Bの文字に置き換わる。だからsedなんかで\eを見つけようとしてもだめ
そんな文字列は流れてこないんだから >>273
あー。いやそうじゃなくて 端末の応答を取得したいんよ。
試しに
$ printf '\e]11;?\e\\'
ってやってみて。多分端末の上に
^[]11;rgb:0c0c/0c0c/0c0c^[\
みたいな文字列が表われる。
この文字列をtestコマンドの対象にしたりしたい。
でも普通の方法ではこの文字列は標準出力ではなく端末の上に直接出力されてるから
そういう加工ができない。 >>274
話の内容を単純化しよう。
文字の内容は今どうでもいい話だろ?
printf 'hogehoge' ってやってみたら
端末の上に、hogehoge って表示されるな?
それでこの文字列をどうしたいって? わかってない奴が話に絡んでいくなよ
文字列なんか関係ない
奴はttyの出力(もしくは入力)を横取りしてパスワードを盗みたいという話をしてる $ printf '\e]11;?\e\\' の話だろ? >>278
試しに
$ printf '\e]11;?\e\\'
ってやってみて。 >>276
パスワードだとしたら、出力には返ってこないから横取りもできないんじゃね
パスワード生で出力するようなアレでなければ >>280
だから入力って書いたじゃん
エコーバックやめるタイミングを捕まえて入力側をだな
まあいいや、俺も答え知らないしw ■ このスレッドは過去ログ倉庫に格納されています