いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ - Qiita
いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ShellScriptBashLinuxUNIXmacOS はじめに [ $? -eq 0 ] や [ $? -ne 0 ] は冗長でデメリットしかありません。非常に多く見かける書き方ですが、1979 年に Bourne シェルが広く公開された時からこのようなコードは必要ありませんでした。実際に当時はこのような書き方は使われておらず、このような書き方をしなければならなかった歴史的な経緯などはありません。これはなぜか広まってしまった良くない書き方です。 優れたコードとは無駄がないシンプルなコードです。丁寧なコードとは無駄な処理を書くことではありません。[ $? -eq 0 ] や [ $? -ne 0 ] は書かないほうが、簡単で読みやすくわかりやすくなります。優れた文法
![いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/4e42d360866a8ef193de27e43e50492da34de08d/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JUUzJTgxJTg0JUUzJTgxJTg0JUU1JThBJUEwJUU2JUI4JTlCJUUzJTgyJUI3JUUzJTgyJUE3JUUzJTgzJUFCJUUzJTgyJUI5JUUzJTgyJUFGJUUzJTgzJUFBJUUzJTgzJTk3JUUzJTgzJTg4JUUzJTgxJUE3JTIwJTVCJTIwJTI0JTNGJTIwLWVxJTIwMCUyMCU1RCUyMCVFMyU4MiU4NCUyMCU1QiUyMCUyNCUzRiUyMC1uZSUyMDAlMjAlNUQlMjAlRTMlODElQUElRTMlODIlOTMlRTMlODElQTYlMjAlRTMlODIlQTglRTMlODMlQTklRTMlODMlQkMlRTUlODclQTYlRTclOTAlODYlRTMlODIlOTIlRTYlOUIlQjglRTMlODElOEYlRTMlODElQUUlRTMlODElQUYlRTMlODIlODQlRTMlODIlODElRTMlODIlODglRTMlODElODYlRUYlQkMlODEmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWZhZDdkMjVkYjUxODQ5OWRhZDhiZWM3ZGMwN2ZlY2Q0%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBrbzFua3NtJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0zNDA2OWFjMTI5MDIyYmE1ZjY0OTI5ZGU2ZGUwNDU5Zg%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D8f12358d68288246128c01d35bcfa4b1)
Makefile で環境構築を確実に一瞬で終わらせる話
はじめに ラブグラフ 開発チーム インターン の こるく です。 私がラブグラフに Join してまず感動したのが、コマンド一発で完了する超お手軽な環境構築でした。 普通プロジェクトに Join するときは面倒な環境構築をする必要がありますが、ラブグラフではそれが全くありませんでした。 ということで今回は、それを実現している Make と Docker を使って、開発、テスト、CI、本番のすべての環境で、ランタイムの環境と環境変数の設定をすべてコードベース ( IaC というやつ？ ) でラクに共有して開発体験を爆アゲしようと思います。 この構成が目指すところ ✅ 環境で悩むことをなくして開発体験を爆アゲする ✅ 環境構築をコマンド一発でできるようにする ✅ ついでにテストもコマンド一発でできるようにする ✅ 環境変数をホストマシンのシェルから排除し、コードの一部としてリポジトリ内で管理す
シェルのバックグラウンド実行って後だしできるって知ってました？ - Qiita
この前までの私のちょっと時間のかかるバッチ実行の日常 「よっしゃー、今日はバッチ処理やるで！」と気合い入れて、タタタタッターン（bash xxxx.sh + Enter）。 おっと、またやらかしたわ。コマンドの末尾に&つけんの忘れたら、プロセスがフォアグラウンドで動いてまうねん。 これやと、ターミナルがこのタスクに独り占めされてまうわ。 この状況をどうにかするには、Ctrl+Cでプロセスを止めてからやり直すか、それとも別のターミナルウィンドウを開くしかないねん。めっちゃ面倒くさいなあ。 今後の私のちょっと時間のかかるバッチ実行の日常 「さて、本日はバッチ処理の実施日でございますね」と心に留めました。 タッタタタッターン。 あら、不覚にも再び&を添え忘れてしまい、結果としてフォアグラウンドでの実行を余儀なくされました。 しかし、ご心配なく。 まずは、Ctrl+Zを駆使してプロセスを一時停止い
POSIXシェルスクリプトではwhichではなくcommand -vを使うべき理由（＋シェルスクリプト版which） - Qiita
重要 2022-01-30 追記 この記事で解説していた警告の出力は 2022-01-21 に取り消されました（参照 Revert deprecation of which）。そのため Debian which が GNU which に変わることは（少なくとも近い未来では）ないと思います。しかしながら which を使うよりは POSIX で規定されている command と type を使う方を推奨します。 はじめに which コマンドはシステムにインストールされてるとは限りません。実際に最小構成でインストールされてない環境として CentOS があります。一方 command -v は POSIX 規定されているので POSIX に準拠したどのシェルでも問題なく使えます。シェル上では which コマンドを使っても良いと思いますが、シェルスクリプトでは command -v を使う
シェル芸の可読性を向上させるマルチライナー記法のススメ - Qiita
マルチライナー記法とは？ マルチライナー記法とは、その名の通りシェル芸をワンライナーではなくマルチライナー（複数行）で書くことです。長すぎる行をワンライナーで書くと以下のように横スクロールが必要になって非常に読みにくくなります。（コードは Convert long single line command to a bash shell script より借用。長いコードとして利用しているだけで中身に意味はありません）。マルチライナー記法はこのようなワンライナーを読みやすく書くことです。 nice --20 iperf3 -c somelocation.com -f k | while IFS= read -r line; do echo "$(date) $line"; done | tee onespeed.txt | tee -a speeds.txt; sleep 30 ;cat o
良いシェルスクリプトのためのkillとtrapの基本 ～ シグナル番号は使わない、シグナル名を使う - Qiita
はじめに kill コマンドと trap コマンドはシェルでシグナルの送信と受信を行うためのコマンドです。このコマンドは意外と適切ではない使われ方をよく見かけます。この記事では kill と trap の基礎知識を解説します。 POSIX準拠のkillコマンドの構文 POSIX で標準化されている kill コマンドの使い方は次のとおりです。POSIX で標準化されているというのは移植性が高い書き方ということを意味しています。シグナル名の指定には -s オプションが必要です。そして signal_name であって signal_number でないことに注意してください。POSIX シェルの世界にシグナル番号という概念はありません。シグナル番号を指定した書き方は避ける方をおすすめします。
【永久保存版】シェルスクリプト完全攻略ガイド - Qiita
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 シェルスクリプトの世界へようこそ！ シェルスクリプトって何？ シェルスクリプトは普段 Bash などのシェルで実行しているコマンドを並べて、まとめて実行できるようにしたものです。ファイルのバックアップ、ログファイルの解析、システムのセットアップなど、ターミナルで行っていた一連の作業をまとめてシェルスクリプトに記述することで、シェルスクリプトを実行するだけで自動的に一連の作業を終わらせることができるようになります。また、シェルスクリプトはファイルに保存することになるため、再利用するのも簡単になります。 シェルスクリプトで使うコマンドの多くは UNIX コマンドになると思います
パイプに関係するさまざまなバッファ、ちゃんと意識していますか？ - Qiita
はじめに コマンドをパイプでつなげた時、各コマンドの間にはいくつかのバッファが存在します。そのバッファについてちゃんと意識しているでしょうか？ バッファの存在によって各コマンドの実行には分かりづらい変化があります。そのバッファを知らないと罠にハマってしまう・・・かもしれません。 プロセス間のパイプ通信のバッファ まずプロセス間のパイプ通信に存在しているバッファです。多くのコマンドは行単位でデータを処理しますが、一般的にパイプでつなげた各コマンドはそれぞれ処理速度が異なります。処理がすぐに終わるコマンドもあれば時間がかかるコマンドもあります。各コマンドは並列で動作可能ですが必ずしも並列で動作するわけではありません。 一般論としてパイプライン全体の処理にかかる実時間はパイプでつながったコマンドの中で一番遅いコマンドに足を引っ張られます。いくら並列で動作可能と言ってもデータが到着しなければ処理す
問 awk をワンライナーで書く時のアクション区切りの｢;｣の数は0個? 1個? 2個? ＋ こぼれ話 - Qiita
問題 awk で複数のアクションをワンライナーで書いた時、区切りの「;」の数は、0個、1個、2個のうちどれが最も適切でしょうか？ 以下の中から適切な回答（複数可）を選び、その理由も答えてください。 # A. セミコロンは不要である echo foo | awk '{print} {print}' # B. セミコロンは一つ必要である echo foo | awk '{print} ; {print}' # C. セミコロンは二つ必要である echo foo | awk '{print} ;; {print}' この記事は上記の問題の回答、およびその回答にまつわる Brian Kernighan と One True Awk、GNU awk との互換性、POSIX awk の標準規格、に関するこぼれ話を紹介する記事です。 . . . ブコメにちゃんと文章読んでるんだろうか？と疑問になるレスが
CLI でのテキスト処理を高速化する
最近、個人的に数百MBから数GBクラスのテキストファイルを扱う機会が増えています。これくらいのサイズだと、手元のマシンだけで十分対応可能な範囲ではあるのですが、扱いを間違えると時間が掛かってつらいことになります。結論から言うと、とにかく LC_ALL=C を指定しようというのと、OS X であれば初めから入っているコマンドではなく最新の coreutils を使おうという2点なのですが、それだけ終わってしまうとあんまりなので、手元の環境で計測した数字を出しつつ紹介したいと思います。 なお、この記事中の速度計測はクアッドコアの Core i7 (2.2GHz) を搭載した MacBook Pro 15インチ (Mid 2014) で行いました。OS は OS X El Capitan です。テスト用のデータは以下のようなコマンドで生成しました。 % perl -e 'for (1..2**2
知っておくとちょっと便利！bash スクリプトで使用する括弧 () [] {} について | SIOS Tech. Lab
bash における () [] {} とは Linux で bash を使用している環境で、スクリプト内などに括弧 () [] {} が使用されることがあります。 これらの括弧を使用することで、より複雑なスクリプトが作成できたり、スクリプトの記述を簡略化する事が出来ます。 なお、bash とはシェルの名称です。シェルには他にもたくさんの種類がありますが、bash が Linux 標準のシェルとして採用されています。 () [] {} の使い方 丸括弧 () 丸括弧 () は、括弧内に記載された命令をサブシェルとして実行します。 サブシェルというのは、シェルから起動された別の (子プロセスの) シェルのことを言います。 サブシェルで操作した内容は、元のシェルに影響を与えません。 $ pwd /opt/dir1 $ (cd /opt/dir2) $ pwd /opt/dir1 ただし、ファイル
![知っておくとちょっと便利！bash スクリプトで使用する括弧 () [] {} について | SIOS Tech. Lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/d7937786c195a550236c49b11a24d3b31953e349/height=288;version=1;width=512/https%3A%2F%2Ftech-lab.sios.jp%2Fwp-content%2Fuploads%2F2021%2F12%2F21016ad731dce10d59f51619b954d753.jpg)
WSLでopenコマンドを用意する
function open() { if [ $# != 1 ]; then explorer.exe . else if [ -e $1 ]; then cmd.exe /c start $(wslpath -w $1) 2> /dev/null else echo "open: $1 : No such file or directory" fi fi } zshでしか試していないが、たぶんbashでも似たような感じでいけると思う。 エクスプローラによるopen Macのターミナルでは、open filenameとすると、そのファイルを関連付けられたアプリで開くことができる。また、open .などとするとFinderでカレントディレクトリが開いて便利だ。 WindowsのWSLで似たようなことがしたくて、
bashの似てて紛らわしいもの =/==と= 代入&比較の注意点 - それマグで！
似てて紛らわしいものシリーズ =/==と= bash の記号で初心者泣かせの、似てて紛らわしかったり、使い分けがわからなかったり、読み方を間違えてパニックになる記号について書く =/==と= の違い =はいくつかのパターンで出てきます。 比較演算子として = で比較 == で比較(=と同じ =~ で正規表現マッチ 数値の比較 代入指示子として 変数（文字列）の代入 数値の代入 これらのそれぞれで微妙な差異があるのです。めんどくさいよねー 大きな違い。両端スペース ＝のスペースの関係。他のプログラミング言語を触った人はこのへんで、頭が？？？になると思う。 変数に代入するときはvarname=value のように書く、スペースは許されない。 文字列を比較するときは [[ / [ の中で使われる。スペースの有無は問われない。 変数に代入する場合（文字列） vaname=value スペースは許
bash スクリプトの実行中上書き動作について
を設定してから再度試した所 bar が表示された。backupcopy は編集中のファイルによって自動で判別する auto がデフォルトになっている為、試す際には明示的に yes に設定しないといけない。 bash の実装確認 evalstring.c の parse_and_execute でコマンドが処理されており、input.c の with_input_from_buffered_stream で読み込みの準備が行われている。バッファの読み込みの本体は y.tab.c つまりパーサから直接呼ばれており、このパーサは fgets(3) で読み込まれつつ実行される為、一括でファイルが読み込まれている訳ではない。 while/do でループ実行した際に、ファイルを書き換えられたら戻り先はどうなるか、についてはスクリプトはバッファ付きで読み込まれており、そのバッファがファイルシステムから読
set -eのもとで特定のコマンドの終了ステータスを変数に入れるシェルスクリプトのスニペット - Islands in the byte stream
課題編 シェルスクリプトで「あるグローバルな状態を変える操作を行い、その結果をチェックし、状態をもとに戻す」みたいなタスクをするときに「その結果をチェックし」のところでコマンドの終了ステータスを変数に入れて置きたいみたいなことがあります。例えば、次のようなコマンド操作です。 set -e # グローバルな状態を変える操作を行う git merge --no-ff --no-commit $main_branch || true # 結果をチェックしてexit codeを変数に入れる git diff --cached --exit-code --quiet ; code=$? # グローバルな状態をもとに戻す git merge --abort # 上位プロセスに結果を渡す exit $code スクリプト全体には set -e （コマンドが失敗するとシェルスクリプトが即座に終了する）を効
シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくる - Qiita
シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくるShellScriptBashUNIXshellPOSIX はじめに シェルスクリプトの変数代入で = の前後にスペースを置くことができない理由は、検索すれば「プログラマーの君！ 勘違いするな！ シェルスクリプトでは読みやすさのためにスペースを置くな！！ という話」のような記事がすぐに見つかります。記事に書いてあるとおり変数代入とコマンド呼び出しと区別がつかないからです。それは間違いではないんですが、私はもう少し説明が足りないと感じています。そこで今回は = の前後にスペースを置けない本当の理由を解説したいと思います。 の前に皆さんにはこの話を読みながら、自分がシェルスクリプトの言語設計者だったとしたら、どういう言語仕様にするかを考えて欲しいです。なぜかと言うとシェルスクリプトの文
環境変数 PATH に空文字があるとカレントディレクトリが指定されているのと同じ意味になる
何だと！？ タイトルのまんま。 恥ずかしながらこれ今まで知らなかった。 もしかして常識だったりする？ ちなみに確認したのは Linux だけど、glibc の posix サブディレクトリ配下の execl*execvpe の挙動なので glibc 使ってればみんな一緒じゃないかな？知らんけど… 環境変数 PATH が設定されていない時 unset PATH とした状態。 この場合、PATH=/bin:/usr/bin と設定されているのと同じ意味になる（追記も参照のこと）。 当然カレントディレクトリは含まれていない。 環境変数 PATH が空の時 PATH= とした状態。 「PATH 環境変数が設定されていない時」とは異なる事に注意。 この場合、PATH=. と設定されているのと同じ意味になる。 つまり、カレントディレクトリが含まれている。 環境変数 PATH の最後が : で終わってい
Bash Scriptの作法 - Qiita
はじめに チーム開発でシェルスクリプト（特にBash Script)を書く際に守るべきルールをまとめます。 シェルスクリプトのコードレビューをする際等にお役立てください。 スクリプト名 -区切りの小文字英数字（いわゆるkebab-case）をつける。拡張子は.sh. これは特に理由があるわけではないので_区切りでもよいし、チーム内にzshやfish等の他Shell愛好家がいる場合は拡張子は.bashでも良い。どちらにせよチーム内では統一しておかないと混乱の元となる。 改行コード LFを使用する。CRLFだと動作しないので書く際に間違うことはないが、Windows上のgitのautocrlf設定によってはご丁寧にCRLFでチェックアウトされてしまう。 避けるためにはgit config --global core.autocrlf inputとするか、.gitattributesをレポジトリ
シェルスクリプトで変数に改行文字を入れる方法の細かすぎる解説 - Qiita
すべての POSIX シェルで使用可能なので私はこれを推奨します。シェルスクリプトの改行コードは Windows の CR+LF ではなく LF を使用している前提です。いくつかの環境ではシェルスクリプトの改行コードに CR+LF を使用していても動くようなのですが（未調査）、遅かれ早かれ問題になるはずです。また需要は少ないと思いますが、POSIX シェル以前の Bourne シェルでも使える（おそらく）唯一の方法です。Solaris 10 などの古い環境にも対応させるのであればこの方法しかありません。 メリットはコードの量が最も少なく最も速いということです。デメリットは 2 行になるため少し不格好でインデントをする場合に困るだけですが、インデントに関してはこのような定数はスクリプトの上部の関数の外で定義するので通常は問題にならないはずです。 LF=$'\n' bash、ksh、mksh、
返り値のチェックでシェルスクリプトが止まらないようにする - CUBE SUGAR CONTAINER
シェルスクリプトで set -e しておくとコマンドの返り値が非ゼロ (エラー) のときにスクリプトを止めることができる。 この機能を使うと、コマンドの実行結果がエラーになった状態で処理が突き進んでしまうことを防止できる。 ただ、この機能は便利な反面、スクリプトが意図せず止まってしまうこともある。 今回は、それを回避する方法について。 使った環境は次の通り。 $ sw_vers ProductName: Mac OS X ProductVersion: 10.14.6 BuildVersion: 18G103 $ bash --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18) Copyright (C) 2007 Free Software Foundation, Inc. もくじ もくじ set -e
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
