シェル (bash) の配列について使い方をまとめてみました。 配列を生成する 配列を生成する場合は配列名=(値1 値2 値3)と記述します。値を指定しなかった場合は空の配列が作成されます。 $ arr=() # 空の配列 $ arr=("first" "second" "third") $ echo "${arr[@]}" first second third declare -a 配列名コマンドを使うことで明示的に宣言することもできます。 $ declare -a arr=("first" "second" "third") $ echo "${arr[@]}" first second third 配列名[インデックス]=値という記法が使われた場合も配列が生成されます。 $ arr[0]="first" $ arr[1]="second" $ arr[2]="third" $ ech
算術式についてまとめます! 以下の衛星記事もご参照ください。 Bash $((算術式)) のすべて - A 基本編 - Qiita Bash $((算術式)) のすべて - B 罠・バグ回避編 - Qiita Bash $((算術式)) のすべて - C 応用編 - Qiita 本当は どうでも良い Bash 算術式の細かいこと をメインで書きたいのですが、それだと余り役に立たない記事になってしまうので、基本も網羅します! 先ず節1に基本事項をまとめ、それ以降に他に書かれていない色々の注意点・応用方法などを簡潔にまとめます。ちゃんとした説明は附録記事に譲ります。 これらの内容(特に節2以降)は、自分で算術式を使う過程で分かったこと・学んだことを基にしています。Bash のマニュアルに載っていないのは勿論のこと、他の場所にも載っていない情報を多く入れられたように思います。役に立つどうかは分か
業務系のシステムでシェルスクリプトを使用している場合など、 多重起動の防止などで排他制御が必要な場合が多々あると思いますが、その様な場合に役に立つシンボリックリンクを利用したシェルスクリプトでの排他制御方法です。 ただし、あくまでもシェルスクリプトによる処理ですので、厳密な意味での排他制御にはなり得ないために タイミングによってはどうしても多重起動してしまう危険性がある事は考慮しておく必要があります。 この処理では自分自身のプロセス ID をロックファイルとしてシンボリックリンクして利用しているので、排他制御を実施したプロセス ID が簡単に確認できる様にするとともに、何らかの理由で不正にロックファイルが残ってしまった場合にプロセス ID を確認する事で簡単にリカバリ可能としています。 なお、プロセス確認のために /proc を参照しているので、 Linux など /proc が存在するシ
bashコマンドのバックグランド実行方法について、まとまっている記事が見つからなかったのでまとめメモ 通常のバックグラウンド実行 &でバックグランド実行 参考：http://kazmax.zpp.jp/linux_beginner/process_background.html もっとも基本的なバックグランド実行、コマンドの後ろに&をつけて実行する。 ターミナルの切断が切れたりしてログアウトした場合に、 この方法で実行したプロセスはkillされてしまうので注意する。 途切れたら困る処理の場合はtmuxのセッション上で実行、 もしくは後述するnohupコマンドでのバックグラウンド実行推奨。 # バックグラウンド実行 $ sleep 5 & [1] 21871 # プロセス確認 $ ps $! # ps 21871 PID TTY STAT TIME COMMAND 21871 pts/0 S
コマンドラインプログラムの引数、オプションといったインターフェースには ちゃんと仕様、ガイドラインといったものが存在しています。 Unix(Linux) では慣習としてなんとなく合うものなのですが、 Windows や Java のプログラムなどでは、インターフェースがめちゃくちゃなプログラムも結構あります。 今回はコマンドラインプログラムの標準的なインターフェースの仕様、動作を紹介します。 プログラムを作る際の参考にしてもらえればと思います。 標準インターフェースはよくあるケースを考慮されて作られているものです。 自分の作っているプログラムは標準的なケースと違うといったことがあるかもしれません。 しかし、 標準のスタイルは合わせること自体に意味があります。 作成する場合にはなるべく標準インターフェースにあわせて作るべきだと思います。 Windows or Unix スタイル コマンドライ
#!/bin/bash : [DEBUG] set param readonly SCORE_ARRAY=(100 90 80 70) readonly COUNTS=${#SCORE_ARRAY[@]} function cal_score_ave() { local _score_sum=i : [DEBUG] cal for _score in ${SCORE_ARRAY[@]} do _score_sum=$((_score_sum + _score)) done score_ave=$((_score_sum / COUNTS)) return 0 } : [DEBUG] main cal_score_ave echo $score_ave echo $param echo "finished" exit 0 # bash -uvx cal_score_ave.sh #!/bin
算術式展開 算術式展開を使うと、算術式を評価して、その結果に置換できます。 算術式展開のフォーマットを次に示します: $((expression)) expression はダブルクォート内部にある場合と同様に扱われますが、 括弧の内側のダブルクォートが特別扱いされることはありません。 式に含まれる全てのトークンに対して、 パラメータ展開・文字列展開・コマンド置換・クォートの削除が行われます。 算術式置換は入れ子にできます。 評価は後述の 算術式評価で示す規則に基づいて行われます。 expression が不正であれば、 bash は評価の失敗を示すメッセージを出力し、置換を全く行いません。 man bash より引用 パラメータ展開 matsuiによるページを参照 Dokuwiki.fl8.jp » bash » 03 特殊な変数展開 ${parameter:-word} デフォルトの値
シェルスクリプトは長くなると処理の境界が不鮮明になりがち。 コメントで処理の境界を表現する工夫はよく見かけるが、もっと良い方法はないか考えてみた。 :コマンド、&&演算子、複合コマンド()や{}を組み合わせて書くと、処理の境界線がはっきりする。
Bash用テストフレームワークに、Batsやshunit2がありますが、イケてないなーと思ってたら、気づいたら自分で作ってました。 github.com テストの結果はモダンなテストフレームワークのように、カラフルに表示します。 またFAIL時は、FAILしたテストの結果を表示します。 自分の Arch Linux 上の Bash 4.3.42 および、Travis CI 上で動作することを確認しています。 インストール curl -o ~/bin/bashtub https://raw.githubusercontent.com/ueokande/bashtub/v0.1/bin/bashtub chmod +x ~/bin/bashtub です。ただし~/binはパスが通ってるとします。 これでターミナルから bashtub と打つことで実行できます。 bashtub テストを書く 各
目的 "getopt"は、Cライブラリもコマンド版も、どちらも使い方を覚えにくい。 ここでは、コマンド版 "getopt" と、sh/bash built-in の "getopts" の使い方をまとめる。 結果 sh/bash built-inのgetoptsが使える場合は、そちらを使った方が良い。 外部コマンド getopt 使用時は、クォート処理に気をつける。 速度的には、getoptとgetoptsどっちでも大して差はない。 getopts.sh https://sssvn.jp/svn/spikelet/sh/getopts.sh getopt-o.sh https://sssvn.jp/svn/spikelet/sh/getopt-o.sh 以下、詳細。 getopt を使う（クォート考慮なし） getopt(1)を参考にしつつ、素直に作成。 getopt.sh https:/
引数で複数のロングオプションを指定したい時のgetoptの指定の仕方がよくわからなかったので、 調べたり実験したりしてみた結果↓で出来るようになりました。 実行コマンド batch/sample.sh --target=maker --env=stage コード OPT=`getopt -o "" -l target: -l env: -- "$@"` if [ "$?" -ne 0 ]; then error "Usage: $0 [--target VALUE] [--env VALUE]" fi eval set -- "$OPT" until [ "$1" == "--" ]; do echo $1 case $1 in --target) target=$2 ;; --env) env=$2 ;; esac shift done echolog log "target is :
最新の類似投稿としてシェルスクリプトのコーディングルール2014も併せてどうぞ。 2014/10/09追記 ぼくがシェルスクリプトを書くときに気にしていること、過去の失敗で書き留めたことを忘れないために。 1. グローバル変数は大文字 PATH や HOME など、環境変数が大文字なので、エクスポートする変数を大文字で書くという習慣は一般的であるような気がしますが、エクスポートする変数を抱えるシェルスクリプトを作成する機会が稀なので。 グローバル変数は大文字 ローカル変数は小文字 エクスポートする変数も大文字 関数内からグローバル変数にアクセスする場合がありますが、やはり区別していると、可読性が増すような気がするのでお勧めです。 2. awk を知る Unix 上にて文書処理をするときに、数多くのフィルタコマンド（grep、cut、tr、head、sort、uniq、sed、awk、wc、
どうもこんにちは。フックしてますか。ジャブからローにつなげてますか。 そんなこんなで最近は僕もそこそこ git に慣れてきて助けてもらわなくても良くなって来ました。 しかし人間の欲望はとどまるところをしらず、「なんか定形作業めんどくせーなだるいしなんかうまいことどうにかなれよ面倒くせぇ」とか考え始めるものです。たとえば「テスト通ってないコードコミットするなってリーダーがいうけどいちいち手でテスト走らせて確認すんのだるいからなんかうまいこと自動で動かんかな」とか。 git は大変よくできたツールですので、そういうのもちゃんと用意されています。hooks といって、コミットのタイミングなどで特定のシェルスクリプトなりなんなりを動かすことが出来るよう配慮されているのです。すげーな git 。 しかしこいつがマジめんどくさい。自分でシェルスクリプト書くとか絶対嫌だし、すでにそのへんに転がってるのを
shell script は普段さけて通りたいと願ってやまないわけですが、たまには書かないといけないことがあるので、そういうときは覚えておくと便利な tips を2つ。 autodie っぽくするset -eとすると、コマンドの実行に失敗したときにそこで実行がとまるので便利。 #!/bin/sh set -e perl -e 'die' echo SHOULD NOT REACH HEREとすると % ./hoge.sh Died at -e line 1. % echo $? 255となって、最後までいかずに死にます。 複数のコマンドを順番に実行するときに便利。 なお、以下のような挙動をするんだそうです。 ただし失敗したコマンドが until または while ループの一部である、 if 文の一部である、 && または || リストの一部である、 コマンドの返り値が ! で反転されてい
/bin/shの実体としてはash（dash）、bash、kshの採用例が多い。どのシェルもBourne shellの機能に加えて、拡張機能を提供する。 FreeBSDなどの＊BSD系のOSは、ashを/bin/shとして使っている。ashはPOSIX.1（POSIX:2008）にいくらかのBSD拡張機能を取り込んだシェルだ。メモリをあまり消費せず、高速に動作し、ほかのライブラリに依存することが少ない。従って、rootやレスキューシステムのインタラクティブシェル、システムのシェルスクリプトといった場面で採用されている。 Mac OS Xはbashを/bin/shに採用している。FedoraやopenSUSEなどのLinuxディストリビューションもbashを/bin/shに採用している。LinuxディストリビューションでもUbuntuやDebian、Linux Mintなどは、高速に動作する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く