mirror of
				git://git.code.sf.net/p/zsh/code
				synced 2025-10-31 18:10:56 +01:00 
			
		
		
		
	
		
			
				
	
	
		
			232 lines
		
	
	
	
		
			8.6 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			232 lines
		
	
	
	
		
			8.6 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
| texinode(Functions)(Jobs & Signals)(Command Execution)(Top)
 | |
| chapter(Functions)
 | |
| ifzman(\
 | |
| sect(Functions)
 | |
| )\
 | |
| cindex(functions)
 | |
| findex(function, use of)
 | |
| Shell functions are defined with the tt(function) reserved word or the
 | |
| special syntax `var(funcname) tt(())'.
 | |
| Shell functions are read in and stored internally.
 | |
| Alias names are resolved when the function is read.
 | |
| Functions are executed like commands with the arguments
 | |
| passed as positional parameters.
 | |
| (See noderef(Command Execution).)
 | |
| 
 | |
| Functions execute in the same process as the caller and
 | |
| share all files
 | |
| and present working directory with the
 | |
| caller.  A trap on tt(EXIT) set inside a function
 | |
| is executed after the function completes in the environment
 | |
| of the caller.
 | |
| 
 | |
| findex(return, use of)
 | |
| The tt(return) builtin is used to return from function calls.
 | |
| 
 | |
| findex(functions, use of)
 | |
| Function identifiers can be listed with the tt(functions) builtin.
 | |
| findex(unfunction, use of)
 | |
| Functions can be undefined with the tt(unfunction) builtin.
 | |
| sect(Autoloading Functions)
 | |
| cindex(autoloading functions)
 | |
| cindex(functions, autoloading)
 | |
| 
 | |
| findex(autoload, use of)
 | |
| vindex(fpath, use of)
 | |
| A function can be marked as em(undefined) using the tt(autoload) builtin
 | |
| (or `tt(functions -u)' or `tt(typeset -fu)').  Such a function has no
 | |
| body.  When the function is first executed, the shell searches for its
 | |
| definition using the elements of the tt(fpath) variable.  Thus to define
 | |
| functions for autoloading, a typical sequence is:
 | |
| 
 | |
| example(fpath=(~/myfuncs $fpath)
 | |
| autoload myfunc1 myfunc2 ...)
 | |
| 
 | |
| The usual alias expansion during reading will be suppressed if the
 | |
| tt(autoload) builtin or its equivalent is given the option tt(-U). This is
 | |
| recommended for the use of functions supplied with the zsh distribution.
 | |
| findex(zcompile, use of)
 | |
| Note that for functions precompiled with the tt(zcompile) builtin command
 | |
| the flag tt(-U) must be provided when the tt(.zwc) file is created, as the
 | |
| corresponding information is compiled into the latter.
 | |
| 
 | |
| For each var(element) in tt(fpath), the shell looks for three possible
 | |
| files, the newest of which is used to load the definition for the function:
 | |
| 
 | |
| startitem()
 | |
| item(var(element)tt(.zwc))(
 | |
| A file created with the tt(zcompile) builtin command, which is expected to
 | |
| contain the definitions for all functions in the directory named
 | |
| var(element).  The file is treated in the same manner as a directory
 | |
| containing files for functions and is searched for the definition of the
 | |
| function.   If the definition is not found, the search for a definition
 | |
| proceeds with the other two possibilities described below.
 | |
| 
 | |
| If var(element) already includes a tt(.zwc) extension (i.e. the extension
 | |
| was explicitly given by the user), var(element) is searched for the
 | |
| definition of the function without comparing its age to that of other
 | |
| files; in fact, there does not need to be any directory named var(element)
 | |
| without the suffix.  Thus including an element such as
 | |
| `tt(/usr/local/funcs.zwc)' in tt(fpath) will speed up the search for
 | |
| functions, with the disadvantage that functions included must be explicitly
 | |
| recompiled by hand before the shell notices any changes.
 | |
| )
 | |
| item(var(element)tt(/)var(function)tt(.zwc))(
 | |
| A file created with tt(zcompile), which is expected to contain the
 | |
| definition for var(function).  It may include other function definitions
 | |
| as well, but those are neither loaded nor executed; a file found in this
 | |
| way is searched em(only) for the definition of var(function).
 | |
| )
 | |
| item(var(element)tt(/)var(function))(
 | |
| A file of zsh command text, taken to be the definition for var(function).
 | |
| )
 | |
| enditem()
 | |
| 
 | |
| In summary, the order of searching is, first, in the em(parents of)
 | |
| directories in tt(fpath) for the newer of either a compiled directory or
 | |
| a directory in tt(fpath); second, if more than one of these contains a
 | |
| definition for the function that is sought, the leftmost in the tt(fpath)
 | |
| is chosen; and third, within a directory, the newer of either a compiled
 | |
| function or an ordinary function definition is used.
 | |
| 
 | |
| pindex(KSH_AUTOLOAD, use of)
 | |
| If the tt(KSH_AUTOLOAD) option is set, or the file contains only a
 | |
| simple definition of the function, the file's contents will be executed.
 | |
| This will normally define the function in question, but may also perform
 | |
| initialization, which is executed in the context of the function execution,
 | |
| and may therefore define local parameters.  It is an error if the function
 | |
| is not defined by loading the file.
 | |
| 
 | |
| Otherwise, the function body (with no surrounding `var(funcname)tt(()
 | |
| {)var(...)tt(})') is taken to be the complete contents of the file.  This
 | |
| form allows the file to be used directly as an executable shell script.  If
 | |
| processing of the file results in the function being re-defined, the
 | |
| function itself is not re-executed.  To force the shell to perform
 | |
| initialization and then call the function defined, the file should contain
 | |
| initialization code (which will be executed then discarded) in addition to
 | |
| a complete function definition (which will be retained for subsequent calls
 | |
| to the function), and a call to the shell function, including any
 | |
| arguments, at the end.
 | |
| 
 | |
| For example, suppose the autoload file tt(func) contains
 | |
| 
 | |
| example(func() { print This is func; }
 | |
| print func is initialized
 | |
| )
 | |
| 
 | |
| then `tt(func; func)' with tt(KSH_AUTOLOAD) set will produce both messages
 | |
| on the first call, but only the message `tt(This is func)' on the second
 | |
| and subsequent calls.  Without tt(KSH_AUTOLOAD) set, it will produce
 | |
| the initialization message on the first call, and the other message on the
 | |
| second and subsequent calls.
 | |
| 
 | |
| It is also possible to create a function that is not marked as autoloaded,
 | |
| but which loads its own definition by searching tt(fpath), by using
 | |
| `tt(autoload -X)' within a shell function.  For example, the following are
 | |
| equivalent:
 | |
| 
 | |
| example(myfunc() {
 | |
|   autoload -X
 | |
| }
 | |
| myfunc args...)
 | |
| 
 | |
| and
 | |
| 
 | |
| example(unfunction myfunc   # if myfunc was defined
 | |
| autoload myfunc
 | |
| myfunc args...)
 | |
| 
 | |
| In fact, the tt(functions) command outputs `tt(builtin autoload -X)' as
 | |
| the body of an autoloaded function.  This is done so that
 | |
| 
 | |
| example(eval "$(functions)")
 | |
| 
 | |
| produces a reasonable result.  A true autoloaded function can be
 | |
| identified by the presence of the comment `tt(# undefined)' in the body,
 | |
| because all comments are discarded from defined functions.
 | |
| 
 | |
| To load the definition of an autoloaded function tt(myfunc) without
 | |
| executing tt(myfunc), use:
 | |
| 
 | |
| example(autoload +X myfunc)
 | |
| 
 | |
| sect(Special Functions)
 | |
| The following functions, if defined, have special meaning to
 | |
| the shell:
 | |
| 
 | |
| startitem()
 | |
| findex(chpwd)
 | |
| item(tt(chpwd))(
 | |
| Executed whenever the current working directory is changed.
 | |
| )
 | |
| findex(periodic)
 | |
| item(tt(periodic))(
 | |
| vindex(PERIOD)
 | |
| If the parameter tt(PERIOD)
 | |
| is set, this function is executed every tt($PERIOD)
 | |
| seconds, just before a prompt.
 | |
| )
 | |
| findex(precmd)
 | |
| item(tt(precmd))(
 | |
| Executed before each prompt.
 | |
| )
 | |
| findex(preexec)
 | |
| item(tt(preexec))(
 | |
| Executed just after a command has been read and is about to be
 | |
| executed.  If the history mechanism is active (and the line was not
 | |
| discarded from the history buffer), the string that the user typed is
 | |
| passed as the first argument, otherwise it is an empty string.  The
 | |
| actual command that will be executed (including expanded aliases) is
 | |
| passed in two different forms: the second argument is a single-line,
 | |
| size-limited version of the command (with things like function bodies
 | |
| elided); the third argument contains the full text that is being
 | |
| executed.
 | |
| )
 | |
| item(tt(TRAP)var(NAL))(
 | |
| cindex(signals, trapping)
 | |
| cindex(trapping signals)
 | |
| If defined and non-null,
 | |
| this function will be executed whenever the shell
 | |
| catches a signal tt(SIG)var(NAL), where var(NAL) is a signal
 | |
| name as specified for the tt(kill) builtin.
 | |
| The signal number will be passed as the first parameter to the function.
 | |
| 
 | |
| If a function of this form is defined and null,
 | |
| the shell and processes spawned by it will ignore tt(SIG)var(NAL).
 | |
| )
 | |
| findex(TRAPDEBUG)
 | |
| item(tt(TRAPDEBUG))(
 | |
| Executed after each command.
 | |
| )
 | |
| findex(TRAPEXIT)
 | |
| item(tt(TRAPEXIT))(
 | |
| Executed when the shell exits,
 | |
| or when the current function exits if defined inside a function.
 | |
| )
 | |
| findex(TRAPZERR)
 | |
| item(tt(TRAPZERR))(
 | |
| Executed whenever a command has a non-zero exit status.  However, the
 | |
| function is not executed if the command occurred in a sublist followed by
 | |
| `tt(&&)' or `tt(||)'; only the final command in a sublist of this type
 | |
| causes the trap to be executed.
 | |
| )
 | |
| enditem()
 | |
| 
 | |
| findex(trap, use of)
 | |
| The functions beginning `tt(TRAP)' may alternatively be defined with the
 | |
| tt(trap) builtin:  this may be preferable for some uses, as they are then
 | |
| run in the environment of the calling process, rather than in their own
 | |
| function environment.  Apart from the difference in calling procedure and
 | |
| the fact that the function form appears in lists of functions, the forms
 | |
| 
 | |
| example(TRAPNAL() { 
 | |
|  # code
 | |
| })
 | |
| 
 | |
| and
 | |
| 
 | |
| example(trap '
 | |
|  # code
 | |
| ' NAL)
 | |
| 
 | |
| are equivalent.
 |