東京Node学園17時限目のLT資料
watchコマンドといえば、そこまで使用頻度が高いわけではないけれど、覚えてるとちょっとした時に便利なコマンド。 今回は、そんなwatchコマンドで覚えておくと役に立つ使い方について紹介する。 1.基本的な使い方 基本的には、以下のようにコマンドを実行することで、数秒ごと(デフォルトは2秒)にそのコマンドの実行結果をコンソール上に出力することができる。 watch 連続実行させるコマンド 例えば、以下のように実行することで数秒ごとに「ls -la /home」を実行する。 当然、その配下のファイルが作成されれば確認することができる。 watch ls -la /home/ 特定のプロセスが上がってくるかどうか確認するなら、「ps -ef | grep プロセス名」で監視することも出来る。 例えば、httpdの状態を監視するなら以下のようにコマンドを実行する。 watch "ps -ef |
これはだいぶ前に書いたエントリです。MINCS作者による最新の解説があるのでそちらもご覧ください。 (2016-11-21追記) コンテナは使いたいけど、たくさんコンテナを起動すると結局それぞれのコンテナに対するセキュリティアップデートなどのメンテナンスは必要だし、コンテナ内独自のプログラムやライブラリ以外はホストと共有したいよね、って話が出てきたりします。みんな考えることは同じで、bind mount を使えば良いよね、って話はでてきてました。 こないだもブログで紹介した kazuho さんの jailing 私が LXC でも結構簡単にできるよ、っていう提案を兼ねて作った lxc-bind こないだのLinuxConでもDockerでたくさんのオプションを並べて、色々工夫して bind mount を使ってやってる発表もありました (Using Docker for existing
$ top # CPU使用率順にソート $ top -a # メモリ使用率順にソート $ top -p [PID] # 特定のプロセスを監視 $ top -d1 # 1秒ごとに更新 操作方法 Shift+o: 表示された特定のキーを押してEnterすると任意の列でソートできる Shift+p: CPU使用率順にソート Shift+m: メモリ使用率順にソート ヘッダーの見方 load average top - 08:42:47 up 2min, 2 users, load average: 2.76, 0.76, 0.27 # 現在時間 サーバーの ログイン 1分 5分 15分 # 稼働時間 ユーザー数 間の単位時間あたりの待ちタスク数
モチベーション 一定の品質を保ちたい 書くたびに書き方が変わるのは好ましくない シェバング(shebang)は#!/bin/shではなく#!/bin/bashにする シバン、シェバンとも言われる #!/bin/shは実行環境によって様々なシェルにシンボリックリンクになっているので、bashなら#!/bin/bashと明示しよう インデントは半角スペース2つ 1行が横に長くなり折り返されないように 処理内容および使い方をスクリプト内に記載する(usage()) 何をしてくれるスクリプトか、どのように使うのかusage()関数を用意しよう ヘッダコメントでもいいけど function usage() { cat <<_EOT_ Usage: $0 [-a] [-b] [-f filename] arg1 ... Description: hogehogehoge Options: -a aaa
私は多くの時間をターミナルの前で過ごしていて、そのほとんどをGitコマンドのタイピングに費やしています。ワークフローを高速化して、毎日何百というキーストロークを節約するために、Bashのエイリアスと関数を使って1組のコマンドラインショートカットを作りました。 Git Bashエイリアスと関数 Gitではエイリアスを設定できますが限定的であり、節約できるキーストロークは、ほんの数ストロークです(例えば、”git checkout”の代わりに”git co”とタイプすることはできますが、まだ”git”とタイプしなければなりません)。Bashはターミナルのデフォルトのコマンドラインインタープリタなので、Bashエイリアスを設定して、さらにキーストロークを減らすこともできます。 これが、私のGit Bashエイリアスと関数のリストです。ご自分のエイリアスや関数の保存先ファイル(例えば、~/.bas
背景 Zsh の醍醐味のひとつが補完機能であるのは言わずもがなですね。 この補完について、基本的なコマンドや有名プロジェクトのコマンドなどの多くは提供されているのですが、自作コマンドもちろんのこと、マイナーなコマンドは提供されていなかったりします。 その場合、ユーザが Zsh スクリプトの記法で補完ファイルを記述しなければなりません。これが結構骨の折れる作業で、Zsh が提供する補完インターフェースは高機能ゆえに複雑怪奇で、並みのユーザはおろか熟練のシェルスクリプターでも投げ出したくなる様です。 特に自作コマンドの場合、コマンドの作成で疲弊して、マニュアルやドキュメンテーションの作成でも疲弊しているところにこの作業となると、まず補完は諦めがちです。 b4b4r07/zgencomp · GitHub DEMO: そこでこのツールを使います。コマンドのUIについて簡単な JSON ファイルを
先日とあるサイトで知った、UNIX系OS で動く screen なるツール。kterm とか teraterm 等の端末1つで、複数端末での作業をエミュレートするとかなんとか・・・って使ってみてびっくり、これすげー便利!乱暴に言えばタブブラウザの terminal 版って感じでしょうか。ざーっと man を読んだ上で、幾つか web からも知識を仕入れたのでここにメモっておきます(いうても使いそうな基礎操作のみ)。 screen の魅力 複数の(仮想)端末を同時に開いて作業する事ができる 仮想端末が開かれた状態を保ったまま端末ログアウト 〜 後日ログイン後、screen を呼び出す事によって前回の状態を復帰させることができる(回線が強制切断しちゃった際も復帰可能) 1端末の画面を上下 n 分割させる事ができる 2人で同じ screen プロセスに接続する事で shell の同時操作ができる
よく訓練されたアップル信者、都元です。最近社内のメンバーがみんなGo言語の世界で楽しそうなので、私も混ざってみることにしました。最初のセットアップや基礎文法等は、私も平行して急いで学ぶGo langシリーズで勉強中です。 コマンドラインツールが作りたい と思っています。ちょっとしたものを作るとしたらPythonなのかな、と思って友達のPythonistaにインタビューをしたところ、「ちょっとしたツール作るとかって用途の人は Golangに移行した(えっ」という衝撃的なコメントを貰い、もうこの際だからGo勉強すっかという空気になった次第。 具体的な環境構築 基本的には急いで学ぶGo langシリーズを読めばいいのですが、一点迷ったのがディレクトリ構成です。 Go言語で幸せになれる10のテクニックでは「GOPATHは一つだけ (Use a single GOPATH)」という指針が紹介されてい
ここ最近、沢山シェルスクリプトを書くようになりました。 元々あまりシェルスクリプトを書いたこと無かったので、色々と勉強しつつ書いてるのですが、 他のプログラミング言語とはちょっと違って独特なクセというか、発見の度におぉー!ってなることが沢山あって楽しいです。 そんなわけで、最近学んだり参考にした中で特に感動したシェルの上手い書き方をまとめてみます。 きっとまだ知らないこととかもっと上手くやる方法なんかが沢山見つかりそうなので、 もっといいやり方あるよ!って方はコメントください 何もしない : (コロン)コマンド シェルを書いていた時に非常に欲しかったコマンドがこれ!何もしない! : というコマンド(?)を利用すると、何もせずに終了ステータス0(つまり正常終了)を返します。 これが様々な事に使える万能コマンドで、これによって面倒なエラー処理を簡潔にできたり、 入力や出力のリダイレクト元/先と
気づいたら自宅でもオフィスでもすっかりWindowsユーザーになっちゃって、Win10情報にも一喜一憂してるという、完璧なる転びマカーぶりを発揮してるドリキンです。 基本的にWinである不便もほとんどなくなってしまった(というかむしろ快適に感じる)今日この頃なんですが、唯一にして最大とも言えるWindowsの弱点はいうまでもなくまともなターミナルコンソールがないことですよね? とはいえ、最近はコンソールではNodeJSだけが動けばいいやという状態だったので、コマンドプロンプトでごまかしたりはしてたんですが、流石にコマンド履歴どころかコピペすらまともに出来ないのはどうかなと一念発起してWindowsでZshくらいは使えないかなとググってみたらよさげなモノを発見! Babun | A windows shell you will love! それがBabunというWindows用のターミナルア
シェルスクリプトの中で、スペース区切りもしくはタブ区切りのレコードを扱うことがよくあると思います。 たとえば、前回のエントリ「AWS CLIとjqを使って、AWSのELBボリュームがアタッチされているEC2インスタンス名を出力するワンライナーを書いた - 双六工場日誌」のスクリプトの出力は以下のようになります。 i-ec56a9f5 vol-07d00601 servername i-ec56a9f5 vol-8f550991 servername このようなレコードの特定の列を取り出して、処理する際にどうするのが効率的か、というのがこのエントリのお題です。 非常に古い話題なので、昔からシェルスクリプトを書いている人には自明な話ではありますが、最近、シェルの標準機能の話を聞く機会がなく、失われつつある技術になってきている気がしているので、改めて確認ということで。 例として挙げたレコードから
git-ignore add みたいのが欲しい— azu (@azu_re) August 24, 2014 ちょろっと書けそうだったので書いた。 yuroyoro/git-ignore · GitHub Demo Installation PATH通った場所においてくれ curl -sL https://raw.githubusercontent.com/yuroyoro/git-ignore/master/git-ignore > ~/bin/git-ignore Examples `git ignore add "pattern"`で、.gitignoreへ追加する。 $ git ignore add '*.log' .gitignoreから削除するには、`git ignore remove "pattern"`を実行する。 $ git ignore remove '*.log' a
シェルスクリプト入門として, 基本的な書き方をまとめました. 長いですが, 1ページにまとめてみました. 良かったら目次も参考にしてご覧になって下さい. 目次 シェルスクリプトとは 作り方, 実行の仕方 コメント ユーザーからのキーボード入力を受け付ける 変数 通常の変数 特別な変数 演算子 数値計算演算子 比較演算子 コマンドを繋げる演算子 条件文に使える比較演算子 条件文 制御構文(分岐) if文 case文 制御構文(ループ) for文 while文 until文 select文 文字列処理 文字列置換 削除 複数行のテキストの出力(ヒアドキュメント) 関数 シェルスクリプトとは シェルスクリプトとは, シェルの動作をまとめて記述したスクリプトのことです. 決められた文法にしたがって処理を記述することによって, シェルでの処理をまとめて行ったり, 作業を自動化できたりします(例 複数
In the introduction, we showed you how to create a Vagrant base box, installing the latest Ubuntu 14.04 LTS in the virtual machine to use it as the guest operating system. In this part you will learn how to setup a development environment using Vagrant, which you can use and reuse in your development. Note that while you can use the box we created in the previous part for the remainder of this pos
oh-my-zsh の環境で、peco-select-history が動かない - Qiita 追記 2014年 7月 7日 シェルスクリプトと書いてしまい漠然すぎましたが, ここで述べている ことが問題になるのは, .bashrc, .zshrcに関数, alias設定等がコピー される場合や, sourceコマンドでファイルを読み込む場合です. non-interactiveに実行されるシェルスクリプトについては特に 問題ないです. 問題点 そうしないと, 公開されたコマンドを自分の環境に導入した場合, aliasにより正しく動かなく場合があるためです. aliasをつけがちな コマンド(ls, grep等)がシェルスクリプトに含まれていると 特に問題が起こる可能性が高くなります. 例 pecoを使って カレントディレクトリのファイルをページャで開く 例を考えてみましょう. 単純に考
橘玲の『「読まなくてもいい本」の読書案内』を読んだので、感想とメモをまとめておく。 この本、タイトルは『「読まなくてもいい本」の読書案内』だが、実際には「読まなくていい本」はほとんど紹介されていない。紹介されているのは、当たり前の話かもしれないが読むべき本だ。他の読書案内本と異なっているのは、”こういう本は読まなくて良い”と、ばっさり切り捨てているところ。読むべきか・読まなくてもよいかの基準は、20世紀後半に爆発的に進歩した科学研究の成果に置いている。著者は、この時期に起きた科学研究の大幅な進歩を”知のビッグバン”、”知のパラダイム転換”と呼び、これ以前に書かれた本は(とりあえず)読む必要がないと言い切る。古いパラダイムで書かれた本は捨てて、新しいパラダイムで書かれた本を読もうという話だ。ちょっと乱暴な分け方ではあるが、1980年代に大学生だった私には案外納得できるものだった。学生時代に最
ASCII Booksのサイトをご利用いただき、ありがとうございます。 2016年12月6日をもちまして、サイトを閉鎖させていただくことになりました。 今までサイトをご利用いただき、ありがとうございました。 アスキー・メディアワークスを引き続き、よろしくお願いいたします。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く