You already have been given very good advice here, so there is little for me to add - which is why i can as well quit pretending to be helpful and start to outright annoy you:

i think you tackle this from the wrong side alltogether!

Every software engineer learns about structured programming and its values and writing reusable pieces of code, yada, yada. But as every experienced software engineer can tell you structurisation - that is, breaking down the code to simple functions - is not only about reusing pieces of code and all the other tenets. One of its greatest benefits is that it breaks down long parts of the code into small manageable "chapters".

A former colleague of mine, principal senior coder in a large software project, even opined that a function - any function - that is longer than a screen full (he uses the same 80x40 xterm windows i prefer) should be broken down into parts, if not for anything else than for clarity of reading. Now, i think this strict stance is a bit of throwing the baby out with the bath water, but i can understand his sentiment. I try to apply this to my shell scripting all the time and - apart from a few exceptions, like commandline handling in scripts with many options - my functions are mostly fitting on one page of the 80x40 xterm i prefer.

Now, shell programming allows for a lot of bad behavior: undeclared variables made out of thin air, no real distinction between locals and globals and so on. I try to always work as strict as possible, meaning:

if i use a variable, i write a "typeset"-statement declaring it, using "typeset -i" if i intend to use it as an integer.

I admit publicly here that i am a devout user of Hungarian Style Notation, adapted to my needs as a shell programmer: i use, for instance, "f" as a prefix for file/directory names, even if there is no real datatype of a "path", whereas strings that can contain whatever are prefixed "ch" ("char" obviously). I also use "l" for switches, even though they are integers but should only contain 0 or 1. But it doesn't matter so much what you use: be consistent with yourself! If you use UPPERCASE for variables (personally i hate that, but that is just me) then ALWAYS use it - not sometimes this way and sometimes the other.

I ALWAYS stay away from that handy "export" keyword and the dot-feature (. command) - save for a few carefully selected exceptions. If a function needs a certain value from another function calling it, it has to be in the parameters. This way - usually even before i write that function - i have its "interface": which parameters it needs, which return values it produces, which output it creates - already laid out.

So, to sum it up: if you have thousands of lines of code and cannot keep track of your variables i suppose you should do a major code review and rewrite the parts where you needed a variable-tracker in the first place. After some serious restructuring of the code the need for such tools might just go away.

I hope this helps (ahh well, see above).

bakunin