パイプラインとサブシェルの問題はシェル依存 - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog
パイプラインとサブシェルの問題はシェル依存 - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog 拡張 POSIX シェルスクリプト Advent Calendar 2013、10日目の記事です。 そろそろネタが尽きそうです。 スクリプトの添削依頼や疑問・質問、やって欲しいネタをお待ちしております。 記事に反映できるかどうかは内容や私の実力次第ですが…。 今日はコマンドパイプラインを実行したときの変数のスコープの問題について紹介します。 「あー、パイプラインとサブシェルの問題だね。知っているよ!」という方も、 最後までお付き合いいただけると新しい発見があるかもしれません。 まずシェルスクリプトのお題として 「メンバー情報が空でないグループの数とグループ名の一覧をカンマ区切りで表示するスクリプトの作成」 を考えてみます。 実装のポイントは次
echo コマンドの違いと移植性の問題 - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog
echo コマンドの違いと移植性の問題 - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog 拡張 POSIX シェルスクリプト Advent Calendar 2013、8日目の記事です。 今日はシェルや OS ごとに微妙に異なる echo コマンドの違いを紹介します。 echo コマンドの挙動は大きく分けて 2種類あります。 BSD 系 echo コマンドの挙動 引数に指定された文字列をそのまま出力します。 複数の文字列が指定された場合はスペース (0x20) 一文字で区切られます。 最後に改行を出力しますが、最初の引数が -n のときはオプションとして認識し、 最後の改行を出力しません。 $ echo foo foo $ echo foo bar foo bar $ echo 'foo\nbar' foo\nbar $ echo f
なるべく書かないawkの使い方 - ザリガニが見ていた...。
awkという、古くからのスクリプト言語がある。（1977年生まれ。読み方は「オーク」である。エイ・ダブリュ・ケイではない）man awkをPDFに変換してみると、たったの3ページ強しかない。 $ man -t awk|pstopdf -i -o ~/Downloads/awk.pdf とてもシンプルな言語仕様ではあるが、awkには必要十分な表現力がある。特にテキストを処理する場面においては、最小限のシンプルな記述で、気の利いた処理を素早くこなす。無駄のないawkワンライナーを見ると、ある種の感動を覚える。awk以降に生まれたスクリプト言語は、少なからずawkの影響を受けていると思われる。 awkを知ることで、間違いなく幸福度は上がると思う。いつかきっと「知ってて良かった」と思える時が来るはず。もっともっと、awkを知りたくなってきた。 基本動作 awkの基本動作は、とってもシンプルである。
安全な一時ファイルの作成と削除の方法 - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog
拡張 POSIX シェルスクリプト Advent Calendar 2013、6日目の記事です。 本日のお題は「一時ファイルの作成と削除」ですが、 よくあるシェルスクリプトのダメ出しネタになってしまいました。 安全な一時ファイルの作成方法 たとえば、こんな感じのありがち(?)なスクリプトがあったとします。 意味のない処理内容ですが、雰囲気だけ察してください。 #!/bin/bash tmpfile=/tmp/words.tmp rm -f $tmpfile echo 'しにたい' >>$tmpfile echo 'とりあえずねよう' >>$tmpfile sleep 3 echo -n '今どんな気持ち? ' read feeling echo $feeling >>$tmpfile cat $tmpfile rm $tmpfile 全然駄目ですね。 もし「何にも問題ないじゃないか!」とい
スクリプト終了イベントの捕捉と zsh の非互換性 - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog
スクリプト終了イベントの捕捉と zsh の非互換性 - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog 拡張 POSIX シェルスクリプト Advent Calendar 2013、5日目の記事です。 書いているうちにネタが変わってしまいました。 trap というシェル組込みコマンドをご存じですか? シグナルを受信したときに実行する処理 (シグナルハンドラー) を設定するものです。 例えば SIGINT シグナル※を受信するとデフォルトではスクリプトが終了しますが、 trap で捕まえてやると終了せずに継続することも可能です。 (※割り込み (INTerrupt)。 端末から実行したシェルスクリプトなら Ctrl+c で送信可) $ sh -c 'trap "echo Boo!" INT; while :; do read i && e
シェルの種類とバージョンの検出 - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog
拡張 POSIX シェルスクリプト Advent Calendar 2013、4日目の記事です。 毎日何時間も執筆に時間をとられて大変です。書くの遅いんです。 今日は軽めに、予定を変更してお届けします。 スクリプトがどのシェルインタープリターで動いているかを判定したいときってありませんか? 私はあります。ポータブルなシェルスクリプトを書きたい、 しかし、互換性の問題などでシェルの種類に依存するコードを書き分けないといけない場合です。 ざっくりとシェルの種類、バージョン、 動作モードを判定するスクリプトを作ってみました: sh-detect-name-ver-mode.sh bash は $BASH_VERSION、zsh は $ZSH_VERSION というシェル変数にバージョン文字列が入るため、これで種類の判定ができます。 ちなみに $VAR でなく ${VAR-} としているのは、 s
バイナリーデータの扱い方 - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog
http://blog.ueda.asia/?p=1549 「ほう…」と思い覗いてみたのですが、「『シェル芸』か?」という内容でした。 ふつうに外部のイメージ処理コマンド使っているじゃん! まあ、いいんですけどね。 人には言わない心の叫びです。気にしないでください。 外部コマンドとの華麗なコラボもシェルスクリプトの醍醐味の一つです。 後日、私と同じ感想を持った人がいて、それを受けて blog 記事が追加されました。 http://blog.ueda.asia/?p=1616 なるほどー。sed とか awk とか便利だよねー…って、これも「シェル芸」と言えるだろうか? 「芸」というと、もうちょっと、なんというか、その、あれ。 まあ、いいんですけどね。シェルももっと頑張れるんだー…っていうか、ね。 …というわけで、元ネタである 「JPEG ファイルから EXIF 等のアプリケーション付加情報
bash, ksh, zsh の速度比較 - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog
bash, ksh, zsh の速度比較 - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog 拡張 POSIX シェルスクリプト Advent Calendar 2013、 1日目の記事です。 「このくらいの要件ならシェルで書ける!」と意気込んで実装を開始して、 たとえやりきっても「あー、やっぱり (あなたの好きな LL) で書けばよかった」 なんてことありませんか? 私はあまりありません。 POSIX シェルやそれ以前の非力なシェルはともかく、bash や ksh、zsh のような拡張 POSIX シェルであれば、少し無理をすれば、大抵の処理は書けます。 老害ですね、わかります。 しかし実装は問題ないのですが、速度がいまひとつなのはどうしても否めません。 そこで一つ、少しでも実行速度を改善する簡単な方法を伝授しましょう。 それは「ba
このタイミングでシェルスクリプトの基本を学ぶ
よーしお前ら、今日はシェルスクリプトを勉強するぞ。シェルの種類はbashだ。ただ、他のシェルでも基本は同じなので安心してくれ。 シェルスクリプトと言っても、findの使い方とかglob展開とかそういう細かいTIPSはやらん。そういうのは他の記事でも読んでくれ。そうじゃなくて、基本的な処理の流れ、考え方の勉強だ。 だいたいシェルスクリプトなんて普段大してやってなくて、いざ必要になったときに「まあPerlやRubyみたいなもんだろ」とか軽く考えてたらしょーもないことでハマって時間を無駄にしたりするもんだ。 なんでそんなことが起きるのか。 それはシェルスクリプトの基本的な発想が分かってないからだ。PerlやRubyのような普通に使われてるプログラム言語とシェルスクリプトの書き方はけっこう違うところがあって、それを理解せずに書いてしまってるからだ。 そもそもシェルとは何かもう一度思い出してみろ。
Rubyでシェルもどきを作る - tmtms のメモ
Ruby でシェルのようなものを作ってみると、Ruby とシェルやシステムコールの理解ができて、研修の課題とかにいいんじゃないかと10年くらい前に思ってたのを、ふと思い出したので書いてみます。 基本 シェルの動作を簡単に説明すると次のような感じです。 プロンプトを出力 標準入力からコマンドラインを読み込む 読み込んだコマンドを実行する コマンドの終了を待つ 1 に戻る これをそのまま Ruby で書いてみます。 while true print '-> ' # プロンプト表示 cmd = gets or break # コマンド入力 cmd.chomp! # 末尾の改行削除 pid = Process.fork do # 子プロセス生成 Process.exec [cmd, cmd] # コマンド実行 end Process.waitall # 子プロセスの終了待ち end Process
シェルスクリプトを書くときに気をつける9箇条 - Qiita
最新の類似投稿としてシェルスクリプトのコーディングルール2014も併せてどうぞ。 2014/10/09追記 ぼくがシェルスクリプトを書くときに気にしていること、過去の失敗で書き留めたことを忘れないために。 1. グローバル変数は大文字 PATH や HOME など、環境変数が大文字なので、エクスポートする変数を大文字で書くという習慣は一般的であるような気がしますが、エクスポートする変数を抱えるシェルスクリプトを作成する機会が稀なので。 グローバル変数は大文字 ローカル変数は小文字 エクスポートする変数も大文字 関数内からグローバル変数にアクセスする場合がありますが、やはり区別していると、可読性が増すような気がするのでお勧めです。 2. awk を知る Unix 上にて文書処理をするときに、数多くのフィルタコマンド（grep、cut、tr、head、sort、uniq、sed、awk、wc、
僕がMacのホームディレクトリを削除するに至った経緯と、復元するまでの道のり | CreativeStyle
最初に結論から申し上げますと、僕 @kadoppe はアホです。大馬鹿者です。 この度、仕事にフル活用しているMacBook Proのホームディレクトリ（/Users/＜ユーザ名＞)を削除するという愚行を働いてしまいました。 具体的に何をしたのか。それは、以下のコマンドの実行です。 コマンドにあまり詳しくない人のために説明すると、この短いコマンドをターミナルを開いて実行するだけで、有無を言わさずホームディレクトリの削除が開始されてしまう、恐怖のコマンドです。良い子は危険だから真似しちゃダメだよ！ ではここからは、僕は何故こんなことをしてしまったのか、その経緯を言い訳がましく説明したいと思います。恥ずかしいですが、二度とこんなことを繰り返さないようにするために。 「~」という名前のディレクトリ 通常「~」（チルダ）という記号はホームディレクトリを表します。~/はMacだと実際には/Users
xargs -P が激しく便利なのでメモ - おともだちティータイム
xargs の -P オプションを使うとプロセスを複数起動して処理を並列に行なうことが出来る。 例 例えば、 1 万枚の JPEG 画像を全て 800x800 に収まるように効率良くリサイズしたい。 まず私はこのようなコマンドを考えた。 convert --geometry 800x800 *.jpg しかし zsh に怒られた。 zsh: argument list too long: convert 引数が全て展開されるためこのような事が起きる。 私は xargs を使って処理することを思い付いた。 ls | xargs -I{} convert --geometry 800x800 {} c_{} 処理は行なわれるが非常に遅い。 しかも CPU を全く使っていないことが分かり、私は処理を並列的に行なう事を考えた。 そこで xargs の -P オプションの出番である。 P の後に並列
シェルスクリプトで「ビルドスクリプト」を作る時に便利なテクニック - ククログ(2012-10-11)
プログラムの種類によっては、そのまま実行できるものと、実行できるようにするために「ビルド」が必要なものとがあります。Cなどのコンパイルが必要な言語で書かれたプログラムは当然ビルドが必要ですし、コンパイルが不要な言語であっても、インストーラパッケージを作るというビルド作業が必要な場合はあります。 ビルド作業の自動化のためのツールとしてmakeなどがありますが、そこまで本格的な事をやる必要がない場合は、シェルスクリプトで「ビルドスクリプト」を作るのが手軽でおすすめです。この記事では、そのような場合に役立つシェルスクリプトのテクニックを4つご紹介します。 エラーの気付きやすさとデバッグのしやすさを高める メッセージに色を付ける シェル関数をライブラリにする 一時的に作業ディレクトリの中に入る エラーの気付きやすさとデバッグのしやすさを高める はじめに紹介するテクニックは問題が発生した時に気づきや
shell script を書くときの tips 2つ(初心者向け) - tokuhirom's blog
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 文の一部である、 && または || リストの一部である、 コマンドの返り値が ! で反転されてい
リダイレクトとパイプを図示してみた (3) - とあるソフトウェア開発者のブログ
前々回、前回の続きです。今回は、様々なリダイレクトやパイプを組み合わせた複雑なケースを説明します。 前回: id:simply-k:20100801:1280617927 補足: id:simply-k:20100803:1280796958 (11) コマンドA 2>&1 | コマンドB リダイレクトとパイプを組み合わせたケースです。2段階に分割して考えます。 (11-1) 「コマンドA 2>&1」、「コマンドB」 パイプの前後のコマンドを単独実行する場合です。「コマンドA 2>&1」では、コマンドAの標準エラー出力を、標準出力にリダイレクトします。このため、コマンドAの標準出力のデータと標準エラー出力のデータは、まとめて標準出力(stdout-a)に出力されます。「コマンドB」は、リダイレクトの無い、通常のコマンド実行です。 (11-2) コマンドA 2>&1 | コマンドB 「コマン
cron で > /dev/null して椅子を投げられないための3つの方法 - 酒日記 はてな支店
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ！出力を /dev/null に捨てるなんてとんでもないよね！」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
>/dev/null 2>&1は「奥が深い症候群」なのか？ (追記あり) · DQNEO日記
ひとつには、前者は「素人くさい、なんかダサイ」、後者は「ハッカーぽい、かっこいい」というのがあると思います。 よくWebで見かけるのが、後者を書こうとして間違えて、「リダイレクトに関する理解が間違っていた」「シェルの仕様を勘違いしていた」といって自分を責めてしまうケースです。 我々エンジニアは真面目な人が多いので、間違えると自分を責めてしまいがちです。 しかし開き直ってみれば、間違いを誘発する記法に問題があるとは言えないでしょうか。 私はこれは「奥が深い症候群」と言えるのではないかと思いました。 バッドノウハウがはびこる大きな理由は、(中略) 別の理由によ るものも根深いと私は考えている。それは、そういった使いにくい ソフトウェアを使いこなす事に対して、「奥が深い」といって喜び を見出す「奥が深い症候群」によるものである。 一般に、マニアという人種は普通の人にとってはどうでもいいよう な知
いい加減、>/dev/null 2>&1と書くのをやめたらどうか (追記あり) · DQNEO日記
はじめに これから書く内容は、シェルスクリプトをばりばり書いている現場(サーバエンジニア・インフラエンジニア)向けのものではありません。 年に数回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 これをぱっと見て
[ヅ] シェルスクリプトに引数を渡す $1 $2 $# $* (2011-07-05)
これを解決するため、シェルスクリプトに引数を渡すことができます。引数は、シェルスクリプトからは順番に$1、$2、$3、……として参照できます。引数の数は「$#」で分かります。また、「$*」とすることで、すべての引数を一度に参照できます。なお、「$0」はスクリプトが呼び出されたときの名前が入ります。 bashで始めるシェルスクリプト基礎の基礎（1/2） 試してみる。引数が無いときでもエラーにはならない。 $ uname -mrsv Linux 2.6.26-2-amd64 #1 SMP Tue Jan 25 05:59:43 UTC 2011 x86_64 $ cat ./ds.sh #!/bin/sh echo $1 echo $2 echo $# echo $* $ sh ./ds.sh 0 $ sh ./ds.sh a b c a b 3 a b c tags: shell_scrip
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
