rootで rm -rf /* したら
身の毛もよだつコマンドですね。 もう5年以上前の話。 お客様の本番サーバでこれをやってしまいました。そのシステムはWeb+DBなシステムでLAPPを1サーバで構成していました。つまりDBもそこに含まれていたわけです。 そもそもやりたかったのは、とあるディレクトリ内のファイルを削除するだけでした。 # rm -rf * とすれば良かったのですが、なぜか丁寧にやろうというか何というかこう入力した「つもり」だったんですね。 # rm -rf ./* で、実際に実行されたのが以下。 # rm -rf /* 実行して数秒しても返ってこないので、アレ？と思って、焦って CTRL+C しても後のカーニバル。 そこから先はイマイチ覚えてないけど、[cd /][ls -la /usr]とかしても「No such file or directory」「command not found」やらが出て、とにかく異
ついにやらかした rm -rf / - 酒日記 はてな支店
UNIX の root なら誰もが必ず一度はやるという、rm -rf / をついにやった。root歴10年にして…… 社内の開発サーバだったのが不幸中の幸いではあったが。 vsftpd でホームディレクトリがない時の挙動を確認したくて、テスト用のユーザ fujiwara2 の home を mv しようと、 # mv /home/fujiwara2 /ここまで打ち込んで、やっぱ mv じゃなくて rm でいいや、と思い直して # rm -rf /home/fujiwara2 /最後の / を付けたままで実行してしまった…… なんか返ってこないな? と思って気が付いて、慌ててキャンセルはしたのだが、時既に遅し。 /dev /etc あたりがごっそり消えた。なんでか /bin /boot は残ってた。 これまた幸いというか、このホストは VMware のバーチャルマシンだったので、2007年7
MySQL の結果を csv 形式で標準出力させたい - いけむランド
最近は DB の動作を理解しようと、気になったところは MySQL のソースを読んだりしているため、そこらへんで学んだことをちょっとずつ書くことにする。 ちなみに結論を先に述べておくと MySQL の結果を標準出力に出す場合は今のところはタブ区切りでしか出せないようにハードコーディングされているために % mysql -e "SELECT ..." | sed -e 's/\t/,/g'みたいに出力を加工するしかないようである。 そもそも MySQL の結果を csv 形式で「ファイルに」出力する方法はある。ひとつはコマンド mysqldump のオプションで指定する方法である。 --fields-terminated-by=..., --fields-enclosed-by=..., --fields-optionally-enclosed-by=..., --fields-escape
git-cherry-pickを掘り下げる - idesaku blog
Gitにgit-cherry-pickという、知らなくてもなんとかなるが知っていると便利なコマンドがある。このコマンドを少し掘り下げてみた。 git-cherry-pick git-cherry-pickは、狙ったコミットの変更内容だけを現在のブランチに取り込む操作である。 例えば、つぎのような履歴を想定する。 ---A---B---C [master] \ \ ---X---Y [temp]ここで、YはCの後にコミットするほうが適切であることに気づいた。このとき、masterブランチで次のようにすると目的は達成される*1。 $ git cherry-pick YコミットYの変更内容だけをmasterのHEADに適用する、という操作である。このときXの変更内容は適用されない点がgit-mergeとは異なる。 ---A---B---C---Y' [master] \ \ ---X---Y [
Gitで特定のファイルだけをマージする - 大規模サービス開発日誌
cherry-pick Gitを使っているとたまにあるブランチからファイル単位でマージしたくなる。しかし、Gitを使ってる以上コミットをベースに生きるべきなのでそんな気分のときもcherry-pickを使おう。 git cherry-pick これは特定のコミットを選んでマージする機能である。自分が欲しい程よいコミットがなかったらコミットを分割したりして何しかコミット単位でマージするように心がける。そうすることでGitの強力なマージ機能を未来永劫使えるようになるのだ。 実際のところ とはいえ、どうしてもそんな諸々を無視してファイル単位でマージしたい時は以下のようにする。 git checkout branch file... 入門Git作者: 濱野純(Junio C Hamano)出版社/メーカー: 秀和システム発売日: 2009/09/19メディア: 単行本購入: 28人 クリック: 6
PDOの真の力を開放する - PHPでデータベースを扱う(3)
ちょっと遅れましたが、シリーズの第３回です。前回までに論じた内容をふまえて、簡単な実装を示します。↓前回までの内容はこちら。 DAOの悪夢 - PHPでデータベースを扱う(1) - 泥のように ドメイン駆動設計という救世主 - PHPでデータベースを扱う(2) - 泥のように 題材 「記事にタグを設定できるブログ」みたいなシステムを考えてみます。ブログ記事を示すEntryテーブル、タグを表すTagテーブルの二つを用意しました。MySQL WorkbenchによるER図(鳥足記法)は以下になります。 1つのEntryに対して複数のTagがある、１対多の関係です。同じTagが複数のEntryに関連するため、多対多の関係と見なすこともできそうですが、タグ程度だとあまり意味がないので、これ以上のテーブル分割はやめておきます。 Entryテーブルの主キーがentryIdと冗長な名前をしているのは、自
それでもPHPにfinallyが必要な理由
PHP Conference 2012で知ったのですが、PHP5.5にはfinallyが搭載される見込みだそうです。 搭載されるのはいいのですが、昔、「PHPにfinallyはないけどデストラクタがあるよ」と題してfinally不要説を書いたことがあるので、もう少し考察を行ってみたいと思います。自分で自分に反論を書いてるのもアレなんですけど。 ※RFCは追いかけてなかったので、本記事は想像で書いています。ツッコミください。 finally不要説 私が主張した内容を要約するとこんな感じです。 finallyの主な用途はファイルのクローズやDBの接続断などの「後始末処理」である。 後始末はデストラクタで行うこともできる。 PHPではデストラクタの動作が保障されている。（参照カウントによるGC） ゆえにデストラクタを正しく使えばfinallyは不要。 具体例を出すと、finallyのRFCでは例
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Major Hayden