シェルスクリプトを書くときにいつもやるやつを調べた
bash のシェルスクリプトを書くときに、いつも脳死で以下をやっている。(同僚が整備してくれたものをコピペしている) エディタなり CI で shellcheck をまわす set -euxo pipefail と冒頭に書く こんな感じ #!/bin/bash set -euxo pipefail いつまでもコピペではさすがにアレなので、意味を調べたメモ。 shellcheck koalaman/shellcheck: ShellCheck, a static analysis tool for shell scripts イケてない書き方に警告を出してくれる それぞれの警告にはエラーコード割り振られていてとても便利 エラーコードごとに正誤例、解説が書かれているのでわかりやすい SC1000 の例 CI もそうだし、エディタのプラグインも充実 しているのでとりあえず入れておくと良い set
シェルスクリプトを何万倍も遅くしないためには —— ループせずフィルタしよう - Qiita
🐚 🐚 🐚 🐚 シェルスクリプトは遅すぎて使えない 普通の「速い言語」より何百、いや、何千倍も遅い 他のプログラミング言語を経験してからシェルスクリプトに入門し、このような感想を持つ方も多いのではないでしょうか。 実際、こういったことは往々にして起こり得ますので、「速い言語」を使うべきか否か見極めることは大事だと思います。 しかし、本当にシェルスクリプトというのは、そこまで遅いのでしょうか？ データ量が多い場合は常に最初から「速い言語」で書いた方がよいのでしょうか？ 実は、そうとも限りません。 シェルスクリプトにはシェルスクリプトなりの「速い書き方」があります。 この「速い書き方」で処理できる問題に関しては、シェルスクリプトは「速い言語」なのです。 では、「速い書き方」とは何かというと、端的には「たくさん繰り返されるループはシェルスクリプトで記述しない」ことです。 以下でこれを説明
雰囲気でシェルを使っている人のためのシェル入門 | κeenのHappy Hacκing Blog
κeenです。雰囲気でシェルを使ってる人が多いとのことだったので少しばかり込み入った知識を。 あと一応POSIX準拠かどうかも気にしながらやっていきます。 基礎知識編 シェルの種類 まず、POSIXにシェルが定義されています。 これに最低限の機能で準拠しているものをPOSIXシェルと呼ぶことにします。いわゆる/bin/shです。具体的な実装はbsh、ash、dashあたりでしょうか。 最低限の機能以上に色々拡張されているシェルを拡張POSIXシェルと呼ぶことにします。具体的な実装はbash、zsh、kshなどでしょうか。 ここでは触れませんがPOSIX準拠でないシェルも存在してcshやtcshなどのシェルがあります。あと確か最近話題のfishも違ったような。 さて、1つ問題になるのは普段使いのコマンドラインはおおむね拡張POSIXシェルでしょうが、サーバで使うシェルやデプロイスクリプトで呼
プログラマーの君！ 騙されるな！ シェルスクリプトはそう書いちゃ駄目だ！！ という話 - Qiita
本記事が切っ掛けとなってお声がけを頂き、本記事の増補リファイン版となる記事をSoftwareDesign 2018年1月号のシェルスクリプト特集第2章として執筆しました。リファイン版には、この記事で触れていない文法面での分かりにくさについての解説が含まれています。その文法面での分かりにくさの解説の一部に相当する記事もありますので、ぜひそちらも併せてご覧下さい。 Shell Script Advent Calendarをご覧の皆様、図々しくも5日目に続く2度目のエントリーのPiroです。 前回は自作のBashスクリプト製Twitterクライアントをネタに実装を解説しましたが、今日は他の言語で多少のプログラミング経験はあるんだけど、どうにもシェルスクリプトは苦手だ……という人のための、シェルスクリプトによるプログラミングの勘所を解説してみようと思います。多分、プログラミング入門レベルの人や上級
コマンドラインツールを書くなら知っておきたい 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++ プログラマー向けである．スクリプトに関しても同様な感じにするのが適切
Big Sky :: UNIX コマンドを SQL で抽出できるツール qq を作った。
昨日僕の Twitter タイムラインで q というツールが話題に上がっていました。 GitHub - harelba/q: q - Run SQL directly on CSV or TSV files Text as Data q is a command line tool that allows direct execution of SQL-like q... https://github.com/harelba/q 標準入力を SQL で抽出できるという物です。ただ個人的には「こういうの python じゃなくて Go でビルドされてると助かるよなー」と思ったので q と同じ様な動作になるツールを作ってみました。 GitHub - mattn/qq Select stdin with query https://github.com/mattn/qq 例えば msys2 のシ
【個人メモ】shellで連続した数列を得てxargsでコマンドを実行して回って行きたい - Qiita
何がやりたいのか そう、結論からいうと大量のサーバに対してプロビジョニングをかけたい。 で、サーバの名前の付け方が以下の感じだったとする こいつらに対して、ssh uname -aを実行したい場合はどうするべきか、 というのでチョコっとしたシェルコマンド(ワンライナ)を残す。 xargsを組み合わせれば良い。 利用するコマンドのバージョン GNU xargsとBSD xargsでオプション違ってて困った。 とりあえずGNU xargsを基準とする。 xargsは4.4.2 bashはは4.3.11である。 xargsについて
“`〜`”と“$(〜)”の挙動の違いまとめ - Qiita
“`〜`”と“$(〜)”は、単純には置き換えられない！ “`〜`”と“$(〜)”は、どちらも中の文字列をコマンドとして解釈し、その実行結果を返す文法であるが、必ずしも素直に置き換えることはできない。 その例をまとめることにした。 “$(〜)”は素直に入れ子にできるが、“`〜`”は酷く複雑になる 例えば、“$(〜)”の中に“$(〜)”を用いて、次のようなコマンドを書いても正しく動作するが、
開発時の探し物を楽にする習慣作り
西日暮里.rb ゴールデンだよLT大会 @ 秋葉原UDX！！ (https://nishinipporirb.doorkeeper.jp/events/42587)Read less
"shove" というシェルスクリプト用のテストツールを作った - weblog of key_amb
CONTENTS: "shove" とは Motivation こんなツールにしたい 使い方について 中で何をやっているのか おわりに "shove" とは こちらです。 github.com 動作イメージとしては README.md にも貼っているスクリーンショットがわかりやすいと思うので、こちらにも貼ります。 成功時: 失敗時: 上のようにテストスクリプトを引数に与えて shove コマンドを実行すると、テストを実行して結果を出力してくれます。 Perl Monger のみなさんは「proveっぽい」と思っていただけたでしょうか。 そうです。名前の "shove" は "shell" + "prove" を縮めたものです。 bash だけでなく、ksh, dash, zsh など POSIX を満たしているシェルに対応できるように作りました。 $SHELL 変数の値と異なるシェルでテス
いい加減、>/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 これをぱっと見て
Bashのよくある間違い | Yakst
原文は2015年8月22日時点のものを利用しており、それ以降に追記、更新されている可能性があります。 本翻訳は原作者の許可を得て公開されています。 Thanks for GreyCat! このページはBashプログラマーが陥りがちなよくあるエラーについてまとめました。以下の例は全てなんらかの欠陥があります。 クオートをいつも使い、どんな理由があっても単語分割を使わなければ、多くの落とし穴からあなた自身を守ることができます！単語分割はクオート表現をしない場合にはデフォルトでオンになっている、Bourneシェルから継承された壊れたレガシーな設計ミスです。落とし穴の大半はクオートされていない展開になんらか関連し、単語分割しその結果をグロブします。 1. for i in $(ls *.mp3) BASHプログラマーたちがループを書く際にもっとも犯しがちなよくあるミスは以下のような感じです。: f
POSIX sh準拠のシェルスクリプトを書くときに checkbashisms が便利。 | おそらくはそれさえも平凡な日々
http://sourceforge.net/projects/checkbaskisms/ 「#!/bin/sh なのにbashでしか動かないシェルスクリプトを書くな！」みたいなことはよく言われるわけですが、僕はゆとりなので正直どうでもええやろとか思ったりもしてました。実際、CentOSだと、/bin/sh は /bin/bash へのリンクだし、OSXでも /bin/sh の実態はbashだしね。 しかしそこで立ちふさがるのがUbuntu。Ubuntuだとデフォルトで /bin/sh は /bin/dash だったりするわけです。dashはPOSIX準拠のsh実装で、bash独自の記述があると見事に動かない。 とはいえ、それで困るのだったら、デフォルトシェルをbashにしたVMテンプレートを作ればいいんじゃないかって思うやろ。僕もそう思う。 しかしそこで立ちふさがるのがTravisで、
シェルスクリプトで書かれた軽量コンテナ MINCS がすばらしい (1) - TenForward
これはだいぶ前に書いたエントリです。MINCS作者による最新の解説があるのでそちらもご覧ください。 (2016-11-21追記) コンテナは使いたいけど、たくさんコンテナを起動すると結局それぞれのコンテナに対するセキュリティアップデートなどのメンテナンスは必要だし、コンテナ内独自のプログラムやライブラリ以外はホストと共有したいよね、って話が出てきたりします。みんな考えることは同じで、bind mount を使えば良いよね、って話はでてきてました。 こないだもブログで紹介した kazuho さんの jailing 私が LXC でも結構簡単にできるよ、っていう提案を兼ねて作った lxc-bind こないだのLinuxConでもDockerでたくさんのオプションを並べて、色々工夫して bind mount を使ってやってる発表もありました (Using Docker for existing
GitHub - jlevy/the-art-of-command-line: Master the command line, in one page
Scope: This guide is for both beginners and experienced users. The goals are breadth (everything important), specificity (give concrete examples of the most common case), and brevity (avoid things that aren't essential or digressions you can easily look up elsewhere). Every tip is essential in some situation or significantly saves time over alternatives. This is written for Linux, with the excepti
シェルスクリプトを書くときはset -euしておく - Qiita
エラーがあったらシェルスクリプトをそこで打ち止めにしてくれる（exit 0以外が返るものがあったら止まるようになる）。「あっあれここでうまくいってないからデータ準備できてないのにあれあれっもうやめて！」ってなるのを防げる。 set -u 未定義の変数を使おうとしたときに打ち止めにしてくれる。Perlでいうuse strict 'vars';的なもの。 って気軽な気持ちで書いてしまって、「ん、やたら時間かかると思ったらスペルミスうわなにをするやめ」ってなるのを防げる。 一部だけ例外にしたい はてなブックマークのコメントより -e は command1 || command2 みたいなことが出来なくなるの使うことないな。-uは付けといて良いが。 確かにおっしゃるとおりですね。コマンドの失敗を考慮して書いている部分については（もしくはやたらexit 0以外するコマンドを呼ばないといけないときなど
Lessの便利な使い方
最近 Stop using tail -f (mostly) や 「tail -f」を使うのは情弱、情強は「less +F」を使う などless押しな記事が幾つか上がっているんだけど、タイトルが煽り気味なのか若干反感を呼んでいるようなのでless派が職場で肩身の狭い思いをしないようにもう少し便利な使い方を紹介したい。 tail -fの様なScroll forward less +Fで起動またはless起動中にF 元記事にもあるtail -fと同様の振る舞い。正直この機能と検索だけでいいのであればtailで十分。lessの便利なところは様々な機能との組み合わせにあって、これから紹介する機能は基本的にこのモードと組み合わせが可能だ。あと、less開いてFのほうがタイプが面倒くさくないのでおすすめ。 1行で表示する (改行しない) less -Sで起動またはless起動中に-Sr(-Sでモード切
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bashでOSを判別する - Qiita
yudai/gotty · GitHub - Share your terminal as a web application
[pdf]open3 のはなし 田中哲 独立行政法人 産業技術総合研究所 情報技術研究部門 東京Ruby会議03 2010-02-28