「shell」の記事 - Crieit

EOF制御文字を削除する

2023-10-20T20:06:09+09:00

#末尾にEOF制御文字があれば、1行削除する
if tail -n 1 ${DATA} | grep -q "^¥Z$";
then
    sed -i "s/^¥Z$//g"  ${DATA} 
fi

bash で標準出力と標準エラーを 2つのコマンドに出し分ける

2021-12-17T09:13:56+09:00

本記事はシェルスクリプトのカレンダー | Advent Calendar 2021 - Qiita 17日目の記事だ。

シェルスクリプトのカレンダー | Advent Calendar 2021 - Qiita

殆どカレンダーが埋まってなかったので、思いついたネタで埋めちゃえ埋めちゃえ。

今回は、 bash 系列 (bash, zsh 等) のプロセス置換 (process substitution) 機能の話だ。

このプロセス置換は POSIX 互換の機能では無いため、以降の例は ash 系列 (busybox hush (ash), dash 等) では利用できない。

bash のプロセス置換

bash 系のプロセス置換という機能と、 tee コマンドを組み合わせて、同時に複数のコマンドにパイプできるらしい。

詳しい説明を読んでも、正直頭がさっぱり追いつかないが…

Linuxでのプロセス置換 #Linux - Qiita

要は、引数部分でファイルを指定するべき場所で、コマンドの標準入出力を代用できる機能ということか。

例えば、 "cat <(ls ./a) <(ls ./b)" とすれば、 "ls ./a" の内容と "ls ./b" の内容が連結されて出力されるし、
"command0 | tee >(command1) | command2" とすれば、 command0 の標準出力が、 command1 の標準入力と、 command2 の標準入力両方に渡される。
また、「ファイルの読み書きの代替」となるため、 "command0 2> >(command1)" のようにリダイレクト先のファイル名の替わりにプロセス置換を使えば、標準エラーだけを command1 の標準入力に渡すことができる。

ちょっとその尖った使い所を考えてみる。

例えばこんな、標準出力と標準エラーを吐き出すスクリプトがあったとしよう。

$ cat <<'EOF' > ./testecho.sh
#!/bin/bash
echo "stdout1" >&1
echo "stderr1" >&2
echo "stdout2" >&1
echo "stderr2" >&2
EOF
$ chmod u+x ./testecho.sh

このスクリプトを実行し、標準エラーだけ command2 に渡して、標準出力は command1 に渡したい場合、プロセス置換を使うと以下のようにできる。

$ ./testecho.sh 2> >(command2) | command1
# -> 各コマンドの入力
#   command1:
#     stdout1
#     stdout2
#   command2:
#     stderr1
#     stderr2

ここで更に、標準出力と標準エラーの両方を command2 に渡して、標準出力だけを command1 に渡したい場合、ちょっと複雑になるが以下のようにして実現できる。

$ ./testecho.sh 2>&1 > >(tee >(command1)) | command2
# -> 各コマンドの入力
#   command1:
#     stdout1
#     stdout2
#   command2:
#     stdout1
#     stderr1
#     stderr2
#     stdout2

少し複雑なので分解して考えてみよう。

まずは testecho.sh のリダイレクト部分 (赤枠) を考える。
1. リダイレクトを複数並べる場合は左から評価されるが、後ろに書いたリダイレクトで上書きされるような動きをするので、右から順番にリダイレクトされると考えるとわかりやすい。 ¹
  このため、まずは (黄色下線部) の部分を見てみよう。
  この部分は、標準出力をファイルにリダイレクトしているだけ (つまり、只の "> ファイルパス") の表記だ。
  ただ、ファイルパスの代わりにプロセス置換 (">(cmd_list)") が使われており、標準出力が tee の標準入力へ書き込まれている。
  1. さらに、 tee のファイル出力もまた、プロセス置換を使って command1 の標準入力に渡される。
    結果的に、 testecho.sh の標準出力だけが、 command1 の標準入力に渡されることになる。
  2. 次に、 tee の標準出力のほう、これは ./testecho.sh を実行した標準出力に戻ってくる。
2. さて、 testecho.sh のリダイレクトに話を戻すと、その次のリダイレクト (水色下線部) の "2>&1" によって、 tee の標準出力と ./testecho.sh の標準エラーが、標準出力側に統合される。
最後に、その統合された標準出力が、パイプで command2 に渡される。
結果的に、 testecho.sh の標準出力と標準エラーの両方が、 command2 の標準入力に渡されることになる。

ちなみに、 ./testecho.sh の標準出力と標準エラーの出力速度が早いと、上記の出力例のように command2 に渡される標準出力と標準エラーが順不同になってしまう。

なお、以下のようにやっても同じ結果になるはずだ。

$ ./testecho.sh > >(command2) 2>&1 > >(tee >(command1))

実用例

例えば、以下のようにすると、コマンドの標準出力だけメールを出しつつ、メールの内容と標準エラーの両方を journal に書き込む事ができる。

./testecho.sh 2>&1 > >(tee >(/usr/sbin/sendmail [email protected])) | /usr/bin/systemd-cat

ただ、どうせ journal に記録するなら、 -t オプションを使って、以下の 3 つを識別子で分けて記録したほうが良いかもしれない。

./testecho.sh の標準エラー
./testecho.sh の標準出力
sendmail の標準出力＆エラー

./testecho.sh 2> >(/usr/bin/systemd-cat -t cmderr) > >(tee >(/usr/bin/systemd-cat -t mailout /usr/sbin/sendmail -v [email protected]) | /usr/bin/systemd-cat -t cmdout)

うーん、 ここまで来ると初見で動作を理解できる気がしない。

参考:

https://tellme.tokyo/post/2020/02/07/tee-command/
https://www.greptips.com/posts/189/

記事の初稿でリダイレクトの参照順の説明が誤っていたので訂正。ただ、詳しい仕組みは難しくて説明しきれないのでググって。 ↩︎

置換ができない/複数ある場合に sed の終了コード0以外にする

2021-12-04T00:20:20+09:00

本記事は、シェルスクリプト Advent Calendar 2021 の 4日目の記事だ。
そして、且つ docker Advent Calendar 2021 4日目の記事でもある。

どちらのカレンダーもまだまだスッカスカなので、禁じ手で埋めにかかってしまった。

Docker 公式イメージなどをベースにして、カスタムしてイメージをビルドして使おうとした際、なるべくなら /etc/apt/apt.conf.d/ 等のように、設定用のファイルを追加して、ツール側がいい感じにマージして利用してくれるのが望ましい。
しかし、場合によってはやむを得ず、既存のファイルを sed コマンドなどで編集せざるを得ないこともあるだろう。

カスタムイメージの Dockerfile をビルドする際に、当初は意図通り書き換えられていても、イメージが更新された結果、イメージのリビルド時にファイルの書き換えが意図しない結果となってしまう場合がある。 ¹

通常、 sed コマンドは、置換が発生してもしなくても、終了コード 0 で終了する。
このため、書き換えの成否にかかわらず、 docker build 時にエラーにならないため、コンテナ実行時に初めて置換が意図しない結果だったことに気づくことがある。

そこで、sed コマンドの書き換えで適切なパターンが見つからなかった場合に 0以外の終了コードを返し、ビルド時にエラーとする方法を考える。

以下、 sed は GNU sed を前提とし、 "行頭の foo" を BARfooBAR に置き換える場合の例。

ひとつもヒットしなかったら終了コード16 のエラー

まずは、書き換えるパターンが見つからなかった場合に、エラーコードを返す方法。

sed -e '/^foo/{s//BAR\0BAR/;h};$!b;p;x;/./Q;Q16'

参考: https://stackoverflow.com/a/15966279

ざっとコマンドの流れを解説すると、以下のようになる。

まず、正規表現アドレスで置換する行を選択する。
ブロック {} を用いて、正規表現に一致する行について以下を実行する。
1. s コマンドで、後方参照を使って FOObarBAR に置換する。
  空の正規表現 '//'は最後の正規表現のマッチを繰り返すので、正規表現アドレスでマッチした "行頭の foo" が置き換えられる。
2. h コマンドで、パターンスペースの内容をホールドスペース (sed 内のクリップボードみたいなもの) にコピーする。
$!b の部分は、最終行でなければ次のサイクルに移動する。すなわち、以降のコマンドは最終行でのみ実行される。
p コマンドでパターンスペースの内容を出力にプリントする。
x コマンドでパターンスペースの内容とホールドスペースをスワップする。
パターンスペースの内容は結果的に 、1度でも最初の正規表現がヒットすればその文字列に、最後まで一度も正規表現がヒットしなければ空っぽになる。
最後、パターンスペースの内容が空でない (即ち、1度以上正規表現がヒットした) なら、終了コード 0 で終了し、そうでなければ 16 で終了する。

ヒットしなければ終了コード16, 2つ以上ヒットしたら終了コード32 のエラー

さらに一歩踏み込んで、書き換えるパターンが見つからない場合と、 2つ以上見つかってしまった場合両方で、エラーにする方法。

sed -e '/^foo/{s//BAR\0BAR/;x;/./Q32;g};$!b;p;x;/./Q;Q16'

基本的な動きは、ひとつもヒットしなかったパターンと同じだ。
ただ、ブロック {} 内部のコマンドを以下のように変更して、複数ヒットした場合にエラーで終了している。

まず、正規表現アドレスで置換する行を選択する。
ブロック {} を用いて、正規表現に一致する行について以下を実行する。
1. s コマンドで、後方参照を使って FOObarBAR に置換する。
2. x コマンドでパターンスペースの内容とホールドスペースをスワップする。
  パターンスペースの内容は結果的に 、以前の行でも正規表現がヒットすればその文字列に、最後まで一度も正規表現がヒットしなければ空っぽになる。
3. パターンスペースの内容が空でない (即ち、正規表現のヒットが2回目) なら、終了コード 32 でエラー終了し、そうでなければそのまま次へ。
4. g コマンドでホールドスペースの内容をパターンスペースにコピーして戻す
以降は「ひとつもヒットしなかったら…」と同じ

なお、このコマンドは、 2つヒットした時点で出力が止まる。

おわりに

モダンなプログラミング言語が軒並み型推論でコンパイル時にエラーとするように、 Dockerfile もビルド時にエラーにしてしまおう。

カスタムイメージの Dockerfile ベースイメージを選択する際、基本的にはタグである程度絞っておくべきだが、それはさておき。 ↩︎

sed のブロック {} 内で i, r, e コマンドを使うと "unmatched `{'" とエラーになる

2021-12-04T00:00:04+09:00

本記事は、シェルスクリプト Advent Calendar 2021 の 3日目の記事だ。
3日目が終わりそうになっても誰も書きそうにないので、最近 sed コマンドでブロック {} を使っていたら、 "unmatched `{" というエラーにハマったので、そのメモ。

target.txt:

foo
bar
foo
bar
foo

insert.txt:

***

上記のような、2つのファイルがあったとする。

target.txt ファイルに対して、正規表現アドレスで bar から始まる行を選択し、その後ろに r コマンド insert.txt のファイルの中身を挿入する。

するとこんな結果になる。

$ sed -e '/^bar/rinsert.txt' target.txt
foo
bar
***
foo
bar
***
foo

では、アドレス指定の後ろにブロック {} を追加し、以下のように bar が2回以上ヒットしたらエラーコード出して終了するようにしてみる。

$ sed -e '/^bar/{rinsert.txt;x;/./Q129;g}' target.txt
sed: -e expression #1, char 0: unmatched `{'
$ echo $?
1

はい、別のエラーで失敗した。
ちゃんと { と } の数はマッチしているのに……

これは、 i, r, e などのコマンドは、コマンドの終了区切りに改行が必須となっていて、セミコロン (;) などで区切ろうとしても、その文字もコマンドのオプションとして渡されてしまうためだ。 ¹

これを回避する場合は、コマンドの後ろに改行を入れるか、 -e を使ってコマンド区切る必要がある。

$ sed -e '/^bar/{rinsert.txt' -e 'x;/./Q129;g}' target.txt
foo
***
bar
foo
***
$ echo $?
129

$ sed -e '/^bar/{rinsert.txt' -e 'x;/./Q129;g}' < foo
> bar
> foo
> foo
> EOF
foo
bar
***
foo
foo
$ echo $?
0

様々な区切り文字でつかわれるので忘れがちだけど、セミコロンをファイル名にすることだって、できるもんな。
そう考えれば納得。

ちなみに、同様の振る舞いをするコマンド ("Commands Requiring a newline") は、以下の通り。

a,c,i (append/change/insert)
# (comment)
r,R,w,W (reading and writing files)
e (command execution)
s///[we] (substitute with e or w flags)

command line - sed weirdness, unmatched { - Super User
sed, a stream editor #3.8.1 Commands Requiring a newline - GNU sed online manual
ストリームエディタ sed #3.8.1 sedコマンドに改行が必要な時 - GNU sed オンラインマニュアル ↩︎

シェルスクリプト内のエラーで実行を停止する「-e」と、実行コマンドを出力する「-x」オプションを使ったシェルスクリプトの開発

2020-01-04T00:49:50+09:00

「ソフトウェアデザイン2020年1月号」を読んでいるのですが、その中に次の一節がありました。

GitLab のCI に関する部分は.gitlab-ci.yml に書き、単独でも実行できる内容はシェルにまとめて、scriptで呼び出すのがお勧めです。
そうすると、.gitlab-ci.ymlに必要な事項だけがまとまって見やすくなるはずです。
しかし、シェルスクリプトにまとめてしまうと実行経過が見えなくなったりするので、シェルスクリプト内で実行過程を標準出力に出力するか、シェルスクリプトのshebang注C に「set -x」または
「set -xe」を付けることをお勧めします。

GitLab特集の記事ですが、CI上で実行するシェルスクリプトには、「set -x」または「set -xe」を付けようという内容です。

なぜ「set -x」または「set -xe」なのか、少し深堀ってみます。
これが理解できるようになると、CI以外の環境であっても、重要なオプションであることがわかります。

なお本記事では、「/bin/bash」を使用しております。

「-e」オプション（bash -e / set -e）

errexit -e：パイプやサブシェルで実行したコマンドが1つでもエラーになったら、直ちにシェルを終了する
https://www.atmarkit.co.jp/ait/articles/1805/10/news023.html より

シェルスクリプトを実行する際に「-e」を追加すると、エラーが起きたコマンドの時点でスクリプトが終了するようになります。

#!/bin/bash -e

# 存在しないファイルを閲覧しようとする
cat ./test1

# 以下は実行されない
cat ./test2
cat ./test3

$ /bin/bash -e test.sh
cat: ./test1: No such file or directory
$ echo $?
1 # 1が出力されるため、test.shが成功しなかったことがわかります

または「set -e」を使っても、同様にエラーが発生した時点で処理を止めることができます。

#!/bin/bash

# -o：シェルオプションを有効にする
set -e

# 存在しないファイルを閲覧しようとする
cat ./test1

# 以下は実行されない
cat ./test2
cat ./test3

# +o：シェルオプションを無効にする（-oによる設定を打ち消す）
set +e

「-e」オプションを使わない場合

自力で頑張る場合は、コマンドの終了ステータスを判定することによって、制御が可能です。

#!/bin/bash

cat ./test1

# コマンドの終了ステータスが「0」以外であれば、コマンドは成功していない
cmdstatus=$?
if [ $cmdstatus -ne 0 ]; then
    echo "command error!!"
    # 必要なら、ここで異常系フローの後処理ができる

    # 実行を終了させる
    exit $cmdstatus
fi

# 以下は実行されない
cat ./test2
cat ./test3

「-x」オプション（bash -x / set -x）

xtrace -x：トレース情報として、シェルが実行したコマンドとその引数を出力する。情報の先頭にはシェル変数PS4の値を使用
https://www.atmarkit.co.jp/ait/articles/1805/10/news023.html より

シェルスクリプトを実行する際に「-x」を追加すると、シェルが実行したコマンドを出力します。

#!/bin/bash -x

cat ./test1
cat ./test2
cat ./test3

$ /bin/bash -x test.sh
+ cat ./test1
cat: ./test1: No such file or directory
+ cat ./test2
cat: ./test2: No such file or directory
+ cat ./test3
cat: ./test3: No such file or directory

スクリプト内に「set -x」を記述する場合は、トレースしたい箇所の前後に追加します。

#!/bin/bash

set -x
cat ./test1
cat ./test2
cat ./test3
set +x

「-ex」は、シェルスクリプトのデバッグで役に立つ

これら2つのオプションは、組み合わせて使うことができます。

「-e」オプションによりエラーが起きた時点でスクリプトが終了しますが、「-x」オプションにより実行コマンドが逐一出力されるため、開発中やデバッグ時はとくに便利です。

#!/bin/bash -ex

# 存在しないファイルを閲覧しようとする
cat ./test1

# 以下は実行されない
cat ./test2
cat ./test3

$ /bin/bash -ex test.sh
+ cat ./test1
cat: ./test1: No such file or directory
# 「cat ./test1」でエラーが起きて失敗したことが、ひと目でわかる

CI上で実行されるシェルスクリプトのデバッグ

CI上でシェルスクリプトを動かす場合、基本的には自分の手の届かない範囲でスクリプトが実行さます。

でもシェルスクリプトの実行にデバッグオプションを付けておけば、CIのログを確認することで、スクリプトの実行確認やエラーの追跡がとてもやりやすくなります。

さいごに

アプリケーションのプログラミングでは、「try〜catch」をはじめとするエラー制御が必要であるという認識は普及しています。

一方で、シェルスクリプトにおいてもエラー処理や異常系を考慮して開発する必要があります。
これは意外と抜け落ちやすいので、忘れないようにしましょう（・・という戒めを込めた、自分向けの記事だったりします）。

ちなみに「ソフトウェアデザイン2020年1月号」にはGitLab特集があるのですが、私もGitLabは好きです。
実際に業務で使ってますが、CIがとても書きやすいです。

IPAのネットワークスペシャリスト試験の過去問一括ダウンロードスクリプト

2019-10-12T12:27:26+09:00

IPAのネットワークスペシャリスト試験の過去問を一括ダウンロードするスクリプト。
平成16年～平成20年は、午前がまとまっているので、午後の問題のみ。

スクリプトはこんな感じ

#!/bin/bash

# *****************************************************************************
# * ネットワークスペシャリスト試験の過去問一括ダウンロードスクリプト
# *****************************************************************************

first_year=16 # 平成16年から
last_year=30  # 平成30年まで

base_url='https://www.jitec.ipa.go.jp/1_04hanni_sukiru'
dl_dir='dist'

dl_pdf() {
  year_label="${1}h${2}"
  fname="$3"

  url="${base_url}/mondai_kaitou_${year_label}_2/${year_label}a_${fname}.pdf"
  echo "#### DOWNLOAD: ${url}"

  wget ${url} -P "./${dl_dir}"
  sleep 1  # 1秒待つ
}

rm -rf ${dl_dir}
mkdir ${dl_dir}

for i in `seq ${first_year} ${last_year} | sort -r`;do
  year="$((1988 + i))"
  year2="${i}"
  echo "${year} - ${year2}"
  if [ $year2 -gt 21 ]; then
    dl_pdf "$year" "$year2" 'nw_am2_qs'
    dl_pdf "$year" "$year2" 'nw_am2_ans'
    dl_pdf "$year" "$year2" 'nw_pm1_qs'
    dl_pdf "$year" "$year2" 'nw_pm1_ans'
    dl_pdf "$year" "$year2" 'nw_pm1_cmnt'
    dl_pdf "$year" "$year2" 'nw_pm2_qs'
    dl_pdf "$year" "$year2" 'nw_pm2_ans'
    dl_pdf "$year" "$year2" 'nw_pm2_cmnt'
  elif [ $year2 -gt 18 ]; then
    dl_pdf "$year" "$year2" 'nw_pm1_qs'
    dl_pdf "$year" "$year2" 'nw_pm1_ans'
    dl_pdf "$year" "$year2" 'nw_pm1_cmnt'
    dl_pdf "$year" "$year2" 'nw_pm2_qs'
    dl_pdf "$year" "$year2" 'nw_pm2_ans'
    dl_pdf "$year" "$year2" 'nw_pm2_cmnt'
  else
    dl_pdf "$year" "$year2" 'nw_pm1_qs'
    dl_pdf "$year" "$year2" 'nw_pm1_ans'
    dl_pdf "$year" "$year2" 'nw_pm2_qs'
    dl_pdf "$year" "$year2" 'nw_pm2_ans'
  fi
done

こんな感じで実行すると...

$ bash download_pdf_nw.sh 2>&1

こんな感じにdist配下にPDFをダウンロードしてきます。

あとは、好きなのを印刷すればOK(´ω｀)

システムアーキテクトやデータベーススペシャリスト版はこちら。
・システムアーキテクト試験の過去問一括ダウンロードスクリプト - くらげになりたい。
・データベーススペシャリスト試験の過去問一括ダウンロードスクリプト - くらげになりたい。

以上！！

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで♪

パイプで受け取った標準入力を列ごとに読みこんで配列っぽく処理したい

2019-10-11T01:39:47+09:00

最近、古いシェルスクリプトをリファクタリングしたので、そのときに使ったテクニックをここに残しておく。

コマンドをパイプでつないで、最終的に出力を行単位で読み込みたいときがある。例えば、以下のlsコマンドの出力から一番ファイルサイズが大きいやつを選びたいとする。

$ ls /tmp/
total 28
...
drwx------  2 root wheel   64 10  8 01:25 KSDownloadAction.dFCyHsIUZR
-rw-r--r--  1 root wheel    0 10  9 23:35 wetrsmuoutpDmR5aR
-rw-r--r--  1 root wheel    0 10  9 23:36 wetrsmuoutpalIXOW
...

レガシー（というかマナーが悪い）なコードだとこんな感じになる。

#!/usr/bin/env bash

set -eu

OLD_IFS="${IFS}"; IFS=$'\n'
max_size=0
max_filename=
ls_outpu="$(\ls -l /tmp/ | sed -e '1d' | grep -v '^d')"
for output in ${ls_outpu}
do
    filesize="$(echo "${output}" | awk '{print $5}')"
    filename="$(echo "${output}" | awk '{print $9}')"
    if [ "${filesize}" -gt "${max_size}" ]; then
        max_size="${filesize}"
        max_filename="${filename}"
    fi
done
IFS="${OLD_IFS}"

やりたいことはタイトルにあるように「パイプで受け取った標準入力を列ごとに読みこんで配列っぽく処理したい」なんだけど、上のコードはいくつか良くない点がある。

IFSを一時的に置き換えている。
空白区切りの行から特定位置の文字列を取り出すためにawkを使っている。
数字を比較している。

１つずつ説明する。

問題点と解決法

IFSを一時的に置き換えている。

これは古いシェルスクリプトだとよく見かけるけど、このやり方はメンテナンスが非常にやりにくくなり、本当に危ないのでやめたほうが良い。
まず、IFSはshellにおいて、文字列の区切りを示すもの。これを変えることで、文字列の区切りを変えることが出来る。

通常、IFSは半角スペース、タブ文字、改行の３つである。ここではls -lの出力を行ごとに読み込むために文字列の区切りを改行区切りにしている（そうしなければ、出力を１行ごとに列単位で扱うことになってしまう）。そして処理が完了したらIFSを元に戻している。

これ、最初に書いた人は良いけど、別の人がコードを保守するときに、この部分を見落としがちなのでバグが発生しやすくなるんだよね。コードを読む人は途中でIFSが変わったことを常に意識しながら読むことを強いられるので、コードの保守性が著しく悪くなる。

よって、IFSの置き換えは良くないのでやめましょう。ではどうすれば良いのかと言うと、ヒアドキュメントを使ってreadで読み込めば良い。

while read line
do
    ...
done <<< "$(ls -l /tmp/ | sed -e '1d' | grep -v '^d')"

すこし見づらくなるけど、こうすることでIFSの置き換えが不要になり、行ごとに変数lineの中に文字列が格納されるようになる。

もしかしたらこうしたほうが良いかも？と思う人がいるかもしれない。

ls -l /tmp/ | sed -e '1d' | grep -v '^d' | while read line
do
    ...
done

べつにこれでも良いのだけど、パイプで繋がれた処理はサブシェルで起動するということを思い出してほしい。今回のようにwhileのループ文の中で、事前に定義した変数を読み込みたい場合、つまり、以下のような場合、

max_size=0
max_filename=
ls -l /tmp/ | sed -e '1d' | grep -v '^d' | while read line
do
    filesize="$(echo "${output}" | awk '{print $5}')"
    filename="$(echo "${output}" | awk '{print $9}')"
    if [ "${filesize}" -gt "${max_size}" ]; then
        max_size="${filesize}"
        max_filename="${filename}"
    fi

done

ループ文中のmax_sizeとmax_filenameは先に定義したものとは別の変数として扱われる。その上、サブシェルなのでループ文を抜けると、その中にあった変数たちは参照できなくなる。なぜなら、サブシェルはメインのシェルとは違う世界なので。よって、パイプでつなぐのでなく、ヒアドキュメントで入力を受け取るようにしている。

もちろん、サブシェルで起動しても問題なければパイプで繋げばいいと思うけど、ヒアドキュメントを使えばサブシェルの起動を１つ減らせるので、リソースやパフォーマンスの面からもオススメしたいやり方だったりする。

空白区切りの行から特定位置の文字列を取り出すために`awk`を使っている。

awkって便利なのでよく使われているんだけど、大抵の場合、空白切りの文字列の特定の位置の文字を取り出すときに使われることが多い。手元のコマンドラインで使うとかだったら良いんだけど、データ処理とかバッチ処理のスクリプトで使っているとしたら、なるべく次に紹介する方法で置き換えたほうが良い。awkは重いし、思わず色々awkの中に処理を詰め込みがちになってしまうから。

オススメのリファクタリングとしては、setを使うこと。setというのは、よくシェルスクリプトの冒頭でset -euとかやると思うんだけど、そのset。これはbuilt-in関数なのでawkと違って別途にプロセスがforkされることがなくて軽い。

で、どういうふうにsetをawkの代わりに使うのかというと、以下のようになる。

...
    set -- ${output}
    filesize="${5}"
    filename="${9}"
...

これだけ。スッキリしてわかりやすくなったと思う。解説はman setで見れば良いと思うけど、ここに引用しておく。

Any arguments remaining after option processing are treated as values for the positional parameters and are assigned, in order, to $1, $2, ... $n.

--については以下の引用を参考。grepとかでもよく使うので知っている人は多いと思う。

-- If no arguments follow this option, then the positional
parameters are unset. Otherwise, the positional parame-
ters are set to the args, even if some of them begin with
a -.

つまり、set -- foo bar bazとやると、それぞれが$1, $2, $3に格納される。Pythonで言うところの*argsみたいな可変長引数みたいな感じで位置引数として利用することが出来る。これにより、もうawkを使ってわざわざechoしてパイプで…みたいなことをしなくて済む（もちろんIFSを変更していないことが前提である）。

副作用としては、シェルスクリプトに渡された位置引数を上書きすることになるので、そういった引数は事前に別の変数に格納しておくのを忘れないこと。

数字を比較している

これはなんのこっちゃと思うかもしれないけど、-gtや-neは本来は数値を比較するためのものであって数字を比較するものではない。つまり、文字列のままで数字を扱うのは危ないのでやめましょうということ。ではどうするかというと、以下のようにすれば良い。

    if [ $((filesize)) -gt $((max_size)) ]; then

シェルスクリプトで足し算とかするときに$((foo + bar))みたいなことをするとおもんだけど（もしexprを使っているなら即刻書き換えましょう）、上のようにすることで数字を数値にすることが出来る。これの何が良いかと言うと、もし変数の中身がアルファベットのような数字ではない文字だった場合はゼロとして扱われる。

$ a="aaa"
$ echo $((a))
0

状況によるが、変数が数字でなければゼロとして扱って差し支えない場合はこのようにすることで余計な数字判定の式を省くことが出来る。

まとめ

ということで、ここまでの内容をまとめると以下のようになる。

max_size=0
max_filename=
while read -r line
do
    set -- ${line}
    filesize="${5}"
    filename="${9}"
    if [ "$((filesize))" -gt "$((max_size))" ]; then
        max_size="${filesize}"
        max_filename="${filename}"
    fi
done <<< "$(\ls -l /tmp/ | sed -e '1d' | grep -v '^d')"

行数はほとんど変わらないけど、最初の方と比べるとわかりやすくなったかなと思う。特別な処理とかないし。ちなみに、もっとも大きいファイル名を取得するだけならls -S | head -1で一発で取れるので、わざわざこんなことをしなくて良い。

Nuxt.jsで未利用のVueコンポーネントを探すシェルスクリプト

2019-10-08T16:56:35+09:00

最近Nuxt.jsでWebアプリを作ってるけど、
度重なる改修でVueコンポーネントが乱立。。

使ってないのもたくさんありそうなので、調べるスクリプトを作ってみた。

スクリプトはこんな感じ

#!/bin/bash

# vueコンポーネントの一覧を取得
FILES=`find components -name "*.vue"`
for i in $FILES; do
  #  全体からコンポーネントをインクルードしている行の数を取得
  NUM=`grep -r "$i" * | wc -l | sed -e "s:[^0-9]*::g"`

  # ファイル名と見つけた件数を表示
  echo "** ${NUM}: ${i}"

  # grepした結果を表示(確認用)
  grep -r "$i" * 
  echo ""
done

こんな感じで出力されるので、** 0:で始まるコンポーネントを削除していけばOK。

** 1: components/Hero.vue
pages/index.vue:import Hero from "~/components/Hero.vue";

** 0: components/OgpUserStock.vue

** 0: components/Card.vue

** 3: components/atom/TotalNumBooks.vue
pages/clip/_uid.vue:import TotalNumBooks from "~/components/atom/TotalNumBooks.vue";
pages/read/_uid.vue:import TotalNumBooks from "~/components/atom/TotalNumBooks.vue";
pages/stack/_uid.vue:import TotalNumBooks from "~/components/atom/TotalNumBooks.vue";

確認用にgrepの結果を出しているけど、コメントアウトしたり、
NUMが0件のときは、結果を表示しないようにすればいい感じ。

もしくは、| grep "** 0:"で結果をgrepするとかでもいいかも。

appとかディレクトリを変えてる場合

こんな感じにapp配下とかに場所を変えている場合は、

app/
  pages/
  components/

こんな感じで、findする場所を変えればOK♪

#!/bin/bash

FILES=`find app/components -name "*.vue" | sed 's:app/::g'`
for i in $FILES; do
  NUM=`grep -r "$i" app/* | wc -l | sed -e "s:[^0-9]*::g"`
  echo "** ${NUM}: ${i}"
  grep -r "$i" app/* 
  echo ""
done

以上!!

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで♪

Windowsで快適なWebシステム開発を行えるか検証中

2018-07-30T06:37:43+09:00

僕はここ数年Linux MintというUbuntuベースのOSでWebシステム開発と日常の趣味活動の全てをまかなっていました。

PCの劣化に伴い新しいPCを購入したのですが、せっかくなのでWindows10 Proそのままでどこまで不便なくやっていけるか試してみました。

特に気になっていたところ

快適なシェル生活が可能か
Dockerは問題なく使えるか
ファイルの改行コードや属性など

シェル

Linuxの場合シェルはデフォルトでBashのため、あらゆることを何も深く考えずにスムーズに使うことができました。Windowsでもなるべく快適に使っていきたいところです。

シェルを使い分ける

Windows10の場合は下記のシェルが利用できます。

デフォルトのPowerShell
Git Bash（Gitインストール時にインストールされる）
Windows Subsystem for LinuxのBash

PowerShell

PowerShellは現在はWindowsのデフォルトのシェルになっています。使い方を見てみると、何やらよく分からない長い名前のコマンドがたくさん用意されているようです。例えばフォルダの移動はSet-Locationなど。

ただ、様々なコマンドにエイリアスが用意されていて、Linuxと同じコマンドも結構あります。例えばls, cd, cat等は普通に使えます。

他にもTabキーでパスを保管できたり、Ctrl+rでBashのようにコマンド履歴から検索したりすることができ、わりと使い勝手は悪くないです。あとは下記のURLにもあるように、設定を行えばGitの補完などもできるようになったりするようです。

Git - PowershellでGitを使う

僕も入れてみましたが、多分公式のGitHubの説明どおりに入れた方が良いと思います。色々変なやり方をするとエラーが出まくります。

dahlbyk/posh-git: A PowerShell environment for Git

インストールしてうまく動かなかったらPSModulePathという環境変数に、インストールされた自分のドキュメントフォルダ以下のWindowsPowerShell\Modulesのパスを入れておきましょう。

Windows Subsystem for Linux

通称WSLです。WindowsでUbuntu等のLinux環境を動作させることができます。Ubuntuを入れればUbuntuと全く同じコマンドを使うことができます。apt等も使用できます。

PowerShell上でwslと実行すれば開くことができますし、レジストリの設定をすればエクスプローラでォルダを右クリックして実行することなどもできます。WindowsにあるソフトウェアよりLinuxのソフトウェアを直で使った方が使い勝手が良い、という場合にかなり便利です。

Git Bash

Git BashはWindowsでGitをインストールすると同時にインストールされているものです。Windows上で気軽にBashを使うことができ非常に便利です。

Bashなら前述したWSLのBashを使えばいいのでは？　と思うかもしれませんが、WSLの方は完全に環境が独立してしまっているため、使いづらいところがあったりします。Git BashはWindowsの環境を共有していますので、Windowsのプログラムも実行できますし、パスや設定等もWindowsのものを共有していますし、何気に結構便利です。

このようにPowerShell, WSL, Git Bashを適切に使い分けていくとなかなか快適なシェル生活を過ごすことができます。

ソフトウェアなど

Windowsで使えるソフトウェア

Windowsだとやはりソフトウェアが充実しているので、何も考えずに色々使えるので安心です。Linux Mintの時はGitを操作する時はGitとTigとVisual Studio CodeのGit操作をそれぞれ使い分けていましたが、Windowsだと普通にSourceTreeが使えるので安心です。（ただ、何気にLinux MIntの時もその組み合わせだとむちゃくちゃ快適ではあったため特にSourceTreeを使う必要性は感じませんでした）

あとはWeb開発に関係ないですがちょっとしたゲームやソフトウェアをあまり深く考えずインストールできるというのはやはり安心できるところです。

Docker

Windows10もPro版であればDockerが使えます。時々うまく動かなくなったり回線が繋がらなくなったりする時があるのでLinuxの時ほど安定しているとは言い難いですが、特に不便はなく使えています。

以前Nortonを数年分買っていてまだ使えたためとりあえず入れていますが、DockerへのSamba接続を許可しないとvolumeが共有できなかったり、というところはあるのでちょっと気をつける必要があります。

Pro版でない人も、最近だとWSLの方でDockerが使える、といった情報があるようです。

言語env系

rbenvとかpyenvとかはWSLに入れました。Windowsだと対応していなかったりするため、直でUbuntu側に入れて使った方が良さそうでした。

あとはnvmなども入れています。一度Windowsに入れていたのですが、インストールするパッケージによってはビルド時にVisual Studioをインストールしていないとビルドできないものなどがあり、そんな重いものはインストールしたくなかったのでWSL側に入れました。

ただ、WSLに入れてしまうとエディタ連携などができないため、サーバーサイド系の言語はとりあえずWindows側にも最新のバージョンのものを入れておく、等が必要だったりします。そのため容量には少し気をつけなければなりません。Dockerだけでなんとかするよ、という人は何もインストールしなくて良いのかもしれませんが、ちょっとあれこれ全部満たすには面倒そうな気がしました。

Visual Studio Code

VSCodeはOS関係なく使えるので別に何も問題はないのですが、Windowsだとデフォルトの改行コードの設定がCRLFになっています。LFに設定を変えておきましょう。

Git

Gitも属性周りがちょっと怖いので、下記などを設定しておきましょう。

git config core.filemode false

Windowsメニューのランチャー

Windowsキーを押すとWindowsメニューが出てきますが、そこでそのまま文字入力をはじめると、実行したいアプリケーション等を適当に検索してそのまま実行すること等ができます。デフォルトでここまでできるとはあまりにも快適でびっくりしました。これはかなりプラス評価でした。

まとめ

色々書きましたが、とにかくシェルをいかに使っていくかがWindowsでの快適なWeb開発生活をおくれるかどうかの鍵になってくると思います。PowerShellだけだったら多分Windowsを使うという選択肢はなかったと思います。今のところLinuxの時とさほど変わらない快適度は保っていると思います（まだ新しいPCの方が高速なのでそれだけでも非常に快適）。

とはいえこれからもまた色々問題は出てくるかもしれません。実際に使い始めて数日はnpmでビルド失敗エラーが出たりDockerのvolumeが連携されなかったりで挫けそうになっていました。また色々と試していきます。