シェルスクリプト総合 その29
■ このスレッドは過去ログ倉庫に格納されています
!extend:on:vvvvv:1000:512
!extend:on:vvvvv:1000:512
シェルスクリプトに関する総合スレッドです。
スレ立て時は以下の文を先頭行に加えて下さい。
後のつけ忘れ防止の為に複数行重ねて追加推奨
!extend:on:vvvvv:1000:512
全般
・荒しは無視しましょう。
・丁寧な姿勢を心掛けましょう。
・ネチケット(死語)を意識しましょう。
前スレ
シェルスクリプト総合 その28
http://mevius.5ch.net/test/read.cgi/tech/1532397676/
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured すごい低レベルな質問で申し訳ないんだけど、
win用のGit-bashで.shファイルダブルクリックしたときに
DOS窓出さないで実行するのってどうすればいい? >>297
それもはやシェルかどうか関係なくてWindows固有の問題だと思うが、エクスプローラでそのファイル右クリックしてプロパティ出したらそんな感じの設定できるようになってない?
最小化した状態で実行するとか、そんなやつ。 こうだ。
まずショートカット作り、そのショートカットのプロパティ出すと実行時の大きさを指定できる所があって、そこを最小化にすると実行時にタスクバーにアイコン出ているだけになる。 >>298
git-bash.exeだとできませんでしたが、bin/bash.exeでできました!
ありがとうございます。 ファイルや標準出力の行数がある数値より大きいことをできるだけ高速に確かめるにはどうすればいいだろう
最も単純で最もUNIXっぽいのは
$ test $(<file.txt wc -l) -gt $num
としてその真偽を見ることだけど
$ test $( (yes | head -n 3000000000000000000) | wc -l) -lt 300
こういうのを実行して貰えれば分かると思うがかなり時間が掛かる
俺の使ってる計算機はそこそこ良い性能(Intel Xeon x2/32GiB RAMなのだが)
それでも実行に1分強掛かった。
しかしこれは無駄だ。なぜなら結局比較する対象は300なのだから、「300行以上ある」ことが分かればいい。
なにか案ありませんかね。
思ったのはsed -n -e '300p'とかでその失敗判定を見るとかだが,これはsedコマンドの失敗の要因が他にもあるので
ちょっと不安定かなと。 cで指定行読むコマンドを作ればいい
面倒なこといちいち考える必要がそもそもない >>303
あーなるほど
$(<file.txt head -n $num | wc -l) -lt $num
とすればいいということですね。 >>305
そのことを意図していったんだけど、
2回走査することになるから
300行飛ばして1行読んだほうがいいか
たしかheadで1コマンドでできたでしょ? シェルスクリプトでループで回しながら数えるのと
headで300行とってきて、wcで300行数えるのってどっちが速いんだろうかね
やればすぐわかるけど、やる気起きないなぁw >>309
シェルスクリプトだとインタープリタの言語みたいな動きになるので遅そうなイメージはあるな。但しうまいこと内部で最適化されれば速くなるかもね。 >>310
いうてもループとカウントと条件分岐だけだからなぁ
内部的にはインタプリタ解釈後の状態になってるだろうし
そこでCPUは食わない気がする
でもheadでとってきてwcでカウントの部分は並列で実行できるわけで
マルチコアなら当然のことながら、シングルコアでもファイルから読み取りの方が
遅いからwcで待たされることはなさそう
どちらが速いかは微妙な所だなw ファイルの先頭からLFの数を数えるだけのことを
ああでもこうでもないと
いちいち考えないといけないオツムのデキを疑うわ。。。 ループってreadのループ?
catからパイプしてwhileのreadループってどうなんだっけ
昔作ったシェルでcatしてたファイルを処理中に書き換えたけど
実行されてる処理では書き換える前の内容で処理されてたみたいだから
どこかメモリに展開されてるんじゃ
catからのパイプでプロセスが終わってるからか?
でもリダイレクトやヒアドキュメントでも同じじゃないの? 低学歴知恵遅れの思考形態、世界では
すでに用意されているコマンドを組み合わせてシェルスクリプトを書くことが
シェルスクリプトを書くことになるという決まりがあるのが
このスレみてると分かる >>314
単にバッファに入っていただけとか。カーネルに設定できるバッファサイズなバッファなんぞもしくはcatプログラムのバッファ(の方が小さいだろう、たぶん)
もしくは上書きが上書きではなくて削除して新規ファイルに保存とかの場合とか(削除してもどこぞでオープンしていたらクローズされるまでは元のはそのまま残る)、か、OSが他でオープンされていたら上書きでも同じように別に保存してるとか >>313
考えてるのはファイルの先頭からLFの数を数える
「効率がいい方法(コマンド)は何か」だよ
LFの数を数えることなんてわかりきったことは考えてない
それを実現する方法を考えてる
まったくキミは思慮が足りないなw >>314
なんの話をしているのか知らんが、readで普通に一行ずつ処理できる。
catが終わるまで待つなんてことはない
なおcatは使わない(標準入力 or ファイルから直接読めばいい) >>312
awkプログラマ、シェルショッカーさんこんちには(笑) 何を噛み付いているのだか。よほど気に食わないことがあるらしいなっw このガキのやり取りもシェルスクリプトスレの日常になりつつあるな >>305
まあこれで今のところ上手くいってるのでいいです。 「シェルスクリプト」を省略するときなんて呼べばいいのかな。
“ss”だと他の用例が多すぎてややこしいし。
“shscp”とか? そもそもシェルでええのにわざわざシェルスクリプトって言いたがる新参者達w こんな感じに script1.sh が script2.sh を呼び出してる状態でさ、
script1.sh
└ script2.sh
CTRL+Cを押した時、script2.shは止めて、script1.shは
止めないってできるのかなぁ?
シグナルって、伝搬というか、上から下へ もしくは 下から上へ
流れていくものなん? ああ、いやトラップはかけてるんだよ
script1.sh でINTを無効にすると
script2.sh は止まらなくなる >>335,337
目的がどこまでどゆのなのかわからんけど、script2.shのシグナルハンドラでkill -SIGTERM $PPIDすればそんな動作にはなるな ああ、script2.shを止めるのか
そんなんだったらscript2.shのシグナルハンドラでexitすればいいんじゃないの??また変な縛りとか拘りとかは知らん script1.sh だけ動作を変えたいということなら
trap true INT
でいいように思うんだが… script2.shでそのへんの制御とかしたくなく、script1.shだけでならscript1.shで trap SIGINTすればいいだけっぽいな。無効じゃなくなにもしないシグナルハンドラで
script2.shの時だけでならその前後でNOPのシグナルハンドラ設定通常のシグナルハンドラに戻すとかか
>>341 被ったけど、書いたので被り被りで 勘違いしてた。違う所が原因だった
単純にscript2.shを起動してるのではなくて
script2.sh | filter みたいにパイプ使っていて、
CTRL+C押したときにscript2.shが出力するメッセージを
script1.shで受け取れないって問題だった どのタイミングでの出力が出ない、出したいのかわからんな。CTRL+C押した瞬間ギリのか??としか思えないが。filterがなんなのか知らんけど、script1.shでtrapでもscript2.shでの出力が全くでないことなないだろう、当然
script2.shでtrapしてexitすればギリ近くのまで出るんじゃないの。script2.shで実際に出力しているコマンド(プロセス)にもよるだろうけど ああ、trapの対象はパイプチェイン(?)の最後のヤツ&それがシェルでなければなのか?script2.shに飛ぶことはないのね。その最後のでexitすればだなすればかな
script2.sh | cat
script2.sh | sh -c "trap 'exit 0';cat"
のような変態なw それもシェル種類依存かな。あとはバッファをflushすればよりなんとかなりそうかなあ(できるのであれば)
そもそもCTRL+Cなんだからそんなギリを気にすんなってとこか >>344
最終的にやりたいことは
script1.sh ・・・ サブプロセスの標準出力・標準エラー出力を総てキャプチャしたい
script2.sh ・・・ 標準出力・標準エラー出力を行い、CTRL+Cを押されたら(trapして)
CTRL+Cが押されたと標準エラー出力に出力したい
ってことなんだよね
> そもそもCTRL+Cなんだからそんなギリを気にすんなってとこか
そういうことだし、諦めて一つのスクリプトにしてやりたいことは
解決できたのでもう深追いする気はなくなってる
あと関係ないけど、SIGINTってPOSIXじゃないみたいだなw
INTを使えってshellcheckに怒られた。みんな SIG SIG 言ってるのに なにその勝手にやる気なくすなよw ほんとに身勝手だな、いつも通り
SIGINTはPOSIXだからな(なぞ)。そっち寄りのの人は普通に使ってしまうんじゃね。てか、んなの本題に関係ないだろうに、そんなこと言いたいのはわかるけどさ(なぞ) >>348
> なにその勝手にやる気なくすなよw
$ dash -c 'trap true SIGINT && echo v^_^'
trap: SIGINT: bad trap
$ dash -c 'trap true INT && echo v^_^'
v^_^ で?通じてるんでしょ?POSIX縛りなんてあったの?そういうのはやる気あるのねw ああ、ちなみに、
>SIGINTはPOSIXだからな(なぞ)
は、(3)だよ。知らないんだろうけど(>>347の最後のあたりからも、その>>349あたりからも) >>350
やる気ではなくて、POSIX縛りは必須要件なので
サブプロセスの標準エラー出力の件は、別の方法で解決できることなので
数値でも指定できるのは知ってる。trap SIGINTとかSIGINT抜けてたとか
かいてあるから、trap INT、INT抜けてただよって言ってるだけ また、後出しか。そんなレスしている目的は違うだろうw
いきなり「数値でも指定できるのは知ってる」とか??(3)に対して???
http://pubs.opengroup.org/onlinepubs/007904975/utilities/trap.html
(新しいドキュメントはどこだ?)
SIG付きもPOSIX仕様のようだけどなwオプションでも言及しているんだからPOSIXの仕様のひとつだろう
なんて、アホなやりとりしたいの? >いきなり「数値でも指定できるのは知ってる」とか??(3)に対して???
ああ、(3)がSIGINTの数値だと思ったのか。違うぞ2だぞ。(3)は C API という意味 なるほどSIGをつけた名前はPOSIXだが、ポータビリティではないってことか
echoみたいなもんだな シェルスクリプトのスレでC APIは関係ないですよね?
言ってること間違ってますか? だから最初は「(なぞ)」にしてたやん
>>347の最後あたりの応えとしてしかない。お前が変なツッコミするから悪い
ちなみに、>>353のPOSIXドキュメントでも (3) のことに言及しているのはどう思う?UNIX/Linuxはそんな境目はそれほど無いと思うけど。誰かみたいに(1)しか興味ない知らない人もいるだろうけど
単に知らなかっただけでいいのに、いつも偉そうにしているからドツボにはまってるように見えなくもないw > ちなみに、>>353のPOSIXドキュメントでも (3) のことに言及しているのはどう思う?
それが、シェルスクリプトだけのドキュメントじゃなくて、POSIXのドキュメントだからでしょう???
なにがいいたいんだか コマンドのドキュメントだよ。それもお前が大好きなPOSIXのw
いろいろ破綻しているように見えなくもない。落ち着けww >>358
その C API って何ですか?定義を教えてください >>362
言い出した本人 (>>354) に聞いてください
> ああ、(3)がSIGINTの数値だと思ったのか。違うぞ2だぞ。(3)は C API という意味 >>361
(俺は最初から)trapの引数にSIGINTは使えないことがあるって
話をしていること、わかってますか?
どうも勘違いして、突っ走ってる気がするな >>363
で?その目的がわからんな。単に素直な疑問なだけなら、>>348で応えているけど。話を振ってねちっこく続けているのは誰なの?>>349とか以後とか
それも>>353でお前は納得したんだろ?
なんか上でC++のことを偉そうにのたまっているのを誤爆したのお前じゃなかったっけ?
それがお前じゃなくても、なんでコマンド関連のCなんて簡単なのにそんなに知らないのか不思議だな、なんか異常にシェルスクリプト「だけ」に拘るのもあって
UNIX/Linux界隈では自分でCでコマンド書く(簡単なフィルタも)のも普通にいるだろうから、お前のようにシェルスクリプトだけしか言ってはいけないなんてないと思うけどな(それも俺からは単にお前の間違いをごまかすためだけにしか見えんからw)
>>362は俺に振ってもいいが、なにを聞いているのか傍目にもわからないw すまんが、も少し具体的に>>362 >>365
コマンド?
もしかして、trapがコマンドだと思ってる?
シェルビルトイン関数だよ
シェルのプロセスでシグナルを扱わなきゃいけないから
外部コマンドで実装することは不可能
だからシェルスクリプトスレでtrapの話をするならば
シェルスクリプト前提になるのは当然だろう? >>368
そういう細かいことは言いたいのね。大枠でコマンドでいいじゃん (1) の範疇なんだから
その二行目以降はイミフ。なにを言っているの?言いたいの?
お前から見てミスを論ってなんとかお前のなにかを保ちたいだけにしか見えない >>369
そのレスはなんのためにしたの?
なにかを保ちたいだけにしか見えない 結局SIGINTの振りも>>368と同じでなにかをなんとかしたかっただけだろなww
SIGINTで失敗したから、別のにか。懲りないなw >>370
なんか失点を挽回しようとしているのが透けて見えてるのでwww >>372
それで、trapの引数のSIGINTの話をしていたところに
C APIを持ち出してきたのはなんでですか?
失態隠しのためにそんなレスしてるんですかねw ID:gJfQRhUl0 がさっきから俺に言ってることって
全部自分の事になってるのわかってないのかな?
どうせ次言う言葉も、自分のことを棚に上げて言うんだろうな >>373,374
はあ?無茶苦茶やな
その答えはすでに応えているけど。「みんな SIG SIG 言ってるのに」のに対する応えを含めての
それも最初に。それも話の流れで、お前も納得勉強wになっただろうにww
よほど「お前のなにかを保ちたい」が琴線だったようだねえw >>376
さすがにその選択肢はない
この赤い奴らをNGすれば済む話
それすら嫌ならお前が消えろ、ここに来た経緯忘れんな シグナルを送信するコマンドの名前がsigとかじゃなくkillなのはなぜでしょうか。
例によって歴史的経緯? 元々はSIGKILLシグナルしか送信しなかったのでkillとか。 >>379
某農家「村を出てアイドルになるなんてとんでもねぇ、両立するべ」 ご想像どおり、version6 unix以前はkillしかできなかった模様 村に戻って親が死んでたら
そいつは手遅れコロスしかない
親はいつまでも待っていない >>304
それを言えるのは、まだ手遅れになってないからなんやで お題:スクリプトのシグナルを扱う外部コマンドを設計せよ こんな感じ?w
#!/bin/sh
trap "$(extcmd)" INT
[extcmd]
#!/bin/sh
cat <<HERE
handler() {
: なにかする
}
handler
HERE >>389
おお、なるほど。長っ探しづらと一瞥では思ったが系統だってのでこっちのがいいか
どうもです いや手遅れ
親がしんでたらゾンビスプロセスになる
殺すしかない UTF-8で符号化された文字列に対応してるfmt(1)コマンドってある?
GNU coreutilsのfmt(1)は無理だった。 一回のループでファイルや変数を使わずに、偶数行と奇数行にまとめられないかなぁ?
例えば、入力ファイルが以下のような場合
1
2
3
4
5
出力は、以下のようにしたい
2 # ここから偶数行
4
1 # ここから奇数行
3
5
ファイルディスクリプタをうまく使えばできるんじゃないか?
と思ってたりするけどうまくいかない >>395
sedでできるならsedでもいいけど。
やっぱり無理だよなぁ
結局、奇数行のデータを後からだすためには
どこかにためておく必要があるわけで
メモリかディスクはどうしても使用してしまう
二回のループにするなら、メモリもディスクも消費しないけど
今度は入力データをためておく必要がある ■ このスレッドは過去ログ倉庫に格納されています