初心者向け、「上手い」シェルスクリプトの書き方メモ - Qiita
ここ最近、沢山シェルスクリプトを書くようになりました。 元々あまりシェルスクリプトを書いたこと無かったので、色々と勉強しつつ書いてるのですが、 他のプログラミング言語とはちょっと違って独特なクセというか、発見の度におぉー！ってなることが沢山あって楽しいです。 そんなわけで、最近学んだり参考にした中で特に感動したシェルの上手い書き方をまとめてみます。 きっとまだ知らないこととかもっと上手くやる方法なんかが沢山見つかりそうなので、 もっといいやり方あるよ！って方はコメントください 何もしない : (コロン)コマンド シェルを書いていた時に非常に欲しかったコマンドがこれ！何もしない！ : というコマンド(？)を利用すると、何もせずに終了ステータス0(つまり正常終了)を返します。 これが様々な事に使える万能コマンドで、これによって面倒なエラー処理を簡潔にできたり、 入力や出力のリダイレクト元/先と
仕事で使えるシェルスクリプト
[第136回関西Debian勉強会 + Linux Kernel 勉強会 LT大会](https://debianjp.connpass.com/event/90376/)での発表資料です。
複数プロジェクトを抱えるチームでのデプロイ自動化
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
コマンドラインツールを作るときに参考にしている資料 | SOTA
コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた． 今年のYAPCで，そのコマンドラインツールをつくるときにどういうことを意識して作っているのか？どのような流れで開発しているのか？といったことを語る機会をもらえた． 具体的な内容については，是非トークを聴きに来てもらうとして， スライドをつくるにあったって過去に読んだ資料や，よく参考にしている記事を集め直したので，その一部を参考資料としてまとめておく． UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた本．古いが全然色あせてない． コマンドラインツールの作り方を書いた本ではないが，これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う．何度も読んで考え方を染み付かせた． 小さい
bash によるオプション解析 - Qiita
すこし記事が長いため、簡単なアウトラインを書いておきます。要点だけ掴みたい場合は、最終項の「まとめ」を読むのがいいかもしれません。 コマンドライン引数の一般的な解析手法 それぞれの特徴 〜 getopt と getopts の違い getopts（メリット・デメリット） getopt（メリット・デメリット） 自前で解析しちゃう（唯一のデメリット） まとめ ============================= コマンドライン引数を処理する一般的な手法として、 getopts getopt shift などで自力で解析 といった具合に、上から順に考えつくかと思います。getopt(3) は UNIX において、コマンドの引数を処理する一般的な C 言語のライブラリ関数です。それを用いて実装されたコマンドが getopt(1) です。Bourne シェル系だと内部関数になりますが、同系統の
ShellCheck – shell script analysis tool
GPLv3: free as in freedom documented on the ShellCheck Wiki available on GitHub (as is this website) already packaged for your distro or package manager supported as an integrated linter in major editors available in CodeClimate, Codacy and CodeFactor to auto-check your GitHub repo written in Haskell, if you're into that sort of thing.
続・ラフなラボ – シェルスクリプトが '> $logfile 2>&1' だらけにならなくて済んだ話
※ 2014-04-26 追記並びに一部コマンド部分の修正を行いました。( > => >> に変更 ) 個人用のチラシの裏のつもりが予想以上に反響いただいていたようで非常にびっくりしております。 ちょっとしたバッチ処理的なものはさくっとシェルスクリプトでやっています。 で、ログをとっておくべくリダイレクトを噛ますわけですが、 スマートに書く方法を調べたのでメモ。 元ネタは @sechiro さんの bashのプロセス置換機能を活用して、シェル作業やスクリプト書きを効率化する でございます。 本当に参考になりました。ありがとうございます。 今までは こんなことやってたわけです。 #!/bin/bash LOGFILE=/tmp/script-log command1 >> $LOGFILE 2>&1 command2 >> $LOGFILE 2>&1 ... >> $LOGFILE 2>&1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA