シェルスクリプト総合 その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 >>478 WSLは対応したのに? WSL その41 - Windowsのコンソールが24bitカラーをサポート・Bashからカラフルな出力が可能に https://kledgeb.blogspot.com/2016/09/wsl-41-windows24bitbash.html >>480 ま,まぁ? 24bitカラーなんて端末エミュレータの本来の機能じゃないし? (震え声) >>480 じゃあそこからsshでログインすればいいじゃん。 これにて一件落着。 >>482 俺に言うなってw 24bitカラーも普通に使っていいだろうって 最初から言ってるだろ そして寒い寒いマシン室に押し込められる可哀想な おじさん達のことは誰も考えてくれないんだよな。 ... | sort -k 2.2 や ... | uniq -c のような、パイプ挟んでもオプション使えるシェルスクリプトが書けません これはどうやればいいのでしょうか? ... | perl -0777 -ne 'print grep(m{ココ1}i, split("(?=ココ2)", $_));' 例えばこのような文脈で動作させていたものを パイプ移行をシェルスクリプトに書いておき 変数ココ1 ココ2 に渡して処理したいのです | split_grep.sh ココ1 ココ2 このように動作させたいのですが $1 $2 ... などを見ても 参照できてなくて困っています --helpオプションで出力される手引きの装飾についてだが less(1)ユーティリティは太字とにしてるね。 シェルスクリプトは20年動くとか言ってるやつがいるけど、 あれ嘘だなぁ。 各シェルの実装は互換性がない部分があるし、 同じシェルでもバージョンが変わると微妙に動きが変わる POSIXという仕様があってもそれを完全に実装しているとは 限らないしバグもある。 20年前のJavaScriptと同じようなレベルだ。 そのJavaScriptも20年前のものが今でも動いているからねw 今のJavaScriptは本当にどれもで同じように動くようになったけど20年前は大変だった。 どのシェルでも同じように動くシェルスクリプトを書くのは今でも大変だよ 一度互換性テストでもやって準拠度100%を達成を競わせたほうが良いだろう 「POSIXという一つの規格」がなぜそんなに強力だと思うのか分からない。 Pythonの公式文書やECMAが規格するJavaScriptと同等の立場でしょう。 もちろん,俺がシェルスクリプトを書くときは,俺がPythonやJavaScriptを書くときと同じく POSIXという共通規格に従うようにしているが,それは今後20年動かす為じゃない。 cronから実行しているシェル(スクリプト)があるんだけど 2重実行されると問題があるので そのシェルをくるむ親シェルを作って そこで事前にpkillで実行されているシェルおよびコマンドを無条件にkillしてる でも最近もともと実行してるシェルを複数回ループで実行したい要件が出てきた 単純に親シェルでループさせることを考えたけど pkillしてもループで再実行されてkill出来ずに2重実行される問題が出てくる シェルを親子孫の3階層にして新しく間に挟む子シェルでループさせ 親シェルのpkillではこの子と孫とコマンドをkillするといいと思うんだけど 階層が深くなって嫌だなと思うんだけど何かいい案ない? ちなみに孫シェルでループってのも考えたけど cron以外ではループさせたくない場合が多いので そこには手を加えずシンプルなままとしたいため考慮から外しました pkillとか野蛮な方法じゃなくて、ちゃんとロックして、ロック取れなければ死ねばいいのでは? どこまでの子プロセスとか残る可能性がとか条件が全然わからんが、シェルスクリプトを2重実行しないようにだけなら、その冒頭で、 [ -f /var/run/hogehogeshellscript.pid ] && kill -0 $(cat /var/run/hogehogeshellscript.pid) && exit 0 printf "%d" $$ > /var/run/hogehogeshellscript.pid 後始末で rm -f /var/run/hogehogeshellscript.pid が常套手段だな、俺は。「事前にpkillで実行されているシェルおよびコマンドを無条件にkillしてる」なんて、バグって残る場合しか考えられない(そんな動いているの殺していいの??) そもそも考え方自体が理解しがたい こんなクソなことやり出すやつとは仕事したくない >>497 cronで「しか」起動しないなら実用上問題ないかもしれんが、 まともなロックじゃないので2重起動されうる。 >>499 まさか、タイミング的な話? >>494 で十分なもんだし、そんなシェスクリプト書きませんよ。そんな超短時間で多重起動されうるもんなんて、シェルスクリプトなんて書かない バグの言い訳をシェルスクリプトのせいにするなよ シェルスクリプト以外でもやり方は一緒だろ それともシェルスクリプトでは不可能で 他の言語なら可能な方法があるとでも言うのか? > そんな超短時間で多重起動されうるもんなんて、シェルスクリプトなんて書かない シェルスクリプト以外でいいんで、どうやるのか答えてみて バグの言い訳?? そんなタイミングにシビアなのは普通にCなりで書くけど?なんか知らんがシェルスクリプトで処理スピードに必死なヤツもいるけど、そんなに時間にシビアなら普通にCでするだろう(一部でも) てか、デーモンだろな。別にシェルスクリプトでデーモン書いてもいいけど、小回りが利くのはやっぱCなりの方だな いや、だから、C言語でいいんで、多重起動しない方法書いてみてって、 どうせそれがシェルスクリプトでも使えるだろ 何に絡んでいるのかわからん 粒度が全然違うことなぞCで何か書いたことがあるのならわかるだろう。>>499 がその粒度の話だからな 絡んでいない。C言語で多重起動しない方法は シェルスクリプトでも使えると言ってる だからシェルスクリプトで書かない理由にはならない だから、粒度って言ってるじゃん。わからんのだな。話にならんな > 粒度って言ってるじゃん なんの説明にも反論にもなってない 粒度が違っても関係ない話だろ(他の人には「粒度」といい方で伝わってるはずw) うるせっw どうもシェルスクリプト大好き(後は私怨かなあとw)な絡みで、それ視点でしかなのでうやむやにしてんだけどね。言ったってたぶん聞かない人だから >>506 タイミング的な話なら、余計なことがない方が粒度が細かい=そっちにに決まっているだろう だがしかし、いくら粒度が細かくたってだから、デーモンでだろなだけどな > 余計なことがない方が粒度が細かい 粒度の使い方を待ちってるだけじゃないか で、デーモンにしないと多重起動は防げないって話をしてんのか? デーモンにすれば多重起動を防げる理由は? ほらな、突っ込まれるとこの程度、答えられないんだよw すまん 口を挟むけど 「 1. シェルスクリプトは各コマンドの起動時間やカーネルがファイルをどのように扱うということを 可搬な方法ではほとんど制御できない。 一方でCはそもそもOSがそれで書かれているように、上記の事柄を比較的簡単に実現できる。 2. ロックファイルを用いた多重起動防止アルゴリズムにはコマンドの制御時間やファイルの扱いを考える必要がある。 3. よってCと同じアルゴリズムをシェルスクリプトで記述しても それは運用に耐えるものでなくなってしまう。 だから無意味 」 ↑こういう理解でいいか? >>511 >粒度の使い方を待ちってる(間違ってる)だけじゃないか はあ? >デーモンにすれば多重起動を防げる理由は はあ?デーモンは一つ動けば十分だからな。ま・さ・か、デーモンにしても多重起動を防げないとか言い出してるわけ?だとしたらアホだな >>512 別に無意味とは言わないよ。俺は書かないというだけで。なんでシェルスクリプトでタイミング的な諸々をシェルスクリプトというある意味隠蔽された条件制約で悩まなくちゃならんねんってとこから。それならCでのほうがスッキリ小回りが利くしという 後は、超短時間で多重起動されうるもんなんてよりCで書くなという、そんな起動頻度のあるのは、スクリプトではしない >>512 > シェルスクリプトは各コマンドの起動時間やカーネルがファイルをどのように扱うということを > 可搬な方法ではほとんど制御できない。 それはプロセスの多重起動を防ぐ方法と関係ない > ロックファイルを用いた多重起動防止アルゴリズムにはコマンドの制御時間やファイルの扱いを考える必要がある。 コマンドの制御時間やファイルの扱いとかなんの話をしてるのか >>497 はアルゴリズムの間違いなのでロックファイルがどうとか関係ない (どうせC言語で作っても同じ間違いをするだろう) > よってCと同じアルゴリズムをシェルスクリプトで記述しても それは運用に耐えるものでなくなってしまう。 今はプロセスの多重起動の話でしか無いので、多重起動が出来ないならば運用に耐えられる それがシェルスクリプトできないわけがない。 >>513 > はあ?デーモンは一つ動けば十分だからな。ま・さ・か、デーモンにしても多重起動を防げないとか言い出してるわけ?だとしたらアホだな デーモンが一つ動けば十分だとかそういう話をしてるんじゃない。 プロセスの多重起動を防ぐにはどうするかの話で、、 それはデーモンにしないと出来ないことではないだろ >>514 > なんでシェルスクリプトでタイミング的な諸々をシェルスクリプトというある意味隠蔽された条件制約で悩まなくちゃならんねんってとこから。 だから、なんでシェルスクリプトにこだわってるのか? こっちはお前が、プロセスの多重起動を防ぐ正しい方法を知らないんだろうなって思ってるんだよ。 だからC言語でいいから書いてみろと。 同じアルゴリズムはシェルスクリプトでも使えるから、シェルスクリプトかどうかの話じゃないって言ってんの で、C言語でプロセスの多重起動を防ぐ正しい方法を書けないんだろう? 出てないってことそういうことだ。シェルスクリプトだからと嘘をつくな >>513 >>497 はアルゴリズムの間違いなのでロックファイルがどうとか関係ない ただのイチャモンか。またか?コマンドのようにw >>516 ただのイチャモンやん。また、無茶苦茶やな。なにを問題にしているのかイミフ。いちゃもんのためのいちゃもんやなあ >>518 何を問題にしているかもわかってないのか? >>517 も指摘しているが、>>497 は多重起動チェックのアルゴリズムに問題がある シェルスクリプトだからこれしか出来ないという話ではない あ、>>517 って俺の書き込みか わかるように書けよw >>519 うーむ、だから粒度の問題と言っているんだけど。なにがアルゴリズムに問題があるの?cronで起動する大きな粒度では問題ないと思うけど あるとしたら、起動終了間近とか??それは別の話だろうしな??? >>520 ああ、すまん。>>516 はあんたか。なんで絡んでるねんっ、何を問題にしてるねん?? >>522 ああ、いいのかww 何を絡んでるのかイミフすぎ。場合によってって考えられないのかな? そもそも>>499 で十分で(十分だろう)というのに対して、その条件以外のツッコミに対して、その漠然として条件なら突き詰めると&俺にとって普通にシェルスクリプトで書かないってことなんだけどなあ 何が気に食わない、何が間違いなのかさっぱりだな >>515 俺は「プロセスの多重起動を防ぐ」というのを 「プロセスを一つ立ち上がっていることを感知する」 という仕組みを作ることだと思っていて、その方法の一つに 「プロセスが起動するときに特定のファイルを生成し そして終了するときそのファイルを削除する (そして そのファイルの有無によって多重起動を判断する)」 というものがある という認識。 「特定のファイル」はロックファイルと呼ばれる。 で ロックファイルアルゴリズムの問題点は非常に素早く二つのプロセスを立ち上げた時に 最初に起動したプロセスがロックファイルを生成し終える前に 二番目のプロセスがロックファイルが存在しないのを理由に立ち上がってしまう (結果として二重起動する) ということだと思っている。 このときに関わってくるのはファイルIOとかその辺のカーネル領域に片足突っ込んだ話なので Cではできるがシェルスクリプトでは難しいということだと考えたんだけど 違いますかね。 flockコマンド使えって。シェル単体ではそこまでやってくれるやつは多分ないだろうし。 >>524 ロックファイル以外でも所詮OSで何らかの起動時のサポートが無ければCでも防げないと思うんだけど、どうだろう? なので、デーモンとして一つ起動して、それを活性化するのがなんだけどな >>515 >>>497 はアルゴリズムの間違いなのでロックファイルがどうとか関係ない どこが間違ってるの? 最初にロック取って最後に解放する、これを間違ってると言うなら 正解を教えてよ。多分逃げるんだろうけど。 flockがあればそれでいいけど、なくてもmkdirとかln -sで正しいロックが書けるよ ロックファイルの有無だけでやる場合は open() で O_EXCL 指定してファイル作ろうとしないと駄目で、シェルスクリプトからこれがやれるかどうかはシェル次第になる。 そういう外部コマンド作って呼び出せば確実だが、それがありなら fcntl() や flock() 等を使ったもう少し信頼性の高そうなロックをした方が良いように思う。 ロックファイルだけでロックする場合はもう一つ強制終了させられた時にファイルが消せずに残る問題がある。 これはファイルのタイムスタンプを見て古ければ動いていないとみなす方法である程度回避可能だが、その場合は動いているプロセスが定期的にファイルを touch する等して更新する必要がある。 しかしそれでも SIGSTOP により停止していただけだったら役に立たない。 なるほど、OS内でキッチリ一元管理しているナニカに頼ればいいのか&あるのか >>524 > で ロックファイルアルゴリズムの問題点は非常に素早く二つのプロセスを立ち上げた時に > 最初に起動したプロセスがロックファイルを生成し終える前に > 二番目のプロセスがロックファイルが存在しないのを理由に立ち上がってしまう > (結果として二重起動する) 正しくない 正しいロックファイルアルゴリズムであれば、素早く二つのプロセスを立ち上げても問題ない あんたが書いたそれはは典型的な間違ったロックファイルアルゴリズム(そして>>497 も同様) アルゴリズム自体の問題なのでシェルスクリプトかどうかは関係ない 直接的な解答ではなくて関連した話題になるが、多重起動防止以外でも重要だから読んどけ https://www.ibm.com/developerworks/jp/linux/library/l-sprace/index.html > 単純な解決方法は、open()をフラグO_WRONLY | O_CREAT | O_EXCLで使うことです https://www.ipa.go.jp/security/fy20/reports/tech1-tg/2_05.html > これを避けるためには先に述べたとおり、テンポラリファイルを生成するときに O_EXCL を指定すればよい。 もう少し引用する範囲を広げる > これを避けるためには先に述べたとおり、テンポラリファイルを生成するときに O_EXCL を指定すればよい。 > これを POSIX シェルで行うには、set -C を使う。set -C は noclobber オプションを有効にする。 > noclobber が有効な場合、> によるリダイレクトでの open には O_EXCL が指定される。 > これを使ってテンポラリファイルの生成に挑戦し、失敗したときは終了するには以下のようにする。 > また、ここでは TMPDIR が指定された場合には使うようにしている。 ほんと場合によってってって無いやつだな。原理主義者か? >>534 そうなんだ。知らなかった。 教えてくれてありがとうございます。 ロックの確認とロックかけるのをアトミックにやらないとか まともにロック処理やったことがない証拠だよ これは初心者は誰でもやる典型的な間違いだからな 基本を知らずに独自の思いつきで実装するからそうなる 言われれ初めて気づく。だが一回言われればこうやれば 解決できるのかと深く記憶する話だから、単純に知識が欠けてるということ だから他の言語でもどうせ同じなんだろということ。 ksh --helpは出力される手引きが装飾されてるね 最初っから主張の根拠を提示すれば良かったのに 何だかんだで下らないレスが続くの止めて欲しい echo "echo \"Hello, world\!\"" これ実行したら echo "Hello, world!" にならない echo "Hello, world\!" なぜか!だけ手前についてしまう >>542 それスクリプトにしてやってみ。 多分期待どおりの出力になる。 間違えてた。 「echo "echo \"Hello, world!\""」にして。 スクリプトの中ではPOSIX互換のインタラクティブシェルは 履歴展開をしないので上手くいく。 そういやkshで思い出したけど、 ksh88ってもしかして比較的最近(今も?)使われてたりする? ksh88っていうぐらいだから1988年だろ?ksh93っていうぐらいだから1993年だろ? 流石にksh88はなんて30年前の化石使われてないだろ?と思ったけど Solaris 11 でこんなこと書かれてたんだよね。意外と最近まで使われていたのかなぁ?と https://docs.oracle.com/cd/E26924_01/html/E25934/userenv-1.html > シェルの変更 - デフォルトのシェル /bin/sh が ksh93 にリンクされるようになりました。 > レガシー Bourne シェルは /usr/sunos/bin/sh として使用可能です。 > 旧バージョンの ksh88 は、shell/ksh88 パッケージの /usr/sunos/bin/ksh として使用可能になっています。 Solaris 11が最新版って言っても2011年11月9日リリースなので2日後に7年前のOSになるけど (でもサポートはSolaris 10が2021年までなのか・・・) そしてksh93の機能でこんな事書いてたんで、$(( )) が使えないシェルはksh88だったんだなって思ったところ https://www.ibm.com/support/knowledgecenter/ja/ssw_aix_72/com.ibm.aix.osdevice/korn_shell_enhanced.htm >>544 できたd (でも都合上コンソール開いてコピペで使いたかったんや) >>545 Solaris 10のがPOSIXに準拠してることになってるせいで "$@"じゃなくて${1+"$@"}と書かないといけなかったりして面倒だよねw >>546 「echo "echo \"Hello, world"'!'"\""」とかどうだろう。 参考: https://www.gnu.org/software/bash/manual/html_node/History-Interaction.html#History-Interaction History expansions are introduced by the appearance of the history expansion character, which is ‘!’ by default. Only ‘\’ and ‘'’ may be used to escape the history expansion character, but the history expansion character is also treated as quoted if it immediately precedes the closing double quote in a double-quoted string. >>547 ksh・・・お前が諸悪の根源だったか https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861743 > % posh -u -c 'echo "$@"' > posh: @: parameter not set poshはpdkshからフォークしている > posh (0.0.1) unstable; urgency=low > * Initial release. (copied from pdksh 5.2.14-6). closes: bug#150431. そしてシンプルな(笑)解決方法をありがとう (if書くのはもっと面倒だった) もっとバッドノウハウあったら教えてくれ! >>550 modernishでも言及されてた。時代遅れのワークアラウンドだってw でも現存するシェルに蘇っておるのじゃよ 昔の人には有名な回避策なのかな? https://github.com/modernish/modernish/blob/master/README.md > BUG_PARONEARG: When IFS is empty on bash 3.x and 4.x (i.e. field splitting is off), > ${1+"$@"} is counted as a single argument instead of each positional parameter as > separate arguments. To avoid this bug, simply use "$@" instead. (${1+"$@"} > is an obsolete workaround for a fatal shell bug, FTL_UPP.) modernishおもしろいね。 modernishプロジェクトはcase文の条件の先頭に開き丸括弧を付けてるのか。 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04_05 ここには確かに開き丸括弧を前置してもいいとあるけど一般的には省略されるでしょ。 なにかこれも旧時代のシェルの不具合への回避策なのかな。 それこそGNU Bash 3.xで動かない,とか。 >>552 やっとmodernishに興味を持ってくれた人がw まあ俺もバグ情報とか参考になるなって程度にしか見てないんだけど > modernishプロジェクトはcase文の条件の先頭に開き丸括弧を付けてるのか。 それ見た時、何この文法?modernishでそこまで拡張できるの?って驚いたw 単なる普通の文法だったわけだけど > それこそGNU Bash 3.xで動かない,とか。 少なくともbash 2.03では開き括弧なくて動くよ 話変わるけど、 foo | bar みたいなコマンドで fooからたくさん出力されるけど、barの処理が遅いってとき fooからの出力ってブロックされるのかな? なんか20〜30行ぐらいでブロックされるような 出力の停止、遅延が起きてる気がする メモリにバッファリングするだろうから、それが溢れないような処置として そういう仕様は理解できるけど、どこかに書いてあるのかな? シェルの仕様っぽい気がするけど、OSも絡んでいそうな気もする >>554 タネンバウム先生の本は読んでるんだよね? お、再現した i=0 while :; do i=$((i+1)) echo test$i echo log$i>&2 done | while read line; do echo $line sleep 3 done パイプの前で無限ループで標準出力と標準エラー出力に高速に出力してるとき パイプの後ろの遅い標準入力から入力の処理によって パイプの前の標準エラー出力への出力がブロックされてる 7400行(64KB程度?)ぐらいまでは、パイプの後ろの処理を待つことなく高速に 標準エラー出力に出力するが、それ移行は1行ずつ出力するようになった。 >>557 ¥ 15,449 円+350円 もするのかー 高いなー >>558 それ普通のマルチタスクOSでの動作なのでは? 昔々のMS-DOSとかのシングルタスクOSでは一回ファイルに書き出してから次のコマンドに読ませるので無限に出力するやつはだめだけどな。 いわゆる普通のプログラミング言語(PythonやCやJavaScript)に対して,シェルスクリプトを作る上で気をつけてることってある? 例えば「局所変数や局所関数が宣言できないのでなるべく使わない」とかさ。 >>560 並列で動作するのは当然だが、今話しをしてるのは、 一つのプロセスが、もう一つのプロセスの動作を止めるっていうところだよ >>561 逆ね。パイプは(パイプ先が)入力を受け取るまでブロックされる こっちはどばどばーっと出し続けようとしてるのに、相手が受け取ってくれないから 出せなくなるんだよ。って話 >>562 個人的な特殊な状況下で気をつけてることならたくさんあるんだけどな パイプを(なるべく)使わないとかwww そうさなぁ、例えば意図せぬエラーで落ちるように、set -eを使う場合は 挙動をよく理解して使うこととかかな set -eは戻り値がエラーになった時点で中断される set -e foo() { echo foo begin; bar; echo foo end; } bar() { echo bar begin; baz; echo bar end; } baz() { echo baz; false; } foo これを実行すると、foo -> bar -> baz の呼び出しの流れが、bazのfalseで中断されて foo begin bar begin baz と表示されるんだが foo の代わりに if foo; then :; fi と実行すると なんと、foo end も bar end も表示されるんだよ つまり foo を if や && や || と組み合わせて使うと、エラー中断機能が無効化される だから、比較関数みたいに if foo; then という使い方を想定している関数は 中でしっかりエラーチェックをしておくこと 他の言語の例外みたいに考えてはいけない ↑ これが理由で、set -eは使うな派もいるらしいねw >>562 > 例えば「局所変数や局所関数が宣言できないのでなるべく使わない」とかさ。 俺は訳あってそうしてるけど、特定のシェルに限って良いのなら localもしくはtypesetで局所変数使えるよ ただし、他の言語と違ってレキシカルスコープじゃなくて ダイナミックスコープなので注意が必要 これも気をつけていることかな あと他の言語でも同じだけどshellcheckは基本やね ダブルクォートでくくるとか、shellcheckで警告出るものは ここでグダグダ書かないよ。 >>563 パイプが詰まってんだから停止させるしか方法ないと思うが? バッファ大きくしても出力側が速いなら何れ突っ掛かる事になるよね。 >>568 そりゃそうだよねって話ではあるんだけどさ、 パイプで何かに繋いだがために処理が遅くなることもあるよなって思ってね 明らかにそんなレベルの回答求めてないよねっていう語りたがり ん? あぁ、質問はコレね > メモリにバッファリングするだろうから、それが溢れないような処置として > そういう仕様は理解できるけど、どこかに書いてあるのかな? > > シェルの仕様っぽい気がするけど、OSも絡んでいそうな気もする >>565 ありがとう。set -eは鬼門だね。前に棘かなにかでも纏められてた。 ところで パイプ使わないのはどうしてだ? シェルスクリプトは入出力指向なんだから積極的にパイプを活用すべきでは。 >>573 パイプ使わないのはシェルスクリプト内部で完結する場合の話ね 外部コマンドとのインターフェースでは使う (内部で)使わない理由は変数の共有がやりづらいから ま、これは特殊な事例なのでw ああ。たしかにパイプ越しに変数を参照させようと思ったらexportして環境変数にしなくちゃらんもんな。 > ああ。たしかにパイプ越しに変数を参照させようと思ったらexportして環境変数にしなくちゃらんもんな。 もうちょっと説明すると foo() { output | bar | baz } fooで見えてる変数を、bar, bazに見せるのは簡単なんだよ。 exportしなくても見せられる。 outputが出力する1行をbarが解析して変数に入れたとして、その変数を bazで見ることはできない(barでexportしても無理) bazが複数行の入力を集計した結果の変数をfooで見ることが出来ない。とかね 1データを1行に詰め込めればパイプ経由でのデータ受け渡しは可能だが それができないデータだと難しい 他の言語でやれって? それをシェルスクリプトでやらなきゃいけないというのが個人的な特殊な状況下というわけ シェルスクリプトでそのコマンドが実行された行数を取得する方法ってあるかな。 #!/usr/bin/env bashにすれば${LINENO}変数にその位置が格納されてるので簡単なんだけど やっぱりもうすこし汎用的な方法で実現したい。 >>577 LINENOしかないよ。ただしご存知の通りLINENOは使えないシェルがある。 dashなんか機能的には搭載されてるがdebianなどでは無効にされてるというw 更にシェルによっては関数呼び出しを行った時にソースコードの行数ではなく 関数の頭からの行数になっていて、それも0から始まるものと1から始まるものがある まともに使えるのはbashだけかな >>578 だよね〜。ファイルの中での自分の位置を調べるのはシェルスクリプトでは無理っぽいね。 Cのassert()関数みたいなのを自作したかったんだけど 機能が落ちるのは嫌だな(もういいけど) ああ ちなみに > 関数呼び出しを行った時にソースコードの行数ではなく > 関数の頭からの行数になっていて これGNU Bashのことを言ってるのなら関数じゃなくて別名にすればO.K.だよ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる