What is a script? A body of Perl code that executes straight through based on some global data (eg @ARGV), right?

What is a function? A body of Perl code that executes straight through, generally based on private data passed in through @_, right?

While there are some technical differences in how you write them, there is no real difference in what you can do with a script and a function. However what you have written to be called as a function can trivially be rewritten as a script that just calls that function. The converse is not true, what is written as a script may take more work to write as a function.

The upshot of this is that when you want to encapsulate a bunch of functionality, you are generally better off thinking about making it a function than making it a script. And you are better off reaching for functions than scripts.

If you apply that principle in this case, your problem resolves itself. Can you write a program that calls two functions, one to produce the main content and another to produce the side menu? The answer is that you can. And if you put the function for the side menu into a module, you can share that content across many pages very easily.

In fact that is basically how this site works. If you look at the page, you will see that it is broken up into various "nodelets". Filling in each nodelet is just a question of calling a function. And if you register for the site you will find out that what nodelets you have is itself configurable - and behind the scenes just represents a series of choices about which functions to call.

But the principle remains. Whenever possible, encapsulate functionality in a function, not a script. Do that consistently and you will find that a lot of technical problems resolve themselves very directly and naturally, in fact often so smoothly that you don't even notice that you might have had a problem if you had done things a different way.