Is it common to split larger script into multiple scripts and source them in the main script?

Is shell the right tool for the job at that point? As a developer who has bumped into issues of outgrowing code I can tell you that a rewrite should not be considered but instead considering separating out pieces into something better suited for the scale you are looking to grow your application - perhaps python or ruby or even perl?

Shell is a utility language - it's a scripting language - and so it will be hard to grow it to those sizes.


Yes, it is a common practice. For example, in the early days of Unix the shell code responsible for guiding the system through its boot phases to multiuser operation was a single file, /etc/rc. Today the boot process is controlled by many shell scripts, broken up by function, with common functions and variables sourced as needed from central locations. Linux distributions, Macs, BSDs, all have adopted this approach to varying degree.


If it makes your maintenance easier, you can have both. Split it up into logical parts so you can maintain it easily, then write (e.g.,) a Makefile to put it all back together for distribution You could write some quick scripts to copy the functions from the include file to the output file in place of the source line or just do something trivial like this (you'll have to re-tabify this, as make requires tabs):

all: myscript

myscript: includes/* body/*
    cat $^ > "$@" || (rm -f "$@"; exit 1)

You then have a "source" version (used for editing) and a "binary" version (used for trivial installation).

Tags:

Bash