openFile

The computation openFile path mode returns a file handle that can be used to interact with the file. The handle is open in text mode with localeEncoding. You can change the encoding with hSetEncoding.
Open a file and make an FD for it. Truncates the file to zero size when the IOMode is WriteMode. This function is difficult to use without potentially leaking the file descriptor on exception. In particular, it must be used with exceptions masked, which is a bit rude because the thread will be uninterruptible while the file path is being encoded. Use openFileWith instead.
Computation openFile file mode allocates and returns a new, open handle to manage the file file. It manages input if mode is ReadMode, output if mode is WriteMode or AppendMode, and both input and output if mode is ReadWriteMode. If the file does not exist and it is opened for output, it should be created as a new file. If mode is WriteMode and the file already exists, then it should be truncated to zero length. Some operating systems delete empty files, so there is no guarantee that the file will exist following an openFile with mode WriteMode unless it is subsequently written to successfully. The handle is positioned at the end of the file if mode is AppendMode, and otherwise at the beginning (in which case its internal position is 0). The initial buffer mode is implementation-dependent. This operation may fail with: On POSIX systems, openFile is an interruptible operation as described in Control.Exception. Note: if you will be working with files containing binary data, you'll want to be using openBinaryFile.
Lifted version of openFile
Acquire a Handle within MonadSafe The ReleaseKey can be used to close the handle with release; otherwise the handle will be closed automatically at the conclusion of the MonadSafe block. The file is opened in text mode. See also: openBinaryFile
Open a file in binary mode, and return an open Handle. The Handle should be closed with hClose when it is no longer needed. withFile is easier to use, because it will handle the Handle’s lifetime automatically. This computation throws IOError on failure. See “Classifying I/O errors” in the System.IO.Error documentation for information on why the failure occured.
Lifted version of openFile. See also withFile for more information.
Like openFile, but sets the file encoding to UTF-8, regardless of the current locale.
Open a file
list the file name in the given FilePath directory TODO: error management and not implemented yet getDirectory :: FilePath -> IO [FileName] getDirectory = undefined Open a new handle on the file
Open a file and return the Handle.
Like openFile, but takes a PlatformPath instead of an OsPath.
Open a file and make an FD for it. Truncates the file to zero size when the IOMode is WriteMode. openFileWith takes two actions, act1 and act2, to perform after opening the file. act1 is passed a file descriptor and I/O device type for the newly opened file. If an exception occurs in act1, then the file will be closed. act1 must not close the file itself. If it does so and then receives an exception, then the exception handler will attempt to close it again, which is impermissible. act2 is performed with asynchronous exceptions masked. It is passed a function to restore the masking state and the result of act1. It /must not/ throw an exception (or deliver one via an interruptible operation) without first closing the file or arranging for it to be closed. act2 may close the file, but is not required to do so. If act2 leaves the file open, then the file will remain open on return from openFileWith. Code calling openFileWith that wishes to install a finalizer to close the file should do so in act2. Doing so in act1 could potentially close the file in the finalizer first and then in the exception handler. See openFile' for an example of this use. Regardless, the caller is responsible for ensuring that the file is eventually closed, perhaps using bracket.
Like openFile, but opens the file in ordinary blocking mode. This can be useful for opening a FIFO for writing: if we open in non-blocking mode then the open will fail if there are no readers, whereas a blocking open will block until a reader appear. Note: when blocking happens, an OS thread becomes tied up with the processing, so the program must have at least another OS thread if it wants to unblock itself. By corollary, a non-threaded runtime will need a process-external trigger in order to become unblocked. On POSIX systems, openFileBlocking is an interruptible operation as described in Control.Exception.