POSIX シェルの小ネタ集。随時更新。 POSIX の範囲外の機能に依存するところには 【non-POSIX】 と書いておいた。 ファイル操作 空のファイルを作る touch でもいいがリダイレクトした方が速い。 >> filename # 既存ファイルは上書きしない (ファイルの更新日時も変へない) >| filename # 既存ファイルは空にする > filename # -C が有効なら既存ファイルがあるとエラーになる フィルタ ソートして重複行を消す sort | uniq でもいいが sort -u だと一コマンドで済む。 ソートせずに重複行を消す awk '!x[$0]++' 1 行番号を付加する awk '{print ++i,$0}' 【non-POSIX】 cat -n 一行目だけを消す tail -n +2 sed 1d 最後の行だけを消す head -n -1 s
Bourne 系対話シェルの初期化ファイル (.bashrc とか .zshrc とか) でコマンドの動作を変更しようとするとき、エイリアスにするか関数にするか迷ひませんか。私はさっき迷ひました1。少し考へて、かういふ風に使ひ分ければいいのかなといふのをここにメモっておきます。 複雑なことをするなら関数一択 かういふのはエイリアスには無理。 コマンドの挙動を破壊的に変更するならエイリアス 例へば alias grep='grep --color=tty' は grep コマンドの出力を条件付きで少し変へるだけ。grep コマンドの出力を他のコマンドにパイプしたりするときは grep コマンドは普通の grep と同様に動く。よって、他の関数とかエイリアスとかで grep が使はれてゐたとしてもそれらがバグることはほぼない。こんな場合は、 grep() { command grep --co
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基本的に irxground 君と同意見のところは省略します。 あと、GoF の本自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければなら
シェルスクリプトで、あるファイルパスに別の相対ファイルパスを連結して新しいファイルパスを得るには次のようにします。 前提 ベースとなるパス base は空文字列ではない 連結するパス rel は空文字列ではなく、かつスラッシュで始まらない コード 解説 結果が単語分割されるを避けるため、全体を二重引用符で囲みます。 ${base%/} で、 base の末尾にスラッシュがある場合にはそれを(一つ)消します。これにより base がスラッシュのみからなるパスである場合でもスラッシュの数が変わることを防ぎます。例えば base が / で rel が home ならば結果は /home になります。 ここでもし "${base}/${rel}" を使ったとしたら、結果は //home になります。Cygwin などの環境ではスラッシュ二つが特別な意味を持つため、これは正しい結果ではありません。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR: 変数や関数を追加するときは、周りにある他の変数や関数の名前を修正すべきでないか検討せよ いきなりですが問題です。あるソフトウェアモジュールに以下の三つの関数があります。 show showWithSlideAnimation showWithoutAnimation 画面をスライドさせながら出現させるにはどの関数を使用すれば良いでせうか? 関数の名前だけを見て答へてください。 はい、その通り。showWithSlideAnimation が正解です。 では、画面をアニメーションなしで出現させたい場合はどの関数が良いでせうか
うまくクラス名を付けるための参考情報といふ記事を見掛けて、「動詞+er」のパターンがちょっと多くていまいちだなーとか思って書いた記事です。 以前クラスの命名のアンチパターンといふ記事を書きましたが、これを読んで「Animation と Animator とではどっちがええんやろ?」と思った人への回答でもあります。 昔の Java では可変文字列クラスは StringBuffer と呼ばれてゐました。C# や最近の Java では可変文字列クラスは StringBuilder と呼ばれます。Objective-C では MutableString です1。 私はこの中では MutableString が最も良いと思ってゐます。次点は StringBuffer です。 StringBuilder はダメです。 MutableString が良い理由は、完全にその名が体を表してゐるからです。直訳
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParame
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く