bashでJSONに変数を埋め込むための3つの方法 | DevelopersIO
昨今のWEB APIは、情報のやりとりにJSONを用いることが多いかと思います。Linuxのサーバを運用していると、手軽に書けるシェルスクリプトを使っていろいろなAPIを叩く機会が多いのですが、JSONの扱いには頻繁に悩まされます。 その悩みの一つは、いかにしてJSONに変数を埋め込むかというところです。例えば { "foo" : "bar" } のようなJSONがあったとします。ここで、fooのvalueであるbarの部分を、値を変数として受け取り、それを設定したいことになりました。JSONの文字列はダブルクォートで囲まれている必要があるため、コマンドラインやシェルスクリプトで利用する時にはシングルクォートで囲む必要があります。ですが、そうすると変数展開の機能が使えなくなってしまいます。 筆者も今までに何度か悩みました。この投稿では、これまでに使った3つの方法をご紹介します。 今回は、例
Bashアプリケーションをテストする | POSTD
以前、bashスクリプトをテストする仕事に取り組んだことがあります。最初、Pythonユニットテストを使うことにしましたが、プロジェクトに外部技術を持ち込むのは気が進みませんでした。そこで、仕方なく、悪名高い bash で書かれたテスト用フレームワークを使いました。 既存ソリューションの概要 手に入るソリューションを探してGoogle検索しましたが、選択肢はほんの少ししかありませんでした。そのうちいくつかについて、詳しく見ていきましょう。 重要になるのは、どんな基準でしょうか？ 依存関係： bass のテスト用フレームワークを選ぶときに、 python 、 lua などのシステムパッケージも一緒に引きずり込むのは嫌ですね。 インストールの難しさ：継続的な開発の実装とTravis CIでの継続的な統合も仕事の1つだったので、私にとってインストールにかかる時間と手間数が妥当だということは、重要
Googleの肩に乗ってShellコーディングしちゃおう - Qiita
はじめに GoogleさんがShellスタイルガイドを共有していたので、いくつか気になった点をピックアップしました。 自分のShellスタイルはかなり我流なので、自省の意味も込めてコメントも併記します。 Googleスタイルガイドの元ネタ （Python/C++/Java/Rとかだけでなくdocumentガイドなど色々あります） https://github.com/google/styleguide Shellスタイルガイド （今回はこちら） http://google.github.io/styleguide/shell.xml 本当は人間がチェックするのではなくcpplintのためXML定義なのかもですが、気にしない気にしない。 （見たところcpplintはc++だけだと思ってます） commitフックでshell系のlint走らせろっていうのが今風なのかもしれませんが、キニシナイキ
bashの初見殺しっぷりがハンパない件 - Qiita
「これ知らなきゃ分からないだろ！」 「エラーの原因はわかったけど、なんか腑に落ちない」 いま悩んだ２時間返せ！ bashというか、UNIXのコマンドに慣れてない 僕みたいな新人エンジニアが 気をつけた方がいいポイントまとめました。 あいことばをわすれない 微妙にエラーが出ないため、気づかないまま進んでしまい、 のちのち絶妙に致命的なことになってしまうので注意。 一行目忘れて２時間悩みました 二行目のオプションつけなかったため２時間悩みました setのオプションはお好みで あいことばの解説： http://qiita.com/magicant/items/f3554274ee500bddaca8 半角スペースをつけるな！半角スペースをつけろ！ shellさんはスペースに非常に神経質です。 よくある変数代入では=の前後にスペースいれてはダメです。
bashのTips色々 - Qiita
概要 bashの記法は独特なものが多く毎回ググってしまうのでまとめて(と言いつつまとまりがないですが。。。)おこうと思います。 ある程度まとまってからpostしようとか思ってたらごちゃごちゃになっちゃいました。 bashで使えるという意味なのでposixシェル共通のネタも混ざってます。 随時更新します。参考になれば幸いです。 参考 man bash リファレンスマニュアル Advanced Bash-Scripting Guide カッコ色々 bashでは色々なカッコがありますが、よく違いが分からず使っていたりするのでまとめてみます。 []と[[]] []はtestコマンドのaliasです。[[]]じゃないとできないこととしては、以下のようなものがあります。 空白を含む文字列をクォートしなくてOK var='abc 123' # []の中だとクォートしないとエラーになる [ $var =
Linuxの ~(tilde) について - rochefort's blog
先日一緒に作業をしていた若者が~(tilde)を知らなかったので、~(tilde) ってのはHOMEディレクトリを指すんだよー。と教えてあげていたのですが、ふと実装が気になったのでソースをのぞいてみました。 まずはググってみる なぜUnix&Linuxではホームディレクトリを「~」文字で表現するのか。 - [モ]Modern Syntax なるほど昔のキーボード由来なんですね。 本題 ソースを見てみます GNU Project Archives から該当バージョンのソースをダウンロード。 $ bash --version GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin14) Copyright (C) 2007 Free Software Foundation, Inc. 環境変数Home を返すところ それっぽい名前のファ
bash の脆弱性 "Shell Shock" のめっちゃ細かい話 (CVE-2014-6271) - もろず blog
※(2014/10/1 追記) 脆弱性の番号を誤って CVE-2014-6721 と表記してしまっていました 正しくは "CVE-2014-6271" です 失礼致しました ※(2014/10/7 追記) 2014/10/7 14:00時点で Shell Shock への修正パッチは6個 公開されています 既に対応済みのシステムでもパッチの漏れがないか注意してください シェルに脆弱性が見つかったらしいです このコマンドを実行すると脆弱性があるバージョンかのチェックができるようです $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" 以下のように表示されたらアウトです vulnerable this is a test どうやら、このコマンドが正常に実行できるというのがこの脆弱性の正体らしく、 echo vuln
2014/09/24に発表されたBash脆弱性と解決法(RedHat系、9/26更新) - Qiita
2014/09/26更新: 本日新たに公開された再修正版を適用するように、情報を更新しました。恐らく、24日のは暫定対応版で今回のリリースが正式対応版だと思います。緊急性については前回のレベルほど高くありません（が、前回の作業を行っていない場合は急ぎましょう）。 Bash使い(特にBashのCGIスクリプト書いてる人)は一刻を争うべき 2014/09/24に発表されてたBash脆弱性。 上記サイトに概要が書いてありますが、何が一番ヤバいかと言えばBashで書いたCGIスクリプトを動かしているサーバーだと私は思います。 詳しくは書きませんが、telnetコマンドで簡単に悪意のあるコードを仕込めました。悪意あるコードが、rmコマンドだったりしたら。取り返しが付きません。 解決法(RedHat、CentOS等) yumコマンドやrpmコマンドでパッケージ管理をしているRedHat系（CentOS
bashにコードインジェクションの脆弱性「Shellshock」、管理者に大きなショック
bashにコードインジェクションの脆弱性「Shellshock」、管理者に大きなショック：影響範囲はどこまで？ UNIX系OSのシェル「bash」に極めて深刻な脆弱（ぜいじゃく）性が発見された。すでにこの脆弱性をスキャンする通信を観測したという報告もあり、修正パッチの適用や継続的な情報収集が望まれる。 米国時間の2014年9月24日、LinuxやMac OS XなどのUNIX系OSで使われているシェル「bash（Bourne Again Shell）」に、極めて深刻な脆弱性（CVE-2014-6271）が発見された。シェルの環境変数として外部入力を受け入れる設定となっている環境では、最悪の場合、リモートから任意のコマンドを実行される恐れがある。bashの配布元であるGNU Projectやパッケージ配布を行っている各Linuxディストリビューションがパッチを公開済みで、速やかに適用するよう
bashを読もう！『オープンソースアプリケーションのアーキテクチャ』3.1〜3.3 | DevelopersIO
こんにちは、虎塚です。 8月31日(日)に「オープンソースアプリケーションのアーキテクチャ読書会(1)」という勉強会に参加してきました。 とても面白い本だったので、3章の3.1〜3.2の内容をレポートしたいと思います。 The Architecture of Open Source Applications 日本語版PDF はじめに 読書会の開催経緯 主催者の方がある経緯でSQLiteのソースコードを読もうとしたところ、想定したより巨大だったので、先にBarkeley DBを読むことにしたそうです。 Barkeley DBの資料を探す中で、この本『Architecture of Open Source Applications』に辿り着き、せっかくなので他にも面白そうな章を読んでみようということで、今回の読書会が企画されたとのことです。 読書会の進行 20人ほどの参加者を席順に従って2人ず
シェルスクリプトを書くときはset -euしておく - Qiita
エラーがあったらシェルスクリプトをそこで打ち止めにしてくれる（exit 0以外が返るものがあったら止まるようになる）。「あっあれここでうまくいってないからデータ準備できてないのにあれあれっもうやめて！」ってなるのを防げる。 set -u 未定義の変数を使おうとしたときに打ち止めにしてくれる。Perlでいうuse strict 'vars';的なもの。 って気軽な気持ちで書いてしまって、「ん、やたら時間かかると思ったらスペルミスうわなにをするやめ」ってなるのを防げる。 一部だけ例外にしたい はてなブックマークのコメントより -e は command1 || command2 みたいなことが出来なくなるの使うことないな。-uは付けといて良いが。 確かにおっしゃるとおりですね。コマンドの失敗を考慮して書いている部分については（もしくはやたらexit 0以外するコマンドを呼ばないといけないときなど
今更ながら抑えておきたいシェルスクリプト用チートシート - Qiita
シェルスクリプト書くときになかなか覚えていなくて、かつググラビリティが低い情報をまとめてみました。 6/19 コメントを元に一部修正しました hnakamurさんありがとうございます！ 参考になる文献 test bash manual zsh manual 特殊な変数 変数 説明
bashの正規表現マッチングの使い方 - adsaria mood
あるフリーウェアのインストール用bashプログラムを見ていたら次の様なものがあった。（以下の例は簡略化してある。） STRING="abc" if [[ "$STRING" =~ "^ab[cd]$" ]]; then echo "matched" else echo "unmatched" fi if文の条件表現の中に“=~”というオペレータがある。manを見ると =~ オペレータは文字列を正規表現と比較するとある。知らなかった。bashの文字列比較で正規表現が使えるとは。私は正規表現比較が必要な時はgrepに喰わせて判断していたのだが、これを使えば簡単にできる。 ところが、だ。上のプログラムが期待通りに動かない。上の例では =~ の左辺と右辺の正規表現はマッチするはずだが、結果は“unmatched”。色々と正規表現を変えてみたが、どれとしてマッチングしない。しかし、if文を次のように
bashのキー操作一覧まとめ - 元RX-7乗りの適当な日々
bashでは、"Ctrl"や"Esc"キーと組み合わせることで様々な操作ができるので、メモ代わりにまとめておきます。 よくやるのが「Ctrl + s」キーを押してしまうと、フリーズしたかのように見えるので一瞬焦ってしまう。そんな時は・・・ Ctrl + b カーソルを左へ1文字移動 (←キーでもOK) Ctrl + f カーソルを右へ1文字移動 (→キーでもOK) Esc + b カーソルを右へ1単語移動 Esc + f カーソルを右へ1単語移動 Ctrl + p historyの1つ前に入力したコマンドを表示 (↑キーでもOK) Ctrl + n historyの1つ後に入力したコマンドを表示 (↓キーでもOK) Ctrl + h カーソルの左1文字を削除 (BackspaceキーでもOK) Ctrl + d カーソルの右1文字を削除 (DeleteキーでもOK) Ctrl + a カー
Unixのコマンドラインで使えるちょっとした小技をまとめた『Unix Comman-Line Kung Fu』 | IDEA*IDEA
ドットインストール代表のライフハックブログ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bashのそれって実はこういう書き方できるよ一覧 - Qiita
Shell Style Guide
bash-hackers.org
2014年10月8日のtwitterセキュリティクラスタ – twitterセキュリティネタまとめ