Application (app) Requirements

1. The application family must have a main subfunction to handle the first function call in the single application.
2. The application family must have an entry subfunction returning the names of the various entry points to the application.
3. The application family must have a scripts subfunction returning the names of the scripting applications used in the functions. It may return nothing.

1. A tool to recursively descend the entry_points function call graph, returning the names of the called functions.
2. Construct a stand-alone library containing all the functions, storing in an _app suffix

1. Identify and collect the various script files
2. Identify and provide for download of locally installed tools. Non /bin, /usr/bin, e.g. /usr/local/bin

1. Identify supported O/S, Bash Version
2. Identify versions of system /bin, /usr/bin tools

1. Wrap the stand-alone _app library with an entry point function call
2. replace return codes as exit.

An entry subfunction looks like this:

graf_entry () 
{ 
    : date: 2020-01-22;
    ${*:-echo} graf graf_copy graf_entry graf_init graf_list graf_main graf_prep graf_scenario
}

A single entry point is turned into an application, in this example a file on the user's PATH named family_subfunction

#! /bin/bash
 ... { the text of family_app } ...
family_main "$@"

A user function finds all the files used by local tools

for suf in $(script_sufs $(family_scripts))
do
    find ${1:-$BASE_DIRECTORY} -name "*.$suf"
done

where script_suf converts application names to appropriate file suffix. Or returns it's argument

The practice documented here is all about developing bash shell functions. In my opinion, the use of functions in bash, while readily accessible, is under-appreciated, under-used. Pick one of these approaches to the material, based on your needs and interests.

Three definitions define sets of functions, distinguishing the need for the collection: the app, family, and library. The library is the most general, the app being the most specific. The relationship is discussed in The Standard Function Library.

Where these definitions appear in requrements documents, they assume a certain implementation, in particular the definition of a tag. Since the null-operator, a gift from the shell designers, uses the colon, it seems appropriate to use the colon as the distinguishing feature of a tag, .e.g.

date: 2020-02-20  this change ....

• app – a set of functions collected to serve a set of requirements
• canonical function – a function when formatted declare -f function_name
• entry point – in an app, a function called only from the command line,
• family – a set of functions sharing common stem, e.g. family_subfunction
• library – a set of functions with zero or more families
• local function – a function used only within another function
• null operator – a shell command beginning with a :
• semantic comment – a shell function which may not display its arguments, or display them on standard error
• shell script – a shell file, whose first line is a sh-bang: #! env bash
• shdoc – a function family which implements Shell Documentation, see the Standard Function Library
• source – a builtin shell command to source or load a function library
• standard function – a function which meets the requirements of The Function Standard
• standard library – a library meeting the requirements of The Library Standard
• subfunction – a member of a function family
• tag – a colon-terminated first argument to the null command

These local papers are housed in the author's section of his commonplace book, which references The Function Standard