| ||||||||||
| ||||||||||
| ||||||||||
Description | ||||||||||
System-independent interface to directory manipulation. | ||||||||||
Synopsis | ||||||||||
Documentation | ||||||||||
A directory contains a series of entries, each of which is a named reference to a file system object (file, directory etc.). Some entries may be hidden, inaccessible, or have some administrative function (e.g. `.' or `..' under POSIX http://www.opengroup.org/onlinepubs/009695399/), but in this standard all such entries are considered to form part of the directory contents. Entries in sub-directories are not, however, considered to form part of the directory contents. Each file system object is referenced by a path. There is normally at least one absolute path to each file system object. In some operating systems, it may also be possible to have paths which are relative to the current directory. | ||||||||||
Actions on directories | ||||||||||
| ||||||||||
createDirectory dir creates a new directory dir which is initially empty, or as near to empty as the operating system allows. The operation may fail with:
| ||||||||||
| ||||||||||
| ||||||||||
| ||||||||||
removeDirectory dir removes an existing directory dir. The implementation may specify additional constraints which must be satisfied before a directory can be removed (e.g. the directory has to be empty, or may not be in use by other processes). It is not legal for an implementation to partially remove a directory unless the entire directory is removed. A conformant implementation need not support directory removal in all situations (e.g. removal of the root directory). The operation may fail with:
| ||||||||||
| ||||||||||
removeDirectoryRecursive dir removes an existing directory dir together with its content and all subdirectories. Be careful, if the directory contains symlinks, the function will follow them. | ||||||||||
| ||||||||||
renameDirectory old new changes the name of an existing directory from old to new. If the new directory already exists, it is atomically replaced by the old directory. If the new directory is neither the old directory nor an alias of the old directory, it is removed as if by removeDirectory. A conformant implementation need not support renaming directories in all situations (e.g. renaming to an existing directory, or across different physical devices), but the constraints must be documented. On Win32 platforms, renameDirectory fails if the new directory already exists. The operation may fail with:
| ||||||||||
| ||||||||||
getDirectoryContents dir returns a list of all entries in dir. The operation may fail with:
| ||||||||||
| ||||||||||
If the operating system has a notion of current directories, getCurrentDirectory returns an absolute path to the current directory of the calling process. The operation may fail with:
| ||||||||||
| ||||||||||
If the operating system has a notion of current directories, setCurrentDirectory dir changes the current directory of the calling process to dir. The operation may fail with:
| ||||||||||
Pre-defined directories | ||||||||||
| ||||||||||
Returns the current user's home directory. The directory returned is expected to be writable by the current user, but note that it isn't generally considered good practice to store application-specific data here; use getAppUserDataDirectory instead. On Unix, getHomeDirectory returns the value of the HOME environment variable. On Windows, the system is queried for a suitable path; a typical path might be C:Documents And Settingsuser. The operation may fail with:
| ||||||||||
| ||||||||||
Returns the pathname of a directory in which application-specific data for the current user can be stored. The result of getAppUserDataDirectory for a given application is specific to the current user. The argument should be the name of the application, which will be used to construct the pathname (so avoid using unusual characters that might result in an invalid pathname). Note: the directory may not actually exist, and may need to be created first. It is expected that the parent directory exists and is writable. On Unix, this function returns $HOME/.appName. On Windows, a typical path might be C:/Documents And Settings/user/Application Data/appName The operation may fail with:
| ||||||||||
| ||||||||||
Returns the current user's document directory. The directory returned is expected to be writable by the current user, but note that it isn't generally considered good practice to store application-specific data here; use getAppUserDataDirectory instead. On Unix, getUserDocumentsDirectory returns the value of the HOME environment variable. On Windows, the system is queried for a suitable path; a typical path might be C:/Documents and Settings/user/My Documents. The operation may fail with:
| ||||||||||
| ||||||||||
Returns the current directory for temporary files. On Unix, getTemporaryDirectory returns the value of the TMPDIR environment variable or "/tmp" if the variable isn't defined. On Windows, the function checks for the existence of environment variables in the following order and uses the first path found:
The operation may fail with:
The function doesn't verify whether the path exists. | ||||||||||
Actions on files | ||||||||||
| ||||||||||
removeFile file removes the directory entry for an existing file file, where file is not itself a directory. The implementation may specify additional constraints which must be satisfied before a file can be removed (e.g. the file may not be in use by other processes). The operation may fail with:
| ||||||||||
| ||||||||||
renameFile old new changes the name of an existing file system object from old to new. If the new object already exists, it is atomically replaced by the old object. Neither path may refer to an existing directory. A conformant implementation need not support renaming files in all situations (e.g. renaming across different physical devices), but the constraints must be documented. The operation may fail with:
| ||||||||||
| ||||||||||
copyFile old new copies the existing file from old to new. If the new file already exists, it is atomically replaced by the old file. Neither path may refer to an existing directory. The permissions of old are copied to new, if possible. | ||||||||||
| ||||||||||
Given path referring to a file or directory, returns a canonicalized path, with the intent that two paths referring to the same file/directory will map to the same canonicalized path. Note that it is impossible to guarantee that the implication (same file/dir <=> same canonicalizedPath) holds in either direction: this function can make only a best-effort attempt. | ||||||||||
| ||||||||||
makeRelative the current directory. | ||||||||||
| ||||||||||
Given an executable file name, searches for such file in the directories listed in system PATH. The returned value is the path to the found executable or Nothing if there isn't such executable. For example (findExecutable "ghc") gives you the path to GHC. | ||||||||||
Existence tests | ||||||||||
| ||||||||||
The operation doesFileExist returns True if the argument file exists and is not a directory, and False otherwise. | ||||||||||
| ||||||||||
The operation doesDirectoryExist returns True if the argument file exists and is a directory, and False otherwise. | ||||||||||
Permissions | ||||||||||
The Permissions type is used to record whether certain operations are permissible on a file/directory. getPermissions and setPermissions get and set these permissions, respectively. Permissions apply both to files and directories. For directories, the executable field will be False, and for files the searchable field will be False. Note that directories may be searchable without being readable, if permission has been given to use them as part of a path, but not to examine the directory contents. Note that to change some, but not all permissions, a construct on the following lines must be used. makeReadable f = do p <- getPermissions f setPermissions f (p {readable = True}) | ||||||||||
| ||||||||||
| ||||||||||
| ||||||||||
The getPermissions operation returns the permissions for the file or directory. The operation may fail with:
| ||||||||||
| ||||||||||
The setPermissions operation sets the permissions for the file or directory. The operation may fail with:
| ||||||||||
Timestamps | ||||||||||
| ||||||||||
The getModificationTime operation returns the clock time at which the file or directory was last modified. The operation may fail with:
| ||||||||||
Produced by Haddock version 0.8 |