mirror of
git://git.code.sf.net/p/zsh/code
synced 2025-10-31 06:00:54 +01:00
55 lines
2.4 KiB
Text
55 lines
2.4 KiB
Text
COMMENT(!MOD!zsh/mapfile
|
|
Access to external files via a special associative array.
|
|
!MOD!)
|
|
cindex(parameter, file access via)
|
|
The tt(zsh/mapfile) module provides one special associative array parameter of
|
|
the same name.
|
|
|
|
startitem()
|
|
vindex(mapfile)
|
|
item(tt(mapfile))(
|
|
This associative array takes as keys the names of files; the resulting
|
|
value is the content of the file. The value is treated identically to any
|
|
other text coming from a parameter. The value may also be assigned to, in
|
|
which case the file in question is written (whether or not it originally
|
|
existed); or an element may be unset, which will delete the file in
|
|
question. For example, `tt(vared mapfile[myfile])' works as expected,
|
|
editing the file `tt(myfile)'.
|
|
|
|
When the array is accessed as a whole, the keys are the names of files in
|
|
the current directory, and the values are empty (to save a huge overhead in
|
|
memory). Thus tt(${(k)mapfile}) has the same affect as the glob operator
|
|
tt(*(D)), since files beginning with a dot are not special. Care must be
|
|
taken with expressions such as tt(rm ${(k)mapfile}), which will delete
|
|
every file in the current directory without the usual `tt(rm *)' test.
|
|
|
|
The parameter tt(mapfile) may be made read-only; in that case, files
|
|
referenced may not be written or deleted.
|
|
|
|
A file may conveniently be read into an array as one line per element
|
|
with the form
|
|
`var(array)tt(=LPAR()"${(f)mapfile[)var(filename)tt(]}"RPAR())'.
|
|
The double quotes are necessary to prevent empty lines from being
|
|
removed.
|
|
)
|
|
enditem()
|
|
|
|
subsect(Limitations)
|
|
|
|
Although reading and writing of the file in question is efficiently
|
|
handled, zsh's internal memory management may be arbitrarily baroque;
|
|
however, tt(mapfile) is usually very much more efficient than
|
|
anything involving a loop. Note in particular that
|
|
the whole contents of the file will always reside physically in memory when
|
|
accessed (possibly multiple times, due to standard parameter substitution
|
|
operations). In particular, this means handling of sufficiently long files
|
|
(greater than the machine's swap space, or than the range of the pointer
|
|
type) will be incorrect.
|
|
|
|
No errors are printed or flagged for non-existent, unreadable, or
|
|
unwritable files, as the parameter mechanism is too low in the shell
|
|
execution hierarchy to make this convenient.
|
|
|
|
It is unfortunate that the mechanism for loading modules does not yet allow
|
|
the user to specify the name of the shell parameter to be given the special
|
|
behaviour.
|