mirrors/zsh
1
0
Fork 0
mirror of git://git.code.sf.net/p/zsh/code synced 2025-10-23 16:40:24 +02:00
Code Releases Activity

Initial revision

Browse source
This commit is contained in:
Tanaka Akira 1999-05-31 17:10:16 +00:00
parent ba1bd66d5f
commit b39cafaa22
5 changed files with 498 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

46
Doc/Zsh/mod_mapfile.yo Normal file
View file

@ -0,0 +1,46 @@
texinode(The mapfile Module)(The parameter Module)(The files Module)(Zsh Modules)
sect(The mapfile Module)
cindex(parameter, file access via)
The tt(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.
)
enditem()
subsect(Limitations)
Although reading and writing of the file in question is efficiently
handled, zsh's internal memory management may be arbitrarily baroque. Thus
it should not automatically be assumed that use of tt(mapfile) represents a
gain in efficiency over use of other mechanisms. 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 subsitution
operations).
No errors are printed or flagged for non-existent, unreadable, or
unwriteable 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.