職場のスクリプトでローカルに生成したファイルの改行コードが CrLf になってしまって本質的な変更があるのかどうかもよくわからなかったので nkf を入れたんです。
参考にさせて頂いたページだとちょっと手順が足りなかったのと、ひとつ気になった事があったのでメモ
まず手順
まずは手順のほうを簡素に
$ mkdir -p ~/abs/nkf
$ cd ~/abs/nkf
$ wget https://ja.osdn.net/projects/nkf/downloads/70406/nkf-2.1.5.tar.gz
$ sha256sum ./nkf-2.1.5.tar.gz
d1a7df435847a79f2f33a92388bca1d90d1b837b1b56523dcafc4695165bad44 *./nkf-2.1.5.tar.gz
$ tar xzvf ./nkf-2.1.5.tar.gz
$ cd nkf-2.1.5
$ make nkf
$ make install
参考にさせて頂いたページだと make nkf が足りてなくて makefile を参照して付け足しました。
参考にしたページとの差
元々のページでは mkdir の最後のパラメーターを $_ として使って cd して (ここは特に問題ないというかむしろいい)、
curl の出力を標準出力に向けて、それをパイプで tar に渡していました。
かっこいいやり方だとは思う。
何度も同じ表現が出てこないし、ローカルに余分な物も残さないしね?
でも自分なら、特段の事情がないのであれば普通にローカルに保存してハッシュを確認して、それを tar で展開するやり方をお勧めします。
ネットワーク上から取得したリソースは本来ならどれだけ疑っても足りないくらい慎重になるべきで、提供側がハッシュ値も一緒に提供してくれてるのに、それを確認しないのは残念なやり方だと思います。
特にソースコードという形だと一般的なセキュリティ対策ソフトの目を潜り抜けてしまう可能性が高いと思うし、いざという時に情報は多く残っていた方がいい。
失敗した時こそ、まずかった理由が有耶無耶になるより明確に残っていたほうがありがたいはずです。
かっこよくやる事を意識したばかりに足元がお留守になってしまっては元も子もないですよね。
かっこいいやり方が優れたやり方とは限らないというお話でした。