Alois Wohlschlager
c1746300a9
Most builtins are now generated from data too, with two exceptions: * Undocumented builtins, since supporting them would add complexity to the generator, the harms of the current implementation mostly don't apply, and the proper fix is to document them. * `derivation` is somewhat magic (it is a function, but defined in the code as a constant), so the current treatment of having it separately documented is kept (for now, at least). Since it is slightly easier to do and probably a good idea anyway, the builtin function registrations generated this way are now processed directly in code and don't go through global variables any more. Unfortunately, a slight breaking change is introduced because the order of the builtins' names in the symbol table changes. Hopefully, this will turn out to not matter in practice. Change-Id: I7b4379a93ae380b6524e41a916a21c5c6f70555e
428 B
428 B
name, args
| name | args | |
|---|---|---|
| readDir |
|
Return the contents of the directory path as a set mapping
directory entries to the corresponding file type. For instance, if
directory A contains a regular file B and another directory
C, then builtins.readDir ./A will return the set
{ B = "regular"; C = "directory"; }
The possible values for the file type are "regular",
"directory", "symlink" and "unknown".