シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくる - Qiita
シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくるShellScriptBashUNIXshellPOSIX はじめに シェルスクリプトの変数代入で = の前後にスペースを置くことができない理由は、検索すれば「プログラマーの君！ 勘違いするな！ シェルスクリプトでは読みやすさのためにスペースを置くな！！ という話」のような記事がすぐに見つかります。記事に書いてあるとおり変数代入とコマンド呼び出しと区別がつかないからです。それは間違いではないんですが、私はもう少し説明が足りないと感じています。そこで今回は = の前後にスペースを置けない本当の理由を解説したいと思います。 の前に皆さんにはこの話を読みながら、自分がシェルスクリプトの言語設計者だったとしたら、どういう言語仕様にするかを考えて欲しいです。なぜかと言うとシェルスクリプトの文
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 ファイルを食わせることで、任意コードの実行ができてしまう。数ある脆弱性の中でもとくにヤバいやつだ。どこが穴なのかというと、タイトルにもあるとおり算術式なのだが、し
yamayaさんの難読化シェル芸(フィボナッチ数列) 解説
yamaya_fib.md yamayaさんの難読化シェル芸(フィボナッチ数列) 解説 経緯 (1) ある日、yamaya さんという怖い方がこのツイートを投稿する。 (2) シェル芸bot上で実行されたこのシェル芸は、結果として下記のようにフィボナッチ数列を出す。 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946 17711 28657 46368 75025 121393 196418 317811 514229 832040 1346269 2178309 3524578 5702887 9227465 14930352 24157817 39088169 63245986 102334155 165580141 267914296 433494437 701408733 11349031
初心者向け、「上手い」シェルスクリプトの書き方メモ - Qiita
ここ最近、沢山シェルスクリプトを書くようになりました。 元々あまりシェルスクリプトを書いたこと無かったので、色々と勉強しつつ書いてるのですが、 他のプログラミング言語とはちょっと違って独特なクセというか、発見の度におぉー！ってなることが沢山あって楽しいです。 そんなわけで、最近学んだり参考にした中で特に感動したシェルの上手い書き方をまとめてみます。 きっとまだ知らないこととかもっと上手くやる方法なんかが沢山見つかりそうなので、 もっといいやり方あるよ！って方はコメントください 何もしない : (コロン)コマンド シェルを書いていた時に非常に欲しかったコマンドがこれ！何もしない！ : というコマンド(？)を利用すると、何もせずに終了ステータス0(つまり正常終了)を返します。 これが様々な事に使える万能コマンドで、これによって面倒なエラー処理を簡潔にできたり、 入力や出力のリダイレクト元/先と
シェルスクリプトの中で1行ずつ変数を分割する際には、cutとかawkとか余計なプロセスを起動せずsetを使って分割した方が効率的 - 双六工場日誌
シェルスクリプトの中で、スペース区切りもしくはタブ区切りのレコードを扱うことがよくあると思います。 たとえば、前回のエントリ「AWS CLIとjqを使って、AWSのELBボリュームがアタッチされているEC2インスタンス名を出力するワンライナーを書いた - 双六工場日誌」のスクリプトの出力は以下のようになります。 i-ec56a9f5 vol-07d00601 servername i-ec56a9f5 vol-8f550991 servername このようなレコードの特定の列を取り出して、処理する際にどうするのが効率的か、というのがこのエントリのお題です。 非常に古い話題なので、昔からシェルスクリプトを書いている人には自明な話ではありますが、最近、シェルの標準機能の話を聞く機会がなく、失われつつある技術になってきている気がしているので、改めて確認ということで。 例として挙げたレコードから
Talpa memorandum
橘玲の『「読まなくてもいい本」の読書案内』を読んだので、感想とメモをまとめておく。 この本、タイトルは『「読まなくてもいい本」の読書案内』だが、実際には「読まなくていい本」はほとんど紹介されていない。紹介されているのは、当たり前の話かもしれないが読むべき本だ。他の読書案内本と異なっているのは、”こういう本は読まなくて良い”と、ばっさり切り捨てているところ。読むべきか・読まなくてもよいかの基準は、20世紀後半に爆発的に進歩した科学研究の成果に置いている。著者は、この時期に起きた科学研究の大幅な進歩を”知のビッグバン”、”知のパラダイム転換”と呼び、これ以前に書かれた本は（とりあえず）読む必要がないと言い切る。古いパラダイムで書かれた本は捨てて、新しいパラダイムで書かれた本を読もうという話だ。ちょっと乱暴な分け方ではあるが、1980年代に大学生だった私には案外納得できるものだった。学生時代に最
使いやすいシェルスクリプトを書く
できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})
シェルスクリプトを書く時に気をつけている事など - Qiita
あくまでも個人的な意見であって、自分がシェルスクリプトを書く時に気をつけている事を備忘録的に列挙しているだけです。 「こうするべきだ」と押しつけている訳ではありません。 勿論「私はこうしている」とか「こうすると良いよ」という意見や議論は大歓迎です。 export (1) しないシェル変数は全て小文字で書く。 PATH や HOME などは環境変数なので大文字で。 スクリプト内で使っているのは単なるシェル変数なので小文字で。 使い方をちゃんと区別する事は重要だと思う。 シェルの変数展開を活用しよう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
