UNIX Shell Quote
Last modified: Fri Nov 27 09:44:59 2020 Written by Bruce Barnett Table of Contents Using the echo command Quoting a single character with the backslash Strong Quoting with the Single Quotes Weak Quotes with the Double Quotes Using quotes to include spaces and characters in filenames Quotes within Quotes Finding out if your quotes are wrong The verbose and echo variables in the C shell The Bourne S
入門 シェル実装
開発者にとってシェルが必要不可欠なものであることは論を俟ちませんが、当たり前の存在すぎてこれがどのように実現されているのかを知る機会はあまりないと思います。本トークでは、シェルがどのように実現されているのかを、実際にシェルを実装する過程を通じてお話しします。 ※ もともとのトークのタイトルは「入門 シェル」でしたが，わかりやすさのため「入門 シェル実装」にタイトルを変更しています．Read less
bash の危険な算術式 - どさにっき
■ bash の危険な算術式 _ 使ってる人がいちばん多いだろうからタイトルでは bash としてるけど、ここで取り上げることは zsh および ksh 一族(本家 ksh、pdksh、mksh)にも該当する。ash、dash などでは該当しない。 _ 以下のシェルスクリプトには脆弱性がある。わかるだろうか。 #!/bin/bash # "品目,単価,個数" の形式の CSV を読んで、"品目,合計金額" の形式で出力する csv="foo.csv" while IFS=, read item price num; do echo "$item,$((price*num))" done < "$csv" これ、細工された CSV ファイルを食わせることで、任意コードの実行ができてしまう。数ある脆弱性の中でもとくにヤバいやつだ。どこが穴なのかというと、タイトルにもあるとおり算術式なのだが、し
pecoからfzfに移行した | tsub's blog
今までずっと peco を使ってきたが、そろそろ別のツールに変えてみるか…と思い立ったので fzf に移行した。 junegunn/fzf: A command-line fuzzy finder written in Go 自分は基本的に飽き性なので、定期的に環境を変えたくなる時期が来るのだが fzf が思ってたより良かったので紹介したい。 fzfとは こちらの記事が参考になる。 おい、peco もいいけど fzf 使えよ - Qiita peco と同じく golang 製の command line fuzzy finder である。 インストールは brew で一発でできる。 $ brew install fzf 本当は zplug を使ってインストールしたかったのだが fzf にバンドルされている fzf-tmux が使えなさそうだったので brew で入れた。 ただ fzf-t
fish shellチュートリアル
fishはフル装備のコマンドラインシェル(bashやzsh同様)で、賢くユーザフレンドリーです。 fishは シンタックスハイライト 、 オートサジェスチョン 、知識ゼロ・設定ゼロでそのまま動作する TAB補完 をサポートしています。 もし、コマンドラインをもっと生産的に、便利に、楽しい(難解な文法や設定オプションを学ぶことなく)環境にしたいならば、fishはあなたの求めていたシェルかもしれません! このチュートリアルはコマンドラインシェルやUnixコマンドの知識があり、fishがインストールされていることを前提とします。 もし、他のシェルについての深い理解があり、fishとの相異点を知りたいならば、 「 他のシェルと違って 」 という魔法の語句を検索してください。 それは重要な相異点を表してます。 fishを立ち上げると、このように表示されます。 Welcome to fish, the
bashスクリプティング研修の資料を公開します - エムスリーテックブログ
こんにちは、エンジニアリングGの中村です。 以前にこのブログにてエムスリーでの社内研修について紹介しました。今回は、この中でのbashスクリプティング講座の資料を公開します。 www.m3tech.blog 弊社の中でもいろいろな用途でbashが使われていますが、bashは簡単に利用できるもののプログラミング言語としてはバグを生みやすい、辛い言語だと思います。 ここで紹介しているのはいわゆるコーディング規則というよりも、バグ防止と可読性向上のためのルールをTips集的にまとめたものです。 bashにおいてまだまだ注意するところはありそうですが、多少なりともわかりにくいスクリプトの削減になればと期待しています。 [追記: 2018-08-22] はてブにて以下のコメントをいただきました。 bashスクリプティング研修の資料を公開します - エムスリーテックブログ bashで50行以上になった
SNIの動作確認にはcURLのresolvオプションが便利 | DevelopersIO
ども、大瀧です。皆さん既知かもしれないのですが、cURLの--resolvオプションがとても便利だったので紹介させてください！ hostsファイル代わりに使える--resolvオプション 様々なWebページやWeb APIの動作確認で活躍するCLIのHTTPクライアント、cURL。要件に応じて様々なオプションを駆使していると思います。例えば複数のコンテンツをホストするバーチャルホストを検証するためにはHostヘッダをリクエストに指定します。AWSのCloudFrontにカスタムドメイン(CNAMEs)を設定しているときの例が以下です。 $ curl --hearder 'Host:example.com' https:///XXXXXX.cloudfront.net/ HTTPであればこれで事足りることが多いのですが、HTTPSでSNI(Server Name Indication)を設定
シェルスクリプトの処理境界が鮮明になる「名前付きブロック記法」なるものを考えてみた
シェルスクリプトは長くなると処理の境界が不鮮明になりがち。 コメントで処理の境界を表現する工夫はよく見かけるが、もっと良い方法はないか考えてみた。 :コマンド、&&演算子、複合コマンド()や{}を組み合わせて書くと、処理の境界線がはっきりする。
プログラマーの君！ 騙されるな！ シェルスクリプトはそう書いちゃ駄目だ！！ という話 - Qiita
本記事が切っ掛けとなってお声がけを頂き、本記事の増補リファイン版となる記事をSoftwareDesign 2018年1月号のシェルスクリプト特集第2章として執筆しました。リファイン版には、この記事で触れていない文法面での分かりにくさについての解説が含まれています。その文法面での分かりにくさの解説の一部に相当する記事もありますので、ぜひそちらも併せてご覧下さい。 Shell Script Advent Calendarをご覧の皆様、図々しくも5日目に続く2度目のエントリーのPiroです。 前回は自作のBashスクリプト製Twitterクライアントをネタに実装を解説しましたが、今日は他の言語で多少のプログラミング経験はあるんだけど、どうにもシェルスクリプトは苦手だ……という人のための、シェルスクリプトによるプログラミングの勘所を解説してみようと思います。多分、プログラミング入門レベルの人や上級
highway という高速検索ツールを作りました · けんごのお屋敷
いまや grep、ack、ag、pt、sift など様々な grep ツールが存在し、高速 grep ツール戦線が激化している昨今ですが、いかがお過ごしでしょう。私は普段から検索ツールには pt を使っていますが、ふとしたことから文字列探索アルゴリズムに興味がわいてきて highway という高速パターンマッチングツールを開発しました。pt や sift が流行りの Go 言語で実装されている中、我が道を行く highway は C 言語での実装にしました (単に Go 言語を知らないだけとも言う＼(^o^)／)。 highway (github) highway とは マルチスレッドで動作する高速パターンマッチングツールです。速そうな名前をつけたくて「高速」でググったら「高速道路」がたくさん出てきたのでこの名前になりました。そりゃそうだ。 機能 基本的な機能としては pt とほぼ同じです
コマンドラインツールを書くなら知っておきたい Bash の 予約済み Exit Code - Qiita
上記の表の通り，Exit Code 1, 2, 126〜165, 255 は特別な意味を持ち，スクリプトやプログラム内で exit に指定するパラメータとしては避けるべきである．とりわけ，Exit Code 127 はトラブルシューティングで混乱の元である（"command not found" で終了したのか，プログラム固有のエラーなのか区別できなくなる）．しかしながら，多くのスクリプトが exit 1 を一般的な実行を続行できないエラーとして使っている．Exit Code 1 は Bash の一般的なエラーを含め，とても多くのエラーで発生しうるので，デバッグの時に切り分けが大変になるだろう． Exit Code を体系立てて定義する試みはある（/usr/include/sysexits.h）が，これは C と C++ プログラマー向けである．スクリプトに関しても同様な感じにするのが適切
シェルスクリプトの中で1行ずつ変数を分割する際には、cutとかawkとか余計なプロセスを起動せずsetを使って分割した方が効率的 - 双六工場日誌
シェルスクリプトの中で、スペース区切りもしくはタブ区切りのレコードを扱うことがよくあると思います。 たとえば、前回のエントリ「AWS CLIとjqを使って、AWSのELBボリュームがアタッチされているEC2インスタンス名を出力するワンライナーを書いた - 双六工場日誌」のスクリプトの出力は以下のようになります。 i-ec56a9f5 vol-07d00601 servername i-ec56a9f5 vol-8f550991 servername このようなレコードの特定の列を取り出して、処理する際にどうするのが効率的か、というのがこのエントリのお題です。 非常に古い話題なので、昔からシェルスクリプトを書いている人には自明な話ではありますが、最近、シェルの標準機能の話を聞く機会がなく、失われつつある技術になってきている気がしているので、改めて確認ということで。 例として挙げたレコードから
jq コマンドを使う日常のご紹介 - Qiita
jq コマンドとは http://stedolan.github.io/jq/ JSONから簡単に値を抜き出したり、集計したり、整形して表示したりできるJSON用のgrepとかawkみたいなコマンドです。 WebサービスがJSONを吐いたり、AWS CLIが JSON を吐いたりする現代社会で大変便利なコマンドです。 マニュアル だいたいここ読めばOK. http://stedolan.github.io/jq/manual/ あ、これで、終わってしまう。だけど気にせず進めます。 簡単な例 まず、空気をつかみましょう。 以下jqコマンドの記法を見ていきます。JSON { "hoge": "value" } があった場合、 . がルート {} を表します。.hoge で "value" を表現します。だいたいこんな感じです。 ただの整形 しばらく下記のJSONを例に進めます。itemsには配
続・ラフなラボ – シェルスクリプトが '> $logfile 2>&1' だらけにならなくて済んだ話
※ 2014-04-26 追記並びに一部コマンド部分の修正を行いました。( > => >> に変更 ) 個人用のチラシの裏のつもりが予想以上に反響いただいていたようで非常にびっくりしております。 ちょっとしたバッチ処理的なものはさくっとシェルスクリプトでやっています。 で、ログをとっておくべくリダイレクトを噛ますわけですが、 スマートに書く方法を調べたのでメモ。 元ネタは @sechiro さんの bashのプロセス置換機能を活用して、シェル作業やスクリプト書きを効率化する でございます。 本当に参考になりました。ありがとうございます。 今までは こんなことやってたわけです。 #!/bin/bash LOGFILE=/tmp/script-log command1 >> $LOGFILE 2>&1 command2 >> $LOGFILE 2>&1 ... >> $LOGFILE 2>&1
使いやすいシェルスクリプトを書く
できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})
シェルスクリプトのオプション設計ガイドライン - Qiita
僕はコマンドラインで使うシェルスクリプトを書くことがけっこうあるんだけど、インターフェイスというか呼び出し方はとても大事だと思ってるので、そこにわりと時間をかけて考えるようにしてる。実装はいつでも変更できるけど呼び出し方を変えた時は利用者にも変更を強いるので、できれば最初から良い設計で作りたいと思っている。 そこで、僕がシェルスクリプトのオプションとか引数とかの仕様を決める上で注意していることをまとめてみた。シェルスクリプトや、その他コマンドラインのツールを作るときに参考にしてほしい。 シェルの種類は bash や zsh を想定してるけど、実装によらない話なのでどんなシェルでも使えると思う。 エラーの時に Usage (使い方ヘルプメッセージ)を表示するのはやめる エラーになった時に Usage (使い方ヘルプメッセージ) を表示するスクリプトがあるけど、やめたほうがいいと思う。例えばこ
シェルスクリプトでパイプを判断する - Qiita
Unix の基本的考え方のひとつに「フィルタとして振る舞う」というものがあります。標準入力から入力をして何らかの処理を行い、標準出力に出力を行うように設計されているコマンドを フィルタ と呼びます。フィルタ・コマンドそれ自身は単純な機能しか持っていませんが、これを | （バーティカルバー）で結びつけることでフィルタを部品のように扱い、大きな機能をもったコマンドとして機能させることが出来ます。 （例）
私が他人のシェルスクリプトから学んだこと | Yakst
私はシェルスクリプトの大ファンで、他人のスクリプトから面白い方法を学ぶのが大好きだ。最近、SSHサーバの2要素認証を簡単にするためのauthy-sshスクリプトに出会った。このスクリプト群を見まわしていて、みんなと共有したいたくさんのクールなことを見つけた。 出力に色付けする 出力文字列を、成功した時は緑に、失敗した時は赤に、警告は黄色に色づけしたいと思うことはたくさんあるだろう。 NORMAL=$(tput sgr0) GREEN=$(tput setaf 2; tput bold) YELLOW=$(tput setaf 3) RED=$(tput setaf 1) function red() { echo -e "$RED$*$NORMAL" } function green() { echo -e "$GREEN$*$NORMAL" } function yellow() { e
ackを捨てて、より高速なag(The Silver Searcher)に切り替えた - Glide Note
Geoff’s site: The Silver Searcher: Better than Ack ggreer/the_silver_searcher · GitHub パターン検索にはackを利用していて、通常利用時には特に不満は無かったんですが、 ファイル数が多いディレクトリだと遅かったので、もっと他の方法が無いかと調べていたら ackの3〜5倍速いというThe Silver Searcherというものが あったので導入。 The Silver Searcherの特徴 公式に書いてあるThe Silver Searcherの特徴 ackの3〜5倍高速 .gitignore、.hgignoreに記載されているものを検索対象から除外 検索対象から除外したいファイルは.agignoreに記載 agというコマンド名で、ackと比べてコマンドが短い(33%減!) なぜ高速なのかは https
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
運用におけるシェルの役割とそのあり方を考える
