Bash Development Cycle

Orbos Bash Development Cycle.

When writing in bash I find the quickest development cycle is to get a very rough working version. The rough version is split up appropriately into functions.

From there if we do not actually call any of the functions that file turns into a library that we can use to make doing the overall task easier.

When changing the rough version over to functions this is often where I will do my optimizations. If the rough version has some repeated tasks that could be defined in another way and make it more efficient.

The original rough version may contain no loops, It may even have many elements of it hardcoded! It may just be "what would I type this into my terminal to get this done? Does it then run and work correctly? If the answer was no then I would make the modifications as required."

From there you can look at exactly what you need and break it down to be more efficient. Are there reoccuring elements within your code? If you answered yes then you can probably optimize that code and refine your initial idea into something great.

I often start with names for files that later on do not make sense but did when I started working on that file. For that reason I usually rename the library file to something more appropriate and recreate the initial file as a front end for users.

Its good to know when to stop, You generally do not want to create a monolithic behemoth. Using the method I've described in this article we end up with an API that we can extend and utilize to make computing easier and more fun.

Keeping things clean.

Bash Function and Variable Cleanup.

Most of the bash files that we have need a way to be cleaned up. In most cases each file called will have its own function to do so however some do not and are instead cleaned up by the file that calls them.

The exception being the orb file. Since its information is loaded by lib-build it is contained within lib-build.

All library files need to have their functions cleaned up either within the file or the file that calls the library. In most cases the file should clean up after itself but if a library is only use by a single function within another library then the calling library can do the clean up during its cleanup process.

After each function is declared the function name is added to an array that is name is the file name stripped of un-neccessary symbols combined with "functions". How variables are tracked are done the same way.

The first time a non-local variable is used it must defined in its respective "variables" array just like a function. This is done outside the function likely just below the functions array.