Opens the file whose filename is given by EXPR, and associates it with FILEHANDLE.
Simple examples to open a file for reading:
and for writing:
(The following is a comprehensive reference to open: for a gentler introduction you may consider perlopentut.)
If FILEHANDLE is an undefined scalar variable (or array or hash element), a
new filehandle is autovivified, meaning that the variable is assigned a
reference to a newly allocated anonymous filehandle. Otherwise if
FILEHANDLE is an expression, its value is the real filehandle. (This is
considered a symbolic reference, so use strict "refs"
should not be
in effect.)
If three (or more) arguments are specified, the open mode (including
optional encoding) in the second argument are distinct from the filename in
the third. If MODE is <
or nothing, the file is opened for input.
If MODE is >
, the file is opened for output, with existing files
first being truncated ("clobbered") and nonexisting files newly created.
If MODE is >>
, the file is opened for appending, again being
created if necessary.
You can put a +
in front of the >
or <
to
indicate that you want both read and write access to the file; thus
+<
is almost always preferred for read/write updates--the
+>
mode would clobber the file first. You can't usually use
either read-write mode for updating textfiles, since they have
variable-length records. See the -i switch in perlrun for a
better approach. The file is created with permissions of 0666
modified by the process's umask value.
These various prefixes correspond to the fopen(3) modes of r
,
r+
, w
, w+
, a
, and a+
.
In the one- and two-argument forms of the call, the mode and filename
should be concatenated (in that order), preferably separated by white
space. You can--but shouldn't--omit the mode in these forms when that mode
is <
. It is safe to use the two-argument form of
open if the filename argument is a known literal.
For three or more arguments if MODE is |-
, the filename is
interpreted as a command to which output is to be piped, and if MODE
is -|
, the filename is interpreted as a command that pipes
output to us. In the two-argument (and one-argument) form, one should
replace dash (-
) with the command.
See Using open() for IPC in perlipc for more examples of this.
(You are not allowed to open to a command
that pipes both in and out, but see IPC::Open2, IPC::Open3, and
Bidirectional Communication with Another Process in perlipc for
alternatives.)
In the form of pipe opens taking three or more arguments, if LIST is specified (extra arguments after the command name) then LIST becomes arguments to the command invoked if the platform supports it. The meaning of open with more than three arguments for non-pipe modes is not yet defined, but experimental "layers" may give extra LIST arguments meaning.
In the two-argument (and one-argument) form, opening <-
or -
opens STDIN and opening >-
opens STDOUT.
You may (and usually should) use the three-argument form of open to specify I/O layers (sometimes referred to as "disciplines") to apply to the handle that affect how the input and output are processed (see open and PerlIO for more details). For example:
opens the UTF8-encoded file containing Unicode characters;
see perluniintro. Note that if layers are specified in the
three-argument form, then default layers stored in ${^OPEN} (see perlvar;
usually set by the open pragma or the switch -CioD
) are ignored.
Those layers will also be ignored if you specify a colon with no name
following it. In that case the default layer for the operating system
(:raw on Unix, :crlf on Windows) is used.
Open returns nonzero on success, the undefined value otherwise. If the open involved a pipe, the return value happens to be the pid of the subprocess.
On some systems (in general, DOS- and Windows-based systems) binmode is necessary when you're not working with a text file. For the sake of portability it is a good idea always to use it when appropriate, and never to use it when it isn't appropriate. Also, people can set their I/O to be by default UTF8-encoded Unicode, not bytes.
When opening a file, it's seldom a good idea to continue if the request failed, so open is frequently used with die. Even if die won't do what you want (say, in a CGI script, where you want to format a suitable error message (but there are modules that can help with that problem)) always check the return value from opening a file.
The filehandle will be closed when its reference count reaches zero. If it is a lexically scoped variable declared with my, that usually means the end of the enclosing scope. However, this automatic close does not check for errors, so it is better to explicitly close filehandles, especially those used for writing:
An older style is to use a bareword as the filehandle, as
Then you can use FH
as the filehandle, in close FH
and <FH>
and so on. Note that it's a global variable, so this form is
not recommended in new code.
As a shortcut a one-argument call takes the filename from the global scalar variable of the same name as the filehandle:
Here $ARTICLE
must be a global (package) scalar variable - not one
declared with my or state.
As a special case the three-argument form with a read/write mode and the third argument being undef:
opens a filehandle to a newly created empty anonymous temporary file.
(This happens under any mode, which makes +>
the only useful and
sensible mode to use.) You will need to
seek to do the reading.
Perl is built using PerlIO by default. Unless you've
changed this (such as building Perl with Configure -Uuseperlio
), you can
open filehandles directly to Perl scalars via:
To (re)open STDOUT
or STDERR
as an in-memory file, close it first:
See perliol for detailed info on PerlIO.
General examples:
- open(my $log, ">>", "/usr/spool/news/twitlog");
- # if the open fails, output is discarded
- open(my $dbase, "+<", "dbase.mine") # open for update
- or die "Can't open 'dbase.mine' for update: $!";
- open(my $dbase, "+<dbase.mine") # ditto
- or die "Can't open 'dbase.mine' for update: $!";
- open(my $article_fh, "-|", "caesar <$article") # decrypt
- # article
- or die "Can't start caesar: $!";
- open(my $article_fh, "caesar <$article |") # ditto
- or die "Can't start caesar: $!";
- open(my $out_fh, "|-", "sort >Tmp$$") # $$ is our process id
- or die "Can't start sort: $!";
- # in-memory files
- open(my $memory, ">", \$var)
- or die "Can't open memory file: $!";
- print $memory "foo!\n"; # output will appear in $var
You may also, in the Bourne shell tradition, specify an EXPR beginning
with >&
, in which case the rest of the string is interpreted
as the name of a filehandle (or file descriptor, if numeric) to be
duped (as in dup(2)) and opened. You may use &
after >
,
>>
, <
, +>
, +>>
, and +<
.
The mode you specify should match the mode of the original filehandle.
(Duping a filehandle does not take into account any existing contents
of IO buffers.) If you use the three-argument
form, then you can pass either a
number, the name of a filehandle, or the normal "reference to a glob".
Here is a script that saves, redirects, and restores STDOUT
and
STDERR
using various methods:
- #!/usr/bin/perl
- open(my $oldout, ">&STDOUT") or die "Can't dup STDOUT: $!";
- open(OLDERR, ">&", \*STDERR) or die "Can't dup STDERR: $!";
- open(STDOUT, '>', "foo.out") or die "Can't redirect STDOUT: $!";
- open(STDERR, ">&STDOUT") or die "Can't dup STDOUT: $!";
- select STDERR; $| = 1; # make unbuffered
- select STDOUT; $| = 1; # make unbuffered
- print STDOUT "stdout 1\n"; # this works for
- print STDERR "stderr 1\n"; # subprocesses too
- open(STDOUT, ">&", $oldout) or die "Can't dup \$oldout: $!";
- open(STDERR, ">&OLDERR") or die "Can't dup OLDERR: $!";
- print STDOUT "stdout 2\n";
- print STDERR "stderr 2\n";
If you specify '<&=X'
, where X
is a file descriptor number
or a filehandle, then Perl will do an equivalent of C's fdopen(3) of
that file descriptor (and not call dup(2)); this is more
parsimonious of file descriptors. For example:
or
or
Being parsimonious on filehandles is also useful (besides being
parsimonious) for example when something is dependent on file
descriptors, like for example locking using
flock. If you do just
open(my $A, ">>&", $B)
, the filehandle $A
will not have the
same file descriptor as $B
, and therefore flock($A)
will not
flock($B)
nor vice versa. But with open(my $A, ">>&=", $B)
,
the filehandles will share the same underlying system file descriptor.
Note that under Perls older than 5.8.0, Perl uses the standard C library's'
fdopen(3) to implement the =
functionality. On many Unix systems,
fdopen(3) fails when file descriptors exceed a certain value, typically 255.
For Perls 5.8.0 and later, PerlIO is (most often) the default.
You can see whether your Perl was built with PerlIO by running
perl -V:useperlio
. If it says 'define'
, you have PerlIO;
otherwise you don't.
If you open a pipe on the command -
(that is, specify either |-
or -|
with the one- or two-argument forms of
open), an implicit fork is done,
so open returns twice: in the parent process
it returns the pid
of the child process, and in the child process it returns (a defined) 0
.
Use defined($pid)
or //
to determine whether the open was successful.
For example, use either
or
followed by
The filehandle behaves normally for the parent, but I/O to that filehandle is piped from/to the STDOUT/STDIN of the child process. In the child process, the filehandle isn't opened--I/O happens from/to the new STDOUT/STDIN. Typically this is used like the normal piped open when you want to exercise more control over just how the pipe command gets executed, such as when running setuid and you don't want to have to scan shell commands for metacharacters.
The following blocks are more or less equivalent:
- open(my $fh, "|tr '[a-z]' '[A-Z]'");
- open(my $fh, "|-", "tr '[a-z]' '[A-Z]'");
- open(my $fh, "|-") || exec 'tr', '[a-z]', '[A-Z]';
- open(my $fh, "|-", "tr", '[a-z]', '[A-Z]');
- open(my $fh, "cat -n '$file'|");
- open(my $fh, "-|", "cat -n '$file'");
- open(my $fh, "-|") || exec "cat", "-n", $file;
- open(my $fh, "-|", "cat", "-n", $file);
The last two examples in each block show the pipe as "list form", which is not yet supported on all platforms. A good rule of thumb is that if your platform has a real fork (in other words, if your platform is Unix, including Linux and MacOS X), you can use the list form. You would want to use the list form of the pipe so you can pass literal arguments to the command without risk of the shell interpreting any shell metacharacters in them. However, this also bars you from opening pipes to commands that intentionally contain shell metacharacters, such as:
See Safe Pipe Opens in perlipc for more examples of this.
Perl will attempt to flush all files opened for
output before any operation that may do a fork, but this may not be
supported on some platforms (see perlport). To be safe, you may need
to set $ ($AUTOFLUSH
in English)
or call the autoflush
method of IO::Handle
on any open handles.
On systems that support a close-on-exec flag on files, the flag will be set for the newly opened file descriptor as determined by the value of $^F . See $^F in perlvar.
Closing any piped filehandle causes the parent process to wait for the child to finish, then returns the status value in $? and ${^CHILD_ERROR_NATIVE} .
The filename passed to the one- and two-argument forms of open will have leading and trailing whitespace deleted and normal redirection characters honored. This property, known as "magic open", can often be used to good effect. A user could specify a filename of "rsh cat file |", or you could change certain filenames as needed:
Use the three-argument form to open a file with arbitrary weird characters in it,
otherwise it's necessary to protect any leading and trailing whitespace:
(this may not work on some bizarre filesystems). One should conscientiously choose between the magic and three-argument form of open:
will allow the user to specify an argument of the form "rsh cat file |"
,
but will not work on a filename that happens to have a trailing space, while
will have exactly the opposite restrictions. (However, some shells
support the syntax perl your_program.pl <( rsh cat file )
, which
produces a filename that can be opened normally.)
If you want a "real" C open(2), then you should use the sysopen function, which involves no such magic (but uses different filemodes than Perl open, which corresponds to C fopen(3)). This is another way to protect your filenames from interpretation. For example:
See seek for some details about mixing reading and writing.
Portability issues: open in perlport.