ブックマーク / qiita.com/ko1nksm (2)

  • 【衝撃の罠】bashスクリプトのパフォーマンス測定は、対話シェルでやっても無意味だ! - Qiita

    理由 びっくりした。対話シェルで実行してパフォーマンス測定すると何故かめちゃくちゃ時間がかかる。これではデータにならない。 追記 よくよく考えたらパフォーマンス測定だけの問題ではなく実際に遅くなるのだから、対話シェルから「このようなコード」を実行してはいけないということを意味しています。「このようなコード」がどのようなコードなのか発生条件はまだ特定できていませんが、少なくともシェルスクリプトにしていれば問題は発生しません。また bash 以外のシェルでも問題は発生しません。 検証結果が気になった方は、ぜひ試してみて、この話を広めてください。 証拠 実行環境: Ubuntu 22.04.3 LTS、bash 5.1.16

    【衝撃の罠】bashスクリプトのパフォーマンス測定は、対話シェルでやっても無意味だ! - Qiita
    softstone
    softstone 2023/09/30
    ブコメ読むとreadが本来行単位のIOをするものだから遅くて当然、非対話モードのときにちゃんと最適化してるってことかな。/いやパイプが偉いんかな。time bash -c '{ while read i; do : ; done < <(seq 100000); }' これだと遅いままですね
  • 【脱sed】いい加減シェルスクリプトで文字列をsedで置換するなんてやめよう - Qiita

    はじめに もう文字列の置換で sed コマンド使うの禁止して良いんじゃないですかね? 言いすぎだとわかってあえて言っていますが。 悪い書き方(外部コマンドに頼る方法) # 変数 line に入ってる文字列を echo コマンドで出力して sed コマンドに渡し、 # sed の s コマンドで "from" を "to" に置換して出力したものを ret 変数で受け取る ret=$(echo "$line" | sed "s/from/to/")

    【脱sed】いい加減シェルスクリプトで文字列をsedで置換するなんてやめよう - Qiita
    softstone
    softstone 2023/09/02
    良い記事/MacOSデフォだとBSD版のsedでgnu版とかけ離れた動作するので、普段使いではbash決め打ちでシェルスクリプトに寄せたほうが互換性も効く場合が多いよね。/タイトル初見で真逆の方向の記事だと誤解したのは秘密だ。
  • 1