To re-iterate what Sinan said, the shopping cart needs to be done using sessions.
I will try to explain a bit more about how it all works, since your question seems to imply you would like to understand the details.
There are two concepts that are involved: A Session Cookie, and a Session database on the server side.
Your web server has an internal "sessions" database - which is basically a mapping between a long string known as the "Session Key" and a blob of data. This database can be built into the web server, or in case of Perl CGI, be implemented by a special Perl module.
What gets stored in this blob of data in a Session database? Anything your CGI script decides to store - in your case, the current state of the shopping cart.
How does the information get shared between the pages? A special "Session Cookie" is generated by your session module, with the value of the cookie being the same "Session Key" used to store the blob of data on the server in session database. It is then stored by the user's browser like all the other cookies, except its value is only valid "for the duration of a session" - it expires after a short period of time or if you close your browser. Then, when the user continues with the web app, the cookie value gets sent back to the server and therefore your CGI script knows to re-use that session key.
NOTE: An alternate approach (instead of using a cookie) is to pass the session ID value between all your requests (e.g. code it into all GET URLs and POST forms).
As far as Perl CGI implementation, it depends on the specific Perl web framework you use - the basic session work can be done using CGI::Session
CPAN module (there is a good tutorial for it as well). Another frequent option for those using Apache web server is Apache::Session
.
What a general Session related module does is provide you with the APIs to:
- Manage Session database
- Store/retrieve data in Session database using Session key (aka Session ID)
- Obtain the user's current session ID (from the session cookie value), if any
- Generate a new session ID for the user, if needed
- Send the session ID value as a cookie to be stored in HTTP response to user's browser.
Any decent Perl web framework has session capabilities built in (they are still implemented using some sort of Session management Perl module, but the framework provides easy-to-use APIs.
As an example of "easy to use", in Embperl, to store a value in a session, all you do is $udat{shopping_cart} = \%shopping_cart_data
and to retrieve it you do %shopping_cart_data = %$udat{shopping_cart}
- %udat
being a special hash name). That's it. All the details hidden from you by the framework.
UPDATE:
This has pretty much nothing to do with what seems to me the actual question being asked, but it's nevertheless a valid point that a comment to this answer made me think of.
In the interest of improving the overall quality of your code, you should always abstract away as much of the general business logic. In this case, if you have any generic logic for working with the shopping cart data which is shared between your different Perl CGI scripts, that logic should be abstracted away into a separate Perl module.
In addition, as further improvements:
You should consider MVC (model-view-controller) design for any complicated web app. To make this easier, pick an MVC-compliant Perl web framework (I think Catalyst is considered the main option these days but do your own research before setting on one.
You should also have a design that allows you to modularize and re-use web (view) elements - e.g. the top var of the application that probably will display # of items in the shopping cart would always be pretty much the same HTML, and you should not duplicate that HTML across different views. (if you aren't sure what I'm talking about, look at top 2 lines on Amazon's web page). There are different techniques for achieving that, which go well beyond the scope of your question (frames, web frameworks with merged views, Perl module for View printing, etc...).