bash のシェルスクリプトを書くときに、いつも脳死で以下をやっている。(同僚が整備してくれたものをコピペしている) エディタなり CI で shellcheck をまわす set -euxo pipefail と冒頭に書く こんな感じ #!/bin/bash set -euxo pipefail いつまでもコピペではさすがにアレなので、意味を調べたメモ。 shellcheck koalaman/shellcheck: ShellCheck, a static analysis tool for shell scripts イケてない書き方に警告を出してくれる それぞれの警告にはエラーコード割り振られていてとても便利 エラーコードごとに正誤例、解説が書かれているのでわかりやすい SC1000 の例 CI もそうだし、エディタのプラグインも充実 しているのでとりあえず入れておくと良い set
■ bash の危険な算術式 _ 使ってる人がいちばん多いだろうからタイトルでは bash としてるけど、ここで取り上げることは zsh および ksh 一族(本家 ksh、pdksh、mksh)にも該当する。ash、dash などでは該当しない。 _ 以下のシェルスクリプトには脆弱性がある。わかるだろうか。 #!/bin/bash # "品目,単価,個数" の形式の CSV を読んで、"品目,合計金額" の形式で出力する csv="foo.csv" while IFS=, read item price num; do echo "$item,$((price*num))" done < "$csv" これ、細工された CSV ファイルを食わせることで、任意コードの実行ができてしまう。数ある脆弱性の中でもとくにヤバいやつだ。どこが穴なのかというと、タイトルにもあるとおり算術式なのだが、し
(注:2017/04/10、いただいたフィードバックを元に翻訳を修正いたしました。) はじめに 私はLinuxが大好きです。コンピュータとのやりとりが楽しくなるし学ぶことも多くなります。OSとハードウェアの基盤となる基本原則を学びたい人にとって、Linuxはとてもいい出発点と言えるでしょう。 ご存じのとおりLinuxとは大抵の場合プログラム(コマンド)を通してやりとりします。Linuxと他のUNIX系システムが持っている特徴は、コマンドラインと、パイプのコンセプトです。プログラムの提供する入力と出力を統合すれば、データを操作するのに非常にパワフルなプラットフォームになります。 Linuxのコマンド、プログラム、バイナリ(何と呼んでもいいのですが)の大部分は、/usr/bin、/usr/sbin/、/binそして/usr/local/binに存在しています。これらのディレクトリを見れば、プロ
はじめに 以前書いたエントリー、重大な脆弱性(CVE-2017-5932)で少し話題になったbash4.4の補完機能の便利な点で、bash4.4からでないとタブの補完機能のソート処理が制御できないという問題について、ソースコードレベルで調べた結果をまとめていたのですが、bashの実装そのものを深く掘り下げ過ぎてしまい、内容が膨大になったので、何回かに分けて書こうと思います。 今回はbashが起動されてからインタラクティブモードでキーボードの入力を待ち受けるまでのお話です。普段使っているbashがどのような処理を行っているのか一緒に覗いてみませんか? 検証ソースコード Bash version 4.1.0(1) release GNU bashの生誕 bashのプロセスが起動されるのはOSへのログイン時にユーザーのログインシェルがbashに設定されている場合、あるいはログイン後に明示的にba
大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げ
さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基本的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分
概要 sedは、入力ストリームに対して様々なテキスト変換をおこなう、ストリームエディタです。 cut, grep, trといった基本的なフィルタコマンドと比較して、柔軟なテキスト処理が可能です。 このsedの機能の1つとして、パターンスペース・ホールドスペースがあります。 高度なテキスト処理が可能になる反面、パターンスペース・ホールドスペースは、動作が理解し辛いという難点があります。 ですが、sedのパターンスペース・ホールドスペースの動作を丁寧に解説した記事は、私が探した限りでは見つかりませんでした。 そこで、sedを深く学ぶ方への助けとして、また私自身の復習として、sedのパターンスペース・ホールドスペースの動作を、記事としてまとめました。 本記事では、sedのパターンスペース・ホールドスペースの動作を、図示して解説します。 実行環境 Arch Linux 4.8.8-2-ARCH G
上記の表の通り,Exit Code 1, 2, 126〜165, 255 は特別な意味を持ち,スクリプトやプログラム内で exit に指定するパラメータとしては避けるべきである.とりわけ,Exit Code 127 はトラブルシューティングで混乱の元である("command not found" で終了したのか,プログラム固有のエラーなのか区別できなくなる).しかしながら,多くのスクリプトが exit 1 を一般的な実行を続行できないエラーとして使っている.Exit Code 1 は Bash の一般的なエラーを含め,とても多くのエラーで発生しうるので,デバッグの時に切り分けが大変になるだろう. Exit Code を体系立てて定義する試みはある(/usr/include/sysexits.h)が,これは C と C++ プログラマー向けである.スクリプトに関しても同様な感じにするのが適切
以下、長々と書いてますが、結論は ”私の環境で”大きなテキストファイルをawkで処理するときにcatで投げ込むと速い理由 - ablogに書いてます はじめに awk file より cat file|awk のほうが速いという以下のブログエントリが興味深いので調べてみました。 ちなみに cat file|awk が速くなる環境は稀で、巷では awk file のほうが速い環境のほうが多いようで、どちらが速いかは環境依存です。 [root@localhost sample]# cat command1 awk '$5 ~ /((26|27|28|29|30)\/Jun|(01|02|03)\/Jul)/{ print }' sample.txt > result1.txt (中略) [root@localhost sample]# time sh command1 real 0m53.92
追記が増えたので整理 経緯 2.5GBのテキストファイルを加工する必要があり、①vimで開いて加工→vim死亡②sublime textで開いて加工→sublime text死亡となったため、awkを用いて以下の様なコマンドを実行した。 $ cat sample.txt | awk '$5 ~ /((26|27|28|29|30)\/Jun|(01|02|03)\/Jul)/{ print }' > result.txt すると 「catいらなくね?」と指摘 さらにMATSUMOTO, Ryosuke (@matsumotory) | Twitter < 「キャッシュに入れて高速化してるんかと思った」 とコメントをもらいました。ので、どっちが速いかの検証です。 注意 加工の目的はログファイルからある期間だけの行を抜き取りたい 正規表現がいけてないのは気にしない 比較 awkにファイル指定す
特定コマンドの正規表現で使えるメタ文字が何だかわからない! 正規表現自体は知っているけど、それが今から使おうとしているコマンドで使えるものなのかわからずに困っている人も多いと思うのでまとめてみた。 たった3つの正規表現メタ文字セットだけ知ればいい コマンドによって、対応している正規表現メタ文字の範囲には違いがある。しかし、最低限知っておけばよいのは2種類+1サブセットの3つだけだ。 BRE(基本正規表現)メタ文字セット ERE(拡張正規表現)メタ文字セット AWKのサブセット もちろん、これ以外にもGNU拡張正規表現メタ文字セットやPerl拡張正規表現メタ文字セット、JavaScript拡張正規表現メタ文字セットなどいくつかあるのだが、「どのUNIXでも(=POSIXで)使える」という特長を持たせたいのであれば、それらは覚えても意味がないので上記の3つさえおさえておけばよい。(例えPOSI
Stop using tail -f (mostly) 12 Mar 2015 I still see a lot of people using tail -f to monitor files that are changing, mostly log files. If you are one of them, let me show you a better alternative: less +F The less documentation explains well what this +F is all about: Scroll forward, and keep trying to read when the end of file is reached. Normally this command would be used when already at the e
システムを運用していく上で cron を使う場面はよくありますよね 処理をスケジュール実行したい時にとても便利です そんな cron ですが、最近仕事で作業しているときに ntpdate でシステム時刻を変更した後に cron で設定した時刻になってもジョブが実行されないという問題が見つかりました 全てのジョブが実行されていないわけではなく一部のジョブは実行されているようでした また、時刻を変更した後に crond を再起動すれば全てのジョブが正常に実行されるようになりました 幸い、実運用ではなくてシステムテスト中に見つかった問題なのでまだよかったんですが、運用している環境で同じ問題が起きたら相当マズイですよね そもそも ntp の時刻同期でシステム時刻が修正された場合にも同じ問題が起きそうじゃないですか? ググっても同じような事象は見つからず、社内のメンバーにも聞いてみても cron で
シェルスクリプトの中で、スペース区切りもしくはタブ区切りのレコードを扱うことがよくあると思います。 たとえば、前回のエントリ「AWS CLIとjqを使って、AWSのELBボリュームがアタッチされているEC2インスタンス名を出力するワンライナーを書いた - 双六工場日誌」のスクリプトの出力は以下のようになります。 i-ec56a9f5 vol-07d00601 servername i-ec56a9f5 vol-8f550991 servername このようなレコードの特定の列を取り出して、処理する際にどうするのが効率的か、というのがこのエントリのお題です。 非常に古い話題なので、昔からシェルスクリプトを書いている人には自明な話ではありますが、最近、シェルの標準機能の話を聞く機会がなく、失われつつある技術になってきている気がしているので、改めて確認ということで。 例として挙げたレコードから
2016/12/27 更新Googleなどの大手IT企業がうるう秒対策済のNTPサーバが公開したため、これを利用する内容などを以下にまとめました。 元旦に実施される うるう秒の対策 まとめ2016/07/08 更新2017/1/1に閏秒の実施が決定されました。対応はこの記事のとおりで問題なさそうです。 2015/06/24 情報追加(2015/06/29 更新)下記の対応に関わるntpdの比較的新しいバージョンにSLEWモードで動作していても、うるう秒が挿入されるバグが発見されました。[redhat] これによりntp-4.2.8p3-RC1以降のバージョンでないとSLEWモードで動作していてもうるう秒が挿入されます。RedHatはntp-4.2.6p5-3.el6_6という対応済みのバージョンを提供しています。Ubuntuでは今日現在12.04LTS, 14.04LTSの2バージョンはパ
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" ar
bashに脆弱性が確認されたとして騒ぎになっています。ここではCVE-2014-6271に関する情報をまとめます。 #記載内容について、誤っている、追記した方がいい等情報がございましたら@piyokangoまでご連絡お願いします。 脆弱性情報 脆弱性の愛称 ShellShock Bashbug CVE番号 Bash周りで発行されているCVEは6つ。その内詳細が不明なのが2つ。(CVE-2014-6277,CVE-2014-6278) CVE 発見者 想定脅威 特記 CVE-2014-6271 Stephane Chazelas氏 任意のコード実行 ShellShockの発端となったバグ。 CVE-2014-7169 Tavis Ormandy氏 任意のコード実行 CVE-2014-6271修正漏れによる脆弱性 CVE-2014-7186 Redhat DoS メモリ破壊(Out-of-Bo
はてなブログが Gist からの貼付けに対応したようなのでさっそく試してみる。 これは何? ファイルの先頭だけを表示する head, 末尾だけを表示する tail というコマンドがあるので、それに習ってファイルの真ん中を表示する body というシェルの関数を作ってみた。開始と終了の行番号を指定したら、フアイルのその範囲内だけを出力してくれる。 ソースコード これを .bashrc とか .zshrc に書けば OK。 開始行と終了行を指定して、ファイルのその範囲内だけを出力するシェルの関数 使い方 body 開始,終了 フアイル名 という形式で使える。 # file1.txt の10行目から20行目までを出力する % body 10,20 file1.txt 開始、終了を省略することもできる。省略したらそれぞれ「先頭行から」、「末尾行まで」という意味になる。 # 1行目から20行目までを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く