on Manufactured Functions

simply names the generated function. It might be tied to the output file, since that's it's job, tied to an underlying function, it takes inputs and produces an output on the stderr. It may be possible in a multi-user world to have multiple named functions using the underlying command

is the minimum number of arguments to the underlying command. Usually these are files. Future enhancements may what to take account of the fact these are files. In the case of inputs using wild card names the pattern may not match any existing names, and the named function may fail the notargcount report.

not implemented yet, but this will account for the real data flow properties of a process. The planned values are blank or always, then newest, where the update process is busy enough to skip if none of the inputs are newer than the output, and finally, a append mode where the generated data is appended to the output, such as a log file.

the name of a file, which needn't exist at the command time, but is written to on the stdout of the command argument, contingent on the state of the mode.

this must exist as a function. At the moment, it must fail the notfunction test. Which is to say, a command found on the user's PATH won't cut it for the command name.

the name of a file, files, or a regular expression (RE) to identify a file or files. In the current incarnation, my investment house downloads CSV files, on my iMac Yosemite into files named ~/Downloads/Portfolio_{Positionsomething}.csv, where {something} is a browser-dependent date format. Our investment house uses a format: Mon-dd-YYYY … where the … is the browser-dependent part. For subsequent downloads (remember, my wife and I) Chrome uses " - (N)" and Safari is easier to deal with: "-N". In both cases, N > 1. Attempts to write a more specific RE proved more work than needed.

When the inputs have been digested, the output updated, then there may be some useful post-process. That's for the dispose function. It's first argument is the output followed by the inputs. backup is a convenient practice for the output. An empty argument is ignored.

This library is generated from the table above. Compare the code to the data in the table. The whole purpose of the table is to hide the considerable amount of boiler-plate code from routine editing. And make it easier to maintain the data-flow of the task at hand. Of the functions here, only fid2pos is a user function. The other two, mfgcmd and mfglibuse are central tools, for use by other sites or data-flow processes.

function fid2pos
{
	set -- ~/Downloads/Portfolio_Position_*.csv
	report_notargcount 2 $#		&& return 1
	report_notfunction fidToPosition     	&& return 2
	fidToPosition "$@" > position.rdb
	report_notfunction putArchive     	&& return 3
	putArchive position.rdb "$@"
	
}
function mfgcmd
{
	set -- command.lst
	report_notargcount 1 $#		&& return 1
	report_notfunction cmd2fun     	&& return 2
	cmd2fun "$@" > mfgcmdlib
	report_notfunction backup     	&& return 3
	backup mfgcmdlib "$@"
}
function mfglibuse
{
	set -- command.lst
	report_notargcount 1 $#		&& return 1
	report_notfunction mfguse     	&& return 2
	mfguse "$@" > mfguselib
	report_notfunction backup     	&& return 3
	backup mfguselib "$@"
}

Each of these functions pair-up with a manufactured function. e.g. fidToPosition is used in fid2pos This little table shows the /RDB layout from this command:

$ column < command.txt | column name mode output inputs | jm
name            mode    output          inputs                              
----            ----    ------          ------                              
fid2pos         always  position.rdb    ~/Downloads/Portfolio_Position_*.csv
mfgcmd          always  mfgcmdlib       command.txt                         
mfglibuse       always  mfguselib       command.txt   

Seems a convention might be established between the name and output fields. Given an output file, a function might be given a name:

$ name=$(basename ${output%.*})_mfg

We'll see

function fidToPosition
{ 
    rdb_hdr account symbol quantity;
    cat $* | fidPosition | egrep -v '(Account|download)' | sed 's/, */	/g; s/\*\*//'
}
function cmd2fun
{ 
    cat ${*:--} | column name nargs mode output command inputs dispose | tail +3 | tawk '
    function onl(tx,dn)     { printf "\t" tx "\n", dn; }
    function tnl(tx,dn,en)  { printf "\t" tx "\n", dn, en; }
    # 1 name    -- MUST have
    # 2 nargs
    # 3 mode:   always, append, newest, 
    # 4 output
    # 5 command
    # 6 inputs, an RE will do
    # 7 dispose
    $1 ~ /$^/  { next; }
               {
		 rc = 1;
                 onl("\nfunction %s\n{", $1)
                 onl("set -- %s",        $6)
                 tnl("report_notargcount %d $#\t\t&& return %d", $2, rc++)
                 tnl("report_notfunction %s     \t&& return %d", $5, rc++)
                 tnl("%s \"$@\" > %s",   $5,$4)
               }
   $7 !~ /$^/  {
                 tnl("report_notfunction %s     \t&& return %d", $7, rc++)
                 tnl("%s %s \"$@\"", $7, $4) }
               { onl("\n}", "") }
   '
}
function mfguse
{ 
    fbdy $(column command < $1 | tail +3)
}

Note, these latter functions are wrapped by their command.lst stored data, and that only the first command in either library is a user command, namely fidToPosition and it's manufactured user function: fid2pos. You may infer which investment house I use.