Opening Text Files for Reading

    my $filename = "/some/path/to/a/textfile/goes/here";
    my $encoding = ":encoding(UTF-8)";
    my $handle   = undef;     # this will be filled in on success

    open($handle, "< $encoding", $filename)
        || die "$0: can't open $filename for reading: $!";

As with the shell, in Perl the "<" is used to open the file in read-only mode. If it succeeds, Perl allocates a brand new filehandle for you and fills in your previously undefined $handle argument with a reference to that handle.

Now you may use functions like "readline", "read", "getc", and "sysread" on that handle. Probably the most common input function is the one that looks like an operator:

    $line = readline($handle);
    $line = <$handle>;          # same thing

Because the "readline" function returns "undef" at end of file or upon error, you will sometimes see it used this way:

    $line = <$handle>;
    if (defined $line) {
        # do something with $line
    }
    else {
        # $line is not valid, so skip it
    }

You can also just quickly "die" on an undefined value this way:

    $line = <$handle> // die "no input found";

However, if hitting EOF is an expected and normal event, you do not want to exit simply because you have run out of input. Instead, you probably just want to exit an input loop. You can then test to see if an actual error has caused the loop to terminate, and act accordingly:

    while (<$handle>) {
        # do something with data in $_
    }
    if ($!) {
        die "unexpected error while reading from $filename: $!";
    }

A Note on Encodings: Having to specify the text encoding every time might seem a bit of a bother. To set up a default encoding for "open" so that you don't have to supply it each time, you can use the "open" pragma:

    use open qw< :encoding(UTF-8) >;

Once you've done that, you can safely omit the encoding part of the open mode:

    open($handle, "<", $filename)
        || die "$0: can't open $filename for reading: $!";

But never use the bare "<" without having set up a default encoding first. Otherwise, Perl cannot know which of the many, many, many possible flavors of text file you have, and Perl will have no idea how to correctly map the data in your file into actual characters it can work with. Other common encoding formats including "ASCII", "ISO-8859-1", "ISO-8859-15", "Windows-1252", "MacRoman", and even "UTF-16LE". See perlunitut for more about encodings.

Opening Text Files for Writing

If you want to preserve any existing contents, then you want to open the file in append mode. As in the shell, in Perl you use ">>" to open an existing file in append mode. ">>" creates the file if it does not already exist.

    my $handle   = undef;
    my $filename = "/some/path/to/a/textfile/goes/here";
    my $encoding = ":encoding(UTF-8)";

    open($handle, ">> $encoding", $filename)
        || die "$0: can't open $filename for appending: $!";

Now you can write to that filehandle using any of "print", "printf", "say", "write", or "syswrite".

As noted above, if the file does not already exist, then the append-mode open will create it for you. But if the file does already exist, its contents are safe from harm because you will be adding your new text past the end of the old text.

On the other hand, sometimes you want to clobber whatever might already be there. To empty out a file before you start writing to it, you can open it in write-only mode:

    my $handle   = undef;
    my $filename = "/some/path/to/a/textfile/goes/here";
    my $encoding = ":encoding(UTF-8)";

    open($handle, "> $encoding", $filename)
        || die "$0: can't open $filename in write-open mode: $!";

Here again Perl works just like the shell in that the ">" clobbers an existing file.

As with the append mode, when you open a file in write-only mode, you can now write to that filehandle using any of "print", "printf", "say", "write", or "syswrite".

What about read-write mode? You should probably pretend it doesn't exist, because opening text files in read-write mode is unlikely to do what you would like. See perlfaq5 for details.

Opening a pipe for reading

You could do this through opening an ordinary filehandle into each of those files, gradually building up an in-memory array of all the file contents you load this way, and finally sorting and filtering that array when you've run out of files to load. Or, you could offload all that merging and sorting into your operating system's own "sort" command by opening a pipe directly into its output, and get to work that much faster.

Here's how that might look:

    open(my $sort_fh, '-|', 'sort -u unsorted/*.txt')
        or die "Couldn't open a pipe into sort: $!";

    # And right away, we can start reading sorted lines:
    while (my $line = <$sort_fh>) {
        #
        # ... Do something interesting with each $line here ...
        #
    }

The second argument to "open", "-|", makes it a read-pipe into a separate program, rather than an ordinary filehandle into a file.

Note that the third argument to "open" is a string containing the program name ("sort") plus all its arguments: in this case, "-u" to specify unqiue sort, and then a fileglob specifying the files to sort. The resulting filehandle $sort_fh works just like a read-only ("<") filehandle, and your program can subsequently read data from it as if it were opened onto an ordinary, single file.

Opening a pipe for writing

Certainly you could write your own code to do this X or, once again, you could kick that work over to another program. In this case, "cat", running with its own "-n" option to activate line numbering, should do the trick:

    open(my $cat_fh, '|-', 'cat -n > numbered.txt')
        or die "Couldn't open a pipe into cat: $!";

    for my $line (@processed) {
        print $cat_fh $line;
    }

Here, we use a second "open" argument of "|-", signifying that the filehandle assigned to $cat_fh should be a write-pipe. We can then use it just as we would a write-only ordinary filehandle, including the basic function of "print"-ing data to it.

Note that the third argument, specifying the command that we wish to pipe to, sets up "cat" to redirect its output via that ">" symbol into the file "numbered.txt". This can start to look a little tricky, because that same symbol would have meant something entirely different had it showed it in the second argument to "open"! But here in the third argument, it's simply part of the shell command that Perl will open the pipe into, and Perl itself doesn't invest any special meaning to it.

Expressing the command as a list

    open(my $sort_fh, '-|', 'sort', '-u', glob('unsorted/*.txt'))
        or die "Couldn't open a pipe into sort: $!";

When you call "open" this way, Perl invokes the given command directly, bypassing the shell. As such, the shell won't try to interpret any special characters within the command's argument list, which might overwise have unwanted effects. This can make for safer, less error-prone "open" calls, useful in cases such as passing in variables as arguments, or even just referring to filenames with spaces in them.

However, when you do want to pass a meaningful metacharacter to the shell, such with the "*" inside that final "unsorted/*.txt" argument here, you can't use this alternate syntax. In this case, we have worked around it via Perl's handy "glob" built-in function, which evaluates its argument into a list of filenames X and we can safely pass that resulting list right into "open", as shown above.

Note also that representing piped-command arguments in list form like this doesn't work on every platform. It will work on any Unix-based OS that provides a real "fork" function (e.g. macOS or Linux), as well as on Windows when running Perl 5.22 or later.