Documentation for routine
open assembled from the following types:
From Independent routines
multi sub open(IO() , |args --> IO::Handle)
Creates a handle with the given
$path, and calls
IO::Handle.open, passing any of the remaining arguments to it. Note that IO::Path type provides numerous methods for reading and writing from files, so in many common cases you do not need to
open files or deal with IO::Handle type directly.
my = open :w, '/tmp/some-file.txt';.say: 'I ♥ writing Perl code';.close;= open '/tmp/some-file.txt';print .readchars: 4;.seek: 7, SeekFromCurrent;say .readchars: 4;.close;# OUTPUT: «I ♥ Perl␤»
method open(IO::CatHandle: --> IO::CatHandle)
Returns the invocant. The intent of this method is to merely make CatHandle workable with things that open IO::Handle. You never have to call this method intentionally.
method open(IO::Path: *)
Opens the path as a file; the named options control the mode, and are the same as the open function accepts.
method open(IO::Handle::, :, :, :, Str :,Str :,:, :, :, :, :, :, :, :,:, :, :, :,:,--> IO::Handle)
Opens the handle in one of the modes. Fails with appropriate exception if the open fails.
See description of individual methods for the accepted values and behavior of
:$enc. The values for parameters default to the invocant's attributes and if any of them are provided, the attributes will be updated to the new values. Specify
:$bin set to
True instead of
:$enc to indicate the handle should be opened in binary mode. Specifying undefined value as
:$enc is equivalent to not specifying
:$enc at all. Specifying both a defined encoding as
:$bin set to true will cause
X::IO::BinaryAndEncoding exception to be thrown.
The open mode defaults to non-exclusive, read only (same as specifying
:r) and can be controlled by a mix of the following arguments:
:r same as specifying :mode<ro> same as specifying nothing:w same as specifying :mode<wo>, :create, :truncate:a same as specifying :mode<wo>, :create, :append:x same as specifying :mode<wo>, :create, :exclusive:update same as specifying :mode<rw>:rw same as specifying :mode<rw>, :create:ra same as specifying :mode<rw>, :create, :append:rx same as specifying :mode<rw>, :create, :exclusive
Support for combinations of modes other than what is listed above is implementation-dependent and should be assumed unsupported. That is, specifying, for example,
.open(:r :create) or
.open(:mode<wo> :append :truncate) might work or might cause the Universe to implode, depending on a particular implementation. This applies to reads/writes to a handle opened in such unsupported modes as well.
The mode details are:
:mode<ro> means "read only":mode<wo> means "write only":mode<rw> means "read and write":create means the file will be created, if it does not exist:truncate means the file will be emptied, if it exists:exclusive means .open will fail if the file already exists:append means writes will be done at the end of file's current contents
Attempts to open a directory, write to a handle opened in read-only mode or read from a handle opened in write-only mode, or using text-reading methods on a handle opened in binary mode will fail or throw.
In 6.c language, it's possible to open path
'-', which will cause
open to open (if
$*IN handle if opening in read-only mode or to open the
$*OUT handle if opening in write-only mode. All other modes in this case will result in exception being thrown.
As of 6.d language version, use path
'-' is deprecated and it will be removed in future language versions entirely.
:out-buffer controls output buffering and by default behaves as if it were
Nil. See method out-buffer for details.
Note (Rakudo versions before 2017.09): Filehandles are NOT flushed or closed when they go out of scope. While they will get closed when garbage collected, garbage collection isn't guaranteed to get run. This means you should use an explicit
close on handles opened for writing, to avoid data loss, and an explicit
close is recommended on handles opened for reading as well, so that your program does not open too many files at the same time, triggering exceptions on further
Note (Rakudo versions 2017.09 and after): Open filehandles are automatically closed on program exit, but it is still highly recommended that you
close opened handles explicitly.