See Dominus' very very short tutorial about modules in Perl.

In the most simple case, you could just include the file using require. Unless you tell Perl otherwise (using a package ... declaration), everything will end up in the same namespace (i.e. main::). So yes, the variable $hello will be known within the included routine.

routines.pl

sub hello {
    print $hello;
}

1; # need to end with a true value
[download]

mainscript.pl

#!/usr/bin/perl

require "./routines.pl";  # assuming it's in the current directory

$hello="hello123";
hello();                  # prints "hello123"
[download]

Having said that, do use modules instead (with their own separate namespaces) for anything larger. This will help keep the mess to a minimum, which would otherwise ensue when the code grows... Same holds for global variables (like your $hello), so try to make judicious use of them...   In other words, you'd more typically pass $hello as an argument to the function, e.g.

sub hello {
    my $hello_msg = shift;
    print $hello_msg;
}

# ...

$hello="hello123";
hello($hello);
# or just:
# hello("hello123");
[download]

In the second place you also don't have a module - see perlmod for how to construct the Perl equivalent of a shared library. I presume you are loading the non-module routines.pl using require - that is really the Perl equivalent of a #INCLUDE in C.

The short answer to the question is "yes" because $hello is global BUT you don't really want to rely on global variables because then you make your "library" dependent on what is defined as global for particular main routines - that's not good code design. Better is to pass parameters to your "shared" subroutines, e.g.:

#!/usr/bin/perl
# main program;

use strict;
use warnings;
use Routines;;

{ # closure to avoid global variables
    my $hello = "hello123;

  # ...

    hello( $hello );    

}
__END__

# Routines.pm - a separate file called a "module"

package Routines;
sub hello {
    my $hello = shift;
    print "$hello\n";
}

1;
[download]

Code reuse is a wonderful thing. You are getting great advice here. Use modules (see perlmod) and avoid globals, pass data to subs as arguments.

If you must use globals, you can either use package globals or import your variables so that you can see them in your main script. I'll show you how to specify the package of variables and subroutines here. Exporting/importing symbols is a bit more complex, so I'll leave that to the proper documentation.

File Foo.pm:

package Foo;

my $hello;

sub hello {
    print "$hello\n";
    return;        # I like explicit returns.
}
[download]

File myscript.pl:

use strict;
use warnings;

use Foo;

$Foo::hello = 'hello';

Foo::hello();  #prints "hello\n"
[download]

Also, ditch the unneeded & sigil from your subroutine calls. It can have unexpected consequences. Here are the relevent bits from perlsub, with emphasis added:

...If a subroutine is called using the & form, the argument list is optional, and if omitted, no @_ array is set up for the subroutine: the @_ array at the time of the call is visible to subroutine instead. This is an efficiency mechanism that new users may wish to avoid.
...
Not only does the & form make the argument list optional, it also disables any prototype checking on arguments you do provide. This is partly for historical reasons, and partly for having a convenient way to cheat if you know what you're doing. See Prototypes below.

See perlsub for more details.

I think I need to put together a meditation - Ampersand Considered Harmful...

Well, on modern Perl incarnations, I have to do:

our $hello;
[download]

instead of

my $hello;
[download]

It will not print the string in that variable, if I use my. Otherwise, thanks. Yet another soul got a door opened to Perl Modules.