------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Yes, but exporter "pollutes" the original scripts namespace, and you can end up, especially if you use the same set of subs for multiple scripts, getting incredibly confused as to where the sub is if you need to modify or otherwise examine it. Merely using require allows you to be precise as to which sub you want and where it is.

Using EXPORT_OK with Exporter lets you not only control which subroutines 'pollute' the caller's namespace, it is also self-documenting which subroutines get imported and where they come from when you say:

use MyFunctions qw(function1 function2 etc);
[download]

Any subs you don't want imported due to namespace collisions you can still call with MyFunctions::function(...)

Thanks =) Will look at that. First time actually using a seperate file for sub's, so I knew there was bound to be something ;)

First, I hope you mean that you're dividing your code into separate modules (using package) for a clean distinction among responsibilities. It is fundamental to creating maintainable software that you think critically about what parts of your code naturally belong together, and which ought to be split off into separate namespaces. The approach you're taking now feels easier to you as the author, because you're already familiar with the code. But the person coming along after you will have a terrible time making sense of the codebase.

Second, what you're seeing is the fact that the subroutine is returning the result of the last evaluated expression. Unless it's a number less than 1, undef, or the empty string, you had a success. So, the short answer to your question is that you can say return undef at the close of that sub if you really want it to be silent. However, there are three reasons (at least) that you do not want to do this:

1. if you don't want that value, don't test for it and don't use it, just let it go.
2. you may not want to test for the success of that sub, but someone else maintaining your code may wish to do so, and be very perplexed that this sub is returning a value that traditionally indicates failure.
3. testing for the success of subroutines is a Good Thing, and you should get in the habit.

I agree with fever completely, but I would suggest using a plain return; instead of return undef; in those cases where you want to return an undefined value. The plain return returns undef when called in scalar context and an empty list when called in list context, which is very handy (for example, if you are calling the subroutine through map and want the bits that don't return a value to be ignored altogether).