Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
目的 "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:/
「#!」[1]や「ハッシュバン」はこの項目へ転送されています。URLに使われるものについては「URIフラグメント#hash-bang(英語版)」をご覧ください。 シバンまたはシェバン (英: shebang) とはスクリプトの#!から始まる1行目のこと。起動してスクリプトを読み込むインタプリタを指定する。 シェバンやシバンと呼ばれるようになった理由については諸説あるが、一般的には、そこに書かれる2文字が「#」(ハッシュ、番号記号)と「!」(bang! バン (びっくりマーク)だから、ハッシュ・バン(hash bang)やシャープ・バン(sharp bang)と呼ばれるようになり、それを短く言う際に訛ってシェバンとなった、と説明されている。あるいは、もはもともとは主にシェルを起動していたからシェル・バン(shell bang)と呼ばれ、それが訛ったと説明されることもある。いずれにせよ現在では
ASCII Booksのサイトをご利用いただき、ありがとうございます。 2016年12月6日をもちまして、サイトを閉鎖させていただくことになりました。 今までサイトをご利用いただき、ありがとうございました。 アスキー・メディアワークスを引き続き、よろしくお願いいたします。
Glamenv-Septzen(ぐらめぬ・ぜぷつぇん)(archive) 技術/UNIX/なぜnohupをバックグランドジョブとして起動するのが定番なのか?(擬似端末, Pseudo Terminal, SIGHUP他) [ Prev ] [ Next ] [ 技術 ] 何をいまさら当たり前の事を・・・と思われるだろう。 $ nohup long_run_batch.sh & SSHからログアウト後も実行を続けたいバッチジョブを、"&"を付けてバックグラウンドジョブとしてnohupから起動するのは定番中の定番である。 しかし、「nohupを使わなくても実行を続けることが出来る」やり方があったり、さらには「nohupを付けてもログアウト時に終了してしまう」パターンがあるとしたらどうだろう? そして、ある日あなたの後輩や同僚がこれらについてあなたに質問してきたら、あなたはどう答えるだろうか?
1 Mar 1999 NAMErsync - rcp よりも速くて、柔軟性に富んでいます SYNOPSIS rsync [OPTION]... SRC [SRC]... [USER@]HOST:DEST rsync [OPTION]... [USER@]HOST:SRC DEST rsync [OPTION]... SRC [SRC]... DEST rsync [OPTION]... [USER@]HOST::SRC [DEST] rsync [OPTION]... SRC [SRC]... [USER@]HOST::DEST rsync [OPTION]... rsync://[USER@]HOST[:PORT]/SRC [DEST] 説明 rsync は rcp とほとんど同じ方法で動くプログラムですが、より多くの オプションを持っています。目的のファイルが既に存在する場合に、 rs
We’re getting things ready Loading your experience… This won’t take long.
shell script を書くときの tips 2つ(初心者向け) 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 文の一部である、 &
世界最強のshellと名高いzshの最新版「zsh 5.0.0」がリリースされました(zsh MLのアナウンス)。 Sourceforgeにアップロードされるまでに試したい場合ftp.zsh.orgからダウンロード可能。 ftp://ftp.zsh.org/pub/zsh-5.0.0.tar.gz ftp://ftp.zsh.org/pub/zsh-5.0.0.tar.bz2 ftp://ftp.zsh.org/pub/zsh-5.0.0-doc.tar.gz ftp://ftp.zsh.org/pub/zsh-5.0.0-doc.tar.bz2 以前のバージョンからの変更点はNEWSの中の「Changes between 4.2 and 5.0」を参照してください。
はじめに これから書く内容は、シェルスクリプトをばりばり書いている現場(サーバエンジニア・インフラエンジニア)向けのものではありません。 年に数回crontabをいじるような現場(サーバに詳しくないアプリケーションプログラマが多数を占めるような現場とか、Webデザイナや非プログラマがcrontabをおそるおそるいじったりするような現場)を想定しています。 >/dev/null 2>&1 の問題点 この記法の問題点は、「覚えにくい、間違えやすい、間違ってても気づかない」ということです。 初心者を迷わせる要素がこんなにあります。 >/dev/nullは先か後か 1と2はどちらが先か &はどこに書くのか よって下記のように多種多様なミスが起こり得ます。 2>&1 >/dev/null >/dev/null 1>&2 >/dev/null 2>1& >/dev/null &2>1 これをぱっと見て
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
今回から、OS付属のシェルスクリプトを読んでいく。多くの人が使っているスクリプトを読むことで、シェルスクリプトならではの書き方、テクニックを身に付けることができるはずだ(編集部) 他人の技術を盗まなければ進歩はない 外国語をマスターするにも、楽器の演奏を覚えるにも、上達するにはただ練習するだけではダメだ。素晴らしいお手本を見つけて、よく観察し、何度もまねることが必要だ。お手本から技術を「盗む」ことが大切だということだ。 プログラミングでも同じことが言えると思う。文法を覚えて、ただひたすらプログラムを書くだけではなかなか上手にならない。スキルのある人のコードを見て、技術を盗もう。開発チームのメンバーそれぞれが書いたコードを持ち寄って、お互いに批評し合う「コードレビュー」に参加している、あるいはリーダーとして主催しているという人は多いと思う。このコードレビューも、人から技術を盗む良い機会と言え
/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などは、高速に動作する
zsh は zcompile コマンドにより中間バイトコードをあらかじめ生成し起動の高速化を図ることができる。だが一人で複数ユーザーを利用したりしていると、いちいち各ユーザーごとに zcompile するのがダルイし、どうせなら /etc/zsh あたりに共通のファイルを置きたい。また、ちょっとしたコード片を追加するときに plugins ディレクトリに放り込んでそのまま拡張できる仕組みが欲しい。 .zshrc を編集してもいいのだが、変更部分だけ独立していたほうが管理も楽になるだろう。このあたりの問題解決を目的としている。 目的 中間バイトコードをシェアして zsh の起動を高速化する。 プラガブルに .zshrc を拡張できる。 (コード片を plugins ディレクトリに放り込めば即反映) インストール先を指定できる。 (sudo が使えても使えなくても OK) ソースコード htt
シェルからでも重い処理というのはちょこちょこあって、例えば超デカいログファイルを移動して圧縮したりというお仕事は世界中のあらゆる場所で毎日行われていたりする。コマンドラインからでも大量の圧縮済みログファイルをいっぺんに展開したい、とか。 あるディレクトリ以下に存在するたくさんのファイルを(圧縮済みのものを除いて)全部 bzip2 圧縮したい!と思ったら、とりあえずさくっと次のようにコマンドラインで叩けばいい。 $ find . -not -name '*.bz2' | xargs bzip2 これで、まあそんなに問題なく効率的にbzip2圧縮ができる。だがしかし。 最近は複数コアのCPUが普通に転がってるし、あまつさえHyperThreadingが有効になってたりしてOSから見える論理CPU数がハンパない。普通に8とかある。その一方で複数コアを使用してくれるコマンドというのはあんまりなくて
Debian システム上でプログラミングを学ぶ人がパッケージ化されたソースコードを読み込めるようになるための指針を示します。以下はプログラムに関する特記すべきパッケージと対応する文書パッケージです。 オンラインリファレンスは manpages と manpages-dev パッケージをインストールした後で "man name" とタイプすると利用可能です。GNU ツールのオンラインリファレンスは該当する文書パッケージをインストールした後で "info program_name" とタイプすると使えます。一部の GFDL 文書は DFSG に準拠していないと考えられているので main アーカイブに加えて contrib や non-free アーカイブを含める必要があるかもしれません。 バージョン コントロール システム ツールの使用を考えましょう。「Git」を参照下さい。
zshはシェルである。シェルはもちろんキーボード入力されたコマンド行を解釈し、必要なコマンドを必要な引数とともに起動することを主な仕事とするソフトウェアである。単なるシェルなのだが、zshには他を圧到する比類なき機能がある。その一端を印象づける一つの例に、zshで実装されたテトリスがある(図1)。 もちろんこれは、お遊び機能の例で実際の日常作業をこれで進めるわけではないが、潜在的に備えている機能がどれほどのものかが分かる好例である。 zshは、sh(Bourne Shell)をベースとし、ksh、csh(tcsh)、bashの優れた機能をアイデアとして取り込み、なおかつ作業効率を高める独自の機能を登載したまさに至高のシェルである。しかしながら超高機能・多機能であるがゆえに全容を掴むのが難しい。付属の英文マニュアルはしっかりしているものの、簡潔な仕様記述がされているのみなので具体的な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く