共通処理の外部ファイル化のメリット・デメリット

[KEINOS]

汎用的なユーザ関数を外部ファイル化して .（bash で言う source）でインポートして利用する場合の弊害の洗い出し

#33 (comment) でも言及されているように、curl で公開鍵を取得するなど同じ処理を行なっています。

今後、OS や環境ごとの分岐や、curl wget fetch の分岐に対応する必要が出てきた場合、それらを利用しているスクリプト全部に反映させるのが面倒なのとコピペミスや更新忘れが発生しそうです。（直感がヒシヒシと言っています）

最終的には、これらの汎用的な処理を外部ファイル化したいです。

テストもスムーズになるし、何よりポカ避けになります。

ただ、ユーザが「archive のコマンドだけが欲しい」場合にアレコレとダウンロードが必要になります。パッケージ・マネージャーなどでインストールできるならいいのですが。

大手アプリであるような、ジェネレーター（src ディレクトリで処理を分散させておいて make コマンドで 1 ファイル化させて bin に出力）を用意するという方法もあるかもしれません。

外部ファイル化するのは、ほぼほぼ決定なのですが、その弊害を知っておきたいです。

「あー、●● なとき ●● になるかもなぁ」的なことありますかね？

• 外部ファイル化のメリット・デメリット一覧

PROS（メリット）	CONS（デメリット）
	コマンドの依存ファイルが増える
修正が楽
テストの作成が楽
	make で 1 ファイル化するにしても仕組み作りがたいへん

[yoshi389111]

共通化やりたい気はしますね。思いつくデメリットは、やはりファイルが増えることだと思います。

---

シェルを統合するツールは、有名どころは存在しない感じなんですかね。

とりあえず、見かけたものを参考として。

• シェルスクリプトを共有してマージするshsubrmerge
• 車輪の再発明：Bashライブラリ内の関数定義をShellScriptにマージするlibMerge

[KEINOS]

おぉ。shsubrmerge が一番らくですかね。シェルで完結してるし。

StackOverflow に . source を置換する方法がありましたが、エスケープが必要だったりを考えると、やるなら shsubrmerge を使った方がいいかも。

• answer | Replacing 'source file' with its content, and expanding variables, in bash
  @ StackOverflow

shsubrmerge のライセンスですが、CodeZine の規約を読むと記事の URL かライセンスと著者情報を明記すれば改変・プログラム開発に使っていいようです。ソースを見ると BSD ライセンスっぽいですね。

shsubrmerge のライセンス表記

#!/bin/sh
#
# Copyright (c) 2005 Daichi GOTO <daichi@ongs.co.jp>
# All rights reserved.
# 
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 
# 1. Redistributions of source code must retain the above copyright 
#    notice, this list of conditions and the following disclaimer. 
# 2. Redistributions in binary form must reproduce the above copyright 
#    notice, this list of conditions and the following disclaimer in the 
#    documentation and/or other materials provided with the distribution.
# 
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
# PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS
# BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER 
# IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
# THE POSSIBILITY OF SUCH DAMAGE.

# author: Daichi GOTO (daichi@ongs.co.jp)
# first edition: Tue Mar 22 20:35:43 2005
# last modified: $Date: 2005/04/21 06:47:32 $
# version: $Revision: 1.7 $

もし、shsubrmerge を使うとしたら 2005 年のソースなので GitHub に別途リポジトリをフォークして使った方がいいのかな。

[KEINOS]

shsubrmerge が一番らくですかね。シェルで完結してるし。

前言撤回です。

海外でもニーズはありそうだし、と shsubrmerge の fork リポジトリ（非公開なう）は作ったのですが、触ってみてチョッと悩んでいます。

1. そもそも動かない
2. 仕様により汎用性がない
3. もっとシンプルなもので良い気がする

まず、FreeBSD 用として作られたからか、動きません。 😭

オリジナルのソースにバグというかコピー漏れがある気がします（v1.7 の 129 行目）。FreeBSD の構文なのかもしれませんが、確認しようにも Docker では環境が作れませんでした。

また、以下の仕様があり QiiCipher のニーズにあわせるには、いささか手直しが必要そうです。

1. "."(source) でインポートするファイル名は .shsubr 固定である
2. .shsubr は shsubrmerge コマンドと同じ階層に置いておかないといけない
3. "."(source) でインポートする場合の構文は . "${0%/*}"/.shsubr で . /path/to/.shsubr のようにできない

そして最後に気になるのが、Python 版の libMerge もそうなのですが、ソース先の「関数」を抜き出して埋め込むという動作であることです。

欲しいのはもっとシンプルなものです。

1. . /path/to/function.sh の行があったら、/path/to/function.sh からシバンを削除して置換する
2. shfmt をかましてフォーマットを整えたものを出力する

これだけです。

でも、この処理をスクラッチから作るんだったら、shsubrmerge を手直しすれば 156 行程度だし POSIX 汎用化はできそうな感じはあるため動くようにして、それをベースにしてもいいんじゃないかとも思うのです。

とりあえず、進捗報告としてジレン魔に陥っているという報告でした。

[KEINOS]

なんか勢いで置換スクリプトをスクラッチから作ってしまいました！

• https://github.com/Qithub-BOT/OlioSource

Olio は「ごった煮」という意味で Source を 1 つの鍋にごった煮するイメージです。