mirror of
git://git.code.sf.net/p/zsh/code
synced 2024-11-19 05:24:23 +01:00
2034 lines
83 KiB
Plaintext
2034 lines
83 KiB
Plaintext
texinode(Expansion)(Parameters)(Prompt Expansion)(Top)
|
|
chapter(Expansion)
|
|
cindex(expansion)
|
|
ifnztexi(sect(Description))
|
|
The following types of expansions are performed in the indicated order in
|
|
five steps:
|
|
|
|
startitem()
|
|
item(em(History Expansion))(
|
|
This is performed only in interactive shells.
|
|
)
|
|
item(em(Alias Expansion))(
|
|
Aliases are expanded immediately before the command line is parsed as
|
|
explained
|
|
ifzman(under Aliasing in zmanref(zshmisc))\
|
|
ifnzman(in noderef(Aliasing))\
|
|
.
|
|
)
|
|
xitem(em(Process Substitution))
|
|
xitem(em(Parameter Expansion))
|
|
xitem(em(Command Substitution))
|
|
xitem(em(Arithmetic Expansion))
|
|
item(em(Brace Expansion))(
|
|
These five are performed in one step in left-to-right fashion. After
|
|
these expansions, all unquoted occurrences of the characters `tt(\)',
|
|
`tt(')' and `tt(")' are removed.
|
|
)
|
|
item(em(Filename Expansion))(
|
|
If the tt(SH_FILE_EXPANSION) option is set, the order of expansion is
|
|
modified for compatibility with bf(sh) and bf(ksh). In that case
|
|
em(filename expansion) is performed immediately after em(alias expansion),
|
|
preceding the set of five expansions mentioned above.
|
|
)
|
|
cindex(globbing)
|
|
item(em(Filename Generation))(
|
|
This expansion, commonly referred to as bf(globbing), is always done last.
|
|
)
|
|
enditem()
|
|
|
|
The following sections explain the types of expansion in detail.
|
|
|
|
startmenu()
|
|
menu(History Expansion)
|
|
menu(Process Substitution)
|
|
menu(Parameter Expansion)
|
|
menu(Command Substitution)
|
|
menu(Arithmetic Expansion)
|
|
menu(Brace Expansion)
|
|
menu(Filename Expansion)
|
|
menu(Filename Generation)
|
|
endmenu()
|
|
texinode(History Expansion)(Process Substitution)()(Expansion)
|
|
sect(History Expansion)
|
|
cindex(history)
|
|
cindex(history expansion)
|
|
cindex(expansion, history)
|
|
History expansion allows you to use words from previous command
|
|
lines in the command line you are typing. This simplifies spelling
|
|
corrections and the repetition of complicated commands or arguments.
|
|
vindex(HISTSIZE, use of)
|
|
Immediately before execution, each command is saved in the history list,
|
|
the size of which is controlled by the tt(HISTSIZE) parameter. The one
|
|
most recent command is always retained in any case. Each saved command in
|
|
the history list is called a history em(event) and is assigned a number,
|
|
beginning with 1 (one) when the shell starts up. The history number that
|
|
you may see in your prompt (see
|
|
ifzman(Prompt Expansion in zmanref(zshmisc))\
|
|
ifnzman(noderef(Prompt Expansion))\
|
|
) is the number that is to be assigned to the em(next) command.
|
|
|
|
startmenu()
|
|
menu(Overview)
|
|
menu(Event Designators)
|
|
menu(Word Designators)
|
|
menu(Modifiers)
|
|
endmenu()
|
|
texinode(Overview)(Event Designators)()(History Expansion)
|
|
subsect(Overview)
|
|
vindex(histchars, use of)
|
|
A history expansion begins with the first character of the tt(histchars)
|
|
parameter, which is `tt(!)' by default, and may occur anywhere on the
|
|
command line; history expansions do not nest. The `tt(!)' can be escaped
|
|
with `tt(\)' or can be enclosed between a pair of single quotes (tt(''))
|
|
to suppress its special meaning. Double quotes will em(not) work for
|
|
this. Following this history character is an optional event designator
|
|
(ifzman(see )noderef(Event Designators)) and then an optional word
|
|
designator (noderef(Word Designators)); if neither of these designators is
|
|
present, no history expansion occurs.
|
|
|
|
Input lines containing history expansions are echoed after being expanded,
|
|
but before any other expansions take place and before the command is
|
|
executed. It is this expanded form that is recorded as the history event
|
|
for later references.
|
|
|
|
By default, a history reference with no event designator refers to the
|
|
same event as any preceding history reference on that command line; if it
|
|
is the only history reference in a command, it refers to the previous
|
|
command.
|
|
pindex(CSH_JUNKIE_HISTORY, use of)
|
|
However, if the option tt(CSH_JUNKIE_HISTORY) is set, then every history
|
|
reference with no event specification em(always) refers to the previous
|
|
command.
|
|
|
|
For example, `tt(!)' is the event designator for the previous command, so
|
|
`tt(!!:1)' always refers to the first word of the previous command, and
|
|
`tt(!!$)' always refers to the last word of the previous command. With
|
|
tt(CSH_JUNKIE_HISTORY) set, then `tt(!:1)' and `tt(!$)' function in the
|
|
same manner as `tt(!!:1)' and `tt(!!$)', respectively. Conversely, if
|
|
tt(CSH_JUNKIE_HISTORY) is unset, then `tt(!:1)' and `tt(!$)' refer to the
|
|
first and last words, respectively, of the same event referenced by the
|
|
nearest other history reference preceding them on the current command
|
|
line, or to the previous command if there is no preceding reference.
|
|
|
|
The character sequence `tt(^)var(foo)tt(^)var(bar)' (where `tt(^)' is
|
|
actually the second character of the tt(histchars) parameter)
|
|
repeats the last command, replacing the string var(foo) with var(bar).
|
|
More precisely, the sequence `tt(^)var(foo)tt(^)var(bar)tt(^)' is
|
|
synonymous with `tt(!!:s)tt(^)var(foo)tt(^)var(bar)tt(^)', hence other
|
|
modifiers (see noderef(Modifiers)) may follow the final `tt(^)'.
|
|
In particular, `tt(^)var(foo)tt(^)var(bar)tt(:G)' performs a global
|
|
substitution.
|
|
|
|
If the shell encounters the character sequence `tt(!")'
|
|
in the input, the history mechanism is temporarily disabled until
|
|
the current list (see
|
|
ifzman(zmanref(zshmisc))\
|
|
ifnzman(noderef(Shell Grammar))\
|
|
) is fully parsed. The `tt(!")' is removed from the input, and any
|
|
subsequent `tt(!)' characters have no special significance.
|
|
|
|
findex(fc, use of)
|
|
A less convenient but more comprehensible form of command history support
|
|
is provided by the tt(fc) builtin.
|
|
texinode(Event Designators)(Word Designators)(Overview)(History Expansion)
|
|
subsect(Event Designators)
|
|
cindex(history event designators)
|
|
cindex(event designators, history)
|
|
An event designator is a reference to a command-line entry in the history
|
|
list. In the list below, remember that the initial tt(`!') in each item
|
|
may be changed to another character by setting the tt(histchars)
|
|
parameter.
|
|
|
|
startitem()
|
|
item(tt(!))(
|
|
Start a history expansion, except when followed by a blank, newline,
|
|
`tt(=)' or `tt(LPAR())'. If followed immediately by a word designator
|
|
(ifzman(see )noderef(Word Designators)), this forms a history reference
|
|
with no event designator (ifzman(see )noderef(Overview)).
|
|
)
|
|
item(tt(!!))(
|
|
Refer to the previous command.
|
|
By itself, this expansion
|
|
repeats the previous command.
|
|
)
|
|
item(tt(!)var(n))(
|
|
Refer to command-line var(n).
|
|
)
|
|
item(tt(!-)var(n))(
|
|
Refer to the current command-line minus var(n).
|
|
)
|
|
item(tt(!)var(str))(
|
|
Refer to the most recent command starting with var(str).
|
|
)
|
|
item(tt(!?)var(str)[tt(?)])(
|
|
Refer to the most recent command containing var(str). The trailing
|
|
`tt(?)' is necessary if this reference is to be followed by a modifier or
|
|
followed by any text that is not to be considered part of var(str).
|
|
)
|
|
item(tt(!#))(
|
|
Refer to the current command line typed in so far. The line is
|
|
treated as if it were complete up to and including the word before the
|
|
one with the `tt(!#)' reference.
|
|
)
|
|
item(tt(!{)...tt(}))(
|
|
Insulate a history reference from adjacent characters (if necessary).
|
|
)
|
|
enditem()
|
|
texinode(Word Designators)(Modifiers)(Event Designators)(History Expansion)
|
|
subsect(Word Designators)
|
|
cindex(history word designators)
|
|
cindex(word designators, history)
|
|
A word designator indicates which word or words of a given command line are
|
|
to be included in a history reference. A `tt(:)' usually
|
|
separates the event specification from the word designator.
|
|
It may be omitted only if the word designator begins with a
|
|
`tt(^)', `tt($)', `tt(*)', `tt(-)' or `tt(%)'.
|
|
Word designators include:
|
|
|
|
startsitem()
|
|
sitem(tt(0))(The first input word (command).)
|
|
sitem(var(n))(The var(n)th argument.)
|
|
sitem(tt(^))(The first argument. That is, tt(1).)
|
|
sitem(tt($))(The last argument.)
|
|
sitem(tt(%))(The word matched by (the most recent) tt(?)var(str) search.)
|
|
sitem(var(x)tt(-)var(y))(A range of words; var(x) defaults to tt(0).)
|
|
sitem(tt(*))(All the arguments, or a null value if there are none.)
|
|
sitem(var(x)tt(*))(Abbreviates `var(x)tt(-$)'.)
|
|
sitem(var(x)tt(-))(Like `var(x)tt(*)' but omitting word tt($).)
|
|
endsitem()
|
|
|
|
Note that a `tt(%)' word designator works only when used in one of
|
|
`tt(!%)', `tt(!:%)' or `tt(!?)var(str)tt(?:%)', and only when used after a
|
|
tt(!?) expansion (possibly in an earlier command). Anything else results
|
|
in an error, although the error may not be the most obvious one.
|
|
texinode(Modifiers)()(Word Designators)(History Expansion)
|
|
subsect(Modifiers)
|
|
cindex(modifiers)
|
|
cindex(colon modifiers)
|
|
cindex(history modifiers)
|
|
cindex(globbing modifiers)
|
|
cindex(parameter modifiers)
|
|
After the optional word designator, you can add
|
|
a sequence of one or more of the following modifiers,
|
|
each preceded by a `tt(:)'. These modifiers also work on the result
|
|
of em(filename generation) and em(parameter expansion), except where
|
|
noted.
|
|
|
|
startitem()
|
|
item(tt(h))(
|
|
Remove a trailing pathname component, leaving the head. This works
|
|
like `tt(dirname)'.
|
|
)
|
|
item(tt(r))(
|
|
Remove a filename extension of the form `tt(.)var(xxx)', leaving
|
|
the root name.
|
|
)
|
|
item(tt(e))(
|
|
Remove all but the extension.
|
|
)
|
|
item(tt(t))(
|
|
Remove all leading pathname components, leaving the tail. This works
|
|
like `tt(basename)'.
|
|
)
|
|
item(tt(p))(
|
|
Print the new command but do not execute it. Only works with history
|
|
expansion.
|
|
)
|
|
item(tt(q))(
|
|
Quote the substituted words, escaping further substitutions. Works
|
|
with history expansion and parameter expansion, though for parameters
|
|
it is only useful if the resulting text is to be re-evaluated such as
|
|
by tt(eval).
|
|
)
|
|
item(tt(Q))(
|
|
Remove one level of quotes from the substituted words.
|
|
)
|
|
item(tt(x))(
|
|
Like tt(q), but break into words at whitespace. Does not work with
|
|
parameter expansion.
|
|
)
|
|
item(tt(l))(
|
|
Convert the words to all lowercase.
|
|
)
|
|
item(tt(u))(
|
|
Convert the words to all uppercase.
|
|
)
|
|
item(tt(s/)var(l)tt(/)var(r)[tt(/)])(
|
|
Substitute var(r) for var(l) as described below.
|
|
The substitution is done only for the
|
|
first string that matches var(l). For arrays and for filename
|
|
generation, this applies to each word of the expanded text.
|
|
|
|
The forms `tt(gs/)var(l)tt(/)var(r)' and `tt(s/)var(l)tt(/)var(r)tt(/:G)'
|
|
perform global substitution, i.e. substitute every occurrence of var(r)
|
|
for var(l). Note that the tt(g) or tt(:G) must appear in exactly the
|
|
position shown.
|
|
)
|
|
item(tt(&))(
|
|
Repeat the previous tt(s) substitution. Like tt(s), may be preceded
|
|
immediately by a tt(g). In parameter expansion the tt(&) must appear
|
|
inside braces, and in filename generation it must be quoted with a
|
|
backslash.
|
|
)
|
|
enditem()
|
|
|
|
The tt(s/l/r/) substitution works as follows. The left-hand side of
|
|
substitutions are not regular expressions, but character strings. Any
|
|
character can be used as the delimiter in place of `tt(/)'. A
|
|
backslash quotes the delimiter character. The character `tt(&)', in
|
|
the right-hand-side var(r), is replaced by the text from the
|
|
left-hand-side var(l). The `tt(&)' can be quoted with a backslash. A
|
|
null var(l) uses the previous string either from the previous var(l)
|
|
or from the contextual scan string var(s) from `tt(!?)var(s)'. You can
|
|
omit the rightmost delimiter if a newline immediately follows var(r);
|
|
the rightmost `tt(?)' in a context scan can similarly be omitted.
|
|
Note the same record of the last var(l) and var(r) is maintained
|
|
across all forms of expansion.
|
|
|
|
The following tt(f), tt(F), tt(w) and tt(W) modifiers work only with
|
|
parameter expansion and filename generation. They are listed here to
|
|
provide a single point of reference for all modifiers.
|
|
|
|
startitem()
|
|
item(tt(f))(
|
|
Repeats the immediately (without a colon) following modifier until the
|
|
resulting word doesn't change any more.
|
|
)
|
|
item(tt(F:)var(expr)tt(:))(
|
|
Like tt(f), but repeats only var(n) times if the expression
|
|
var(expr) evaluates to var(n). Any character can be used instead of
|
|
the `tt(:)'; if `tt(LPAR())', `tt([)', or `tt({)'
|
|
is used as the opening delimiter,
|
|
the closing delimiter should be 'tt(RPAR())', `tt(])', or `tt(})',
|
|
respectively.
|
|
)
|
|
item(tt(w))(
|
|
Makes the immediately following modifier work on each word in the
|
|
string.
|
|
)
|
|
item(tt(W:)var(sep)tt(:))(
|
|
Like tt(w) but words are considered to be the parts of the string
|
|
that are separated by var(sep). Any character can be used instead of
|
|
the `tt(:)'; opening parentheses are handled specially, see above.
|
|
)
|
|
enditem()
|
|
texinode(Process Substitution)(Parameter Expansion)(History Expansion)(Expansion)
|
|
sect(Process Substitution)
|
|
cindex(process substitution)
|
|
cindex(substitution, process)
|
|
Each command argument of the form
|
|
`tt(<LPAR())var(list)tt(RPAR())',
|
|
`tt(>LPAR())var(list)tt(RPAR())' or
|
|
`tt(=LPAR())var(list)tt(RPAR())'
|
|
is subject to process substitution.
|
|
In the case of the tt(<) or tt(>) forms, the shell runs process
|
|
var(list) asynchronously. If the system supports the tt(/dev/fd)
|
|
mechanism, the command argument is the name of the device file
|
|
corresponding to a file descriptor; otherwise, if the system supports named
|
|
pipes (FIFOs), the command argument will be a named pipe. If the form with
|
|
tt(>) is selected then writing on this special file will provide input for
|
|
var(list). If tt(<) is used, then the file passed as an argument will
|
|
be connected to the output of the var(list) process. For example,
|
|
|
|
example(tt(paste <LPAR()cut -f1) var(file1)tt(RPAR() <LPAR()cut -f3) var(file2)tt(RPAR() |
|
|
tee >LPAR())var(process1)tt(RPAR() >LPAR())var(process2)tt(RPAR() >/dev/null))
|
|
|
|
cuts fields 1 and 3 from the files var(file1) and var(file2) respectively,
|
|
pastes the results together, and sends it to the processes
|
|
var(process1) and var(process2).
|
|
|
|
If tt(=LPAR())var(...)tt(RPAR()) is used instead of
|
|
tt(<LPAR())var(...)tt(RPAR()),
|
|
then the file passed as an argument will be the name
|
|
of a temporary file containing the output of the var(list)
|
|
process. This may be used instead of the tt(<)
|
|
form for a program that expects to lseek (see manref(lseek)(2))
|
|
on the input file.
|
|
|
|
There is an optimisation for substitutions of the form
|
|
tt(=LPAR()<<<)var(arg)tt(RPAR()), where var(arg) is a single-word argument
|
|
to the here-string redirection tt(<<<). This form produces a file name
|
|
containing the value of var(arg) after any substitutions have been
|
|
performed. This is handled entirely within the current shell. This is
|
|
effectively the reverse of the special form tt($LPAR()<)var(arg)tt(RPAR())
|
|
which treats var(arg) as a file name and replaces it with the file's
|
|
contents.
|
|
|
|
The tt(=) form is useful as both the tt(/dev/fd) and the named pipe
|
|
implementation of tt(<LPAR())var(...)tt(RPAR()) have drawbacks. In
|
|
the former case, some programmes may automatically close the file
|
|
descriptor in question before examining the file on the command line,
|
|
particularly if this is necessary for security reasons such as when the
|
|
programme is running setuid. In the second case, if the
|
|
programme does not actually open the file, the subshell attempting to read
|
|
from or write to the pipe will (in a typical implementation, different
|
|
operating systems may have different behaviour) block for ever and have to
|
|
be killed explicitly. In both cases, the shell actually supplies the
|
|
information using a pipe, so that programmes that expect to lseek
|
|
(see manref(lseek)(2)) on the file will not work.
|
|
|
|
Also note that the previous example can be more compactly and
|
|
efficiently written (provided the tt(MULTIOS) option is set) as:
|
|
|
|
example(tt(paste <LPAR()cut -f1) var(file1)tt(RPAR() <LPAR()cut -f3) var(file2)tt(RPAR()) ifzman(\
|
|
)tt(> >LPAR())var(process1)tt(RPAR() > >LPAR())var(process2)tt(RPAR()))
|
|
|
|
The shell uses pipes instead of FIFOs to implement the latter
|
|
two process substitutions in the above example.
|
|
|
|
There is an additional problem with tt(>LPAR())var(process)tt(RPAR()); when
|
|
this is attached to an external command, the parent shell does not wait
|
|
for var(process) to finish and hence an immediately following command
|
|
cannot rely on the results being complete. The problem and solution are
|
|
the same as described in the section em(MULTIOS) in
|
|
ifzman(zmanref(zshmisc))\
|
|
ifnzman(noderef(Redirection)). Hence in a simplified
|
|
version of the example above:
|
|
|
|
example(tt(paste <LPAR()cut -f1) var(file1)tt(RPAR() <LPAR()cut -f3) var(file2)tt(RPAR()) tt(> >LPAR())var(process)tt(RPAR()))
|
|
|
|
(note that no tt(MULTIOS) are involved), var(process) will be run
|
|
asynchronously. The workaround is:
|
|
|
|
example(tt({ paste <LPAR()cut -f1) var(file1)tt(RPAR() <LPAR()cut -f3) var(file2)tt(RPAR() }) tt(> >LPAR())var(process)tt(RPAR()))
|
|
|
|
The extra processes here are
|
|
spawned from the parent shell which will wait for their completion.
|
|
|
|
texinode(Parameter Expansion)(Command Substitution)(Process Substitution)(Expansion)
|
|
sect(Parameter Expansion)
|
|
cindex(parameter expansion)
|
|
cindex(expansion, parameter)
|
|
The character `tt($)' is used to introduce parameter expansions.
|
|
See
|
|
ifzman(\
|
|
zmanref(zshparam)
|
|
)\
|
|
ifnzman(\
|
|
noderef(Parameters)
|
|
)\
|
|
for a description of parameters, including arrays, associative arrays,
|
|
and subscript notation to access individual array elements.
|
|
|
|
Note in particular the fact that words of unquoted parameters are not
|
|
automatically split on whitespace unless the option tt(SH_WORD_SPLIT) is
|
|
set; see references to this option below for more details. This is an
|
|
important difference from other shells.
|
|
|
|
In the expansions discussed below that require a pattern, the form of
|
|
the pattern is the same as that used for filename generation;
|
|
see noderef(Filename Generation). Note that these patterns, along with
|
|
the replacement text of any substitutions, are themselves subject to
|
|
parameter expansion, command substitution, and arithmetic expansion.
|
|
In addition to the following operations, the colon modifiers described in
|
|
noderef(Modifiers) in noderef(History Expansion) can be
|
|
applied: for example, tt(${i:s/foo/bar/}) performs string
|
|
substitution on the expansion of parameter tt($i).
|
|
|
|
startitem()
|
|
item(tt(${)var(name)tt(}))(
|
|
The value, if any, of the parameter var(name) is substituted.
|
|
The braces are required if the expansion is to be followed by
|
|
a letter, digit, or underscore that is not to be interpreted
|
|
as part of var(name). In addition, more complicated forms of substitution
|
|
usually require the braces to be present; exceptions, which only apply if
|
|
the option tt(KSH_ARRAYS) is not set, are a single subscript or any colon
|
|
modifiers appearing after the name, or any of the characters `tt(^)',
|
|
`tt(=)', `tt(~)', `tt(#)' or `tt(+)' appearing before the name, all of
|
|
which work with or without braces.
|
|
|
|
If var(name) is an array parameter, and the tt(KSH_ARRAYS) option is not
|
|
set, then the value of each
|
|
element of var(name) is substituted, one element per word. Otherwise, the
|
|
expansion results in one word only; with tt(KSH_ARRAYS), this is the first
|
|
element of an array. No field splitting is done on the result unless the
|
|
tt(SH_WORD_SPLIT) option is set.
|
|
)
|
|
item(tt(${PLUS())var(name)tt(}))(
|
|
If var(name) is the name of a set parameter `tt(1)' is substituted,
|
|
otherwise `tt(0)' is substituted.
|
|
)
|
|
item(tt(${)var(name)tt(:-)var(word)tt(}))(
|
|
If var(name) is set and is non-null then substitute its
|
|
value; otherwise substitute var(word). If var(name) is
|
|
missing, substitute var(word).
|
|
)
|
|
xitem(tt(${)var(name)tt(:=)var(word)tt(}))
|
|
item(tt(${)var(name)tt(::=)var(word)tt(}))(
|
|
In the first form, if var(name) is unset or is null then
|
|
set it to var(word); in the second form, unconditionally
|
|
set var(name) to var(word). In both forms, the value of
|
|
the parameter is then substituted.
|
|
)
|
|
item(tt(${)var(name)tt(:?)var(word)tt(}))(
|
|
If var(name) is set and is non-null then substitute
|
|
its value; otherwise, print var(word) and exit from the shell.
|
|
Interactive shells instead return to the prompt.
|
|
If var(word) is omitted, then a standard message is printed.
|
|
)
|
|
item(tt(${)var(name)tt(:PLUS())var(word)tt(}))(
|
|
If var(name) is set and is non-null then substitute
|
|
var(word); otherwise substitute nothing.
|
|
)
|
|
enditem()
|
|
|
|
If the colon is omitted from one of the above expressions
|
|
containing a colon, then the shell only checks whether
|
|
var(name) is set, not whether its value is null.
|
|
|
|
In the following expressions, when var(name) is an array and
|
|
the substitution is not quoted, or if the `tt((@))' flag or the
|
|
var(name)tt([@]) syntax is used, matching and replacement is
|
|
performed on each array element separately.
|
|
|
|
startitem()
|
|
xitem(tt(${)var(name)tt(#)var(pattern)tt(}))
|
|
item(tt(${)var(name)tt(##)var(pattern)tt(}))(
|
|
If the var(pattern) matches the beginning of the value of
|
|
var(name), then substitute the value of var(name) with
|
|
the matched portion deleted; otherwise, just
|
|
substitute the value of var(name). In the first
|
|
form, the smallest matching pattern is preferred;
|
|
in the second form, the largest matching pattern is
|
|
preferred.
|
|
)
|
|
xitem(tt(${)var(name)tt(%)var(pattern)tt(}))
|
|
item(tt(${)var(name)tt(%%)var(pattern)tt(}))(
|
|
If the var(pattern) matches the end of the value of
|
|
var(name), then substitute the value of var(name) with
|
|
the matched portion deleted; otherwise, just
|
|
substitute the value of var(name). In the first
|
|
form, the smallest matching pattern is preferred;
|
|
in the second form, the largest matching pattern is
|
|
preferred.
|
|
)
|
|
item(tt(${)var(name)tt(:#)var(pattern)tt(}))(
|
|
If the var(pattern) matches the value of var(name), then substitute
|
|
the empty string; otherwise, just substitute the value of var(name).
|
|
If var(name) is an array
|
|
the matching array elements are removed (use the `tt((M))' flag to
|
|
remove the non-matched elements).
|
|
)
|
|
xitem(tt(${)var(name)tt(/)var(pattern)tt(/)var(repl)tt(}))
|
|
item(tt(${)var(name)tt(//)var(pattern)tt(/)var(repl)tt(}))(
|
|
Replace the longest possible match of var(pattern) in the expansion of
|
|
parameter var(name) by string var(repl). The first form
|
|
replaces just the first occurrence, the second form all occurrences.
|
|
Both var(pattern) and var(repl) are subject to double-quoted substitution,
|
|
so that expressions like tt(${name/$opat/$npat}) will work, but note the
|
|
usual rule that pattern characters in tt($opat) are not treated specially
|
|
unless either the option tt(GLOB_SUBST) is set, or tt($opat) is instead
|
|
substituted as tt(${~opat}).
|
|
|
|
The var(pattern) may begin with a `tt(#)', in which case the
|
|
var(pattern) must match at the start of the string, or `tt(%)', in
|
|
which case it must match at the end of the string. The var(repl) may
|
|
be an empty string, in which case the final `tt(/)' may also be omitted.
|
|
To quote the final `tt(/)' in other cases it should be preceded by a
|
|
single backslash; this is not necessary if the
|
|
`tt(/)' occurs inside a substituted parameter. Note also that the `tt(#)'
|
|
and `tt(%)' are not active if they occur inside a substituted parameter,
|
|
even at the start.
|
|
|
|
The first `tt(/)' may be preceded by a `tt(:)', in which case the match
|
|
will only succeed if it matches the entire word. Note also the
|
|
effect of the tt(I) and tt(S) parameter expansion flags below; however,
|
|
the flags tt(M), tt(R), tt(B), tt(E) and tt(N) are not useful.
|
|
|
|
For example,
|
|
|
|
example(foo="twinkle twinkle little star" sub="t*e" rep="spy"
|
|
print ${foo//${~sub}/$rep}
|
|
print ${(S)foo//${~sub}/$rep})
|
|
|
|
Here, the `tt(~)' ensures that the text of tt($sub) is treated as a
|
|
pattern rather than a plain string. In the first case, the longest
|
|
match for tt(t*e) is substituted and the result is `tt(spy star)',
|
|
while in the second case, the shortest matches are taken and the
|
|
result is `tt(spy spy lispy star)'.
|
|
)
|
|
item(tt(${#)var(spec)tt(}))(
|
|
If var(spec) is one of the above substitutions, substitute
|
|
the length in characters of the result instead of
|
|
the result itself. If var(spec) is an array expression,
|
|
substitute the number of elements of the result.
|
|
Note that `tt(^)', `tt(=)', and `tt(~)', below, must appear
|
|
to the left of `tt(#)' when these forms are combined.
|
|
)
|
|
item(tt(${^)var(spec)tt(}))(
|
|
pindex(RC_EXPAND_PARAM, toggle)
|
|
cindex(array expansion style, rc)
|
|
cindex(rc, array expansion style)
|
|
Turn on the tt(RC_EXPAND_PARAM) option for the
|
|
evaluation of var(spec); if the `tt(^)' is doubled, turn it off.
|
|
When this option is set, array expansions of the form
|
|
var(foo)tt(${)var(xx)tt(})var(bar),
|
|
where the parameter var(xx)
|
|
is set to tt(LPAR())var(a b c)tt(RPAR()), are substituted with
|
|
`var(fooabar foobbar foocbar)' instead of the default
|
|
`var(fooa b cbar)'.
|
|
|
|
Internally, each such expansion is converted into the
|
|
equivalent list for brace expansion. E.g., tt(${^var}) becomes
|
|
tt({$var[1],$var[2],)...tt(}), and is processed as described in
|
|
noderef(Brace Expansion) below.
|
|
If word splitting is also in effect the
|
|
tt($var[)var(N)tt(]) may themselves be split into different list
|
|
elements.
|
|
)
|
|
item(tt(${=)var(spec)tt(}))(
|
|
pindex(SH_WORD_SPLIT, toggle)
|
|
cindex(field splitting, sh style, parameter)
|
|
cindex(sh, field splitting style, parameter)
|
|
Perform word splitting using the rules for tt(SH_WORD_SPLIT) during the
|
|
evaluation of var(spec), but regardless of whether the parameter appears in
|
|
double quotes; if the `tt(=)' is doubled, turn it off.
|
|
vindex(IFS, use of)
|
|
This forces parameter expansions to be split into
|
|
separate words before substitution, using tt(IFS) as a delimiter.
|
|
This is done by default in most other shells.
|
|
|
|
Note that splitting is applied to var(word) in the assignment forms
|
|
of var(spec) em(before) the assignment to var(name) is performed.
|
|
This affects the result of array assignments with the tt(A) flag.
|
|
)
|
|
item(tt(${~)var(spec)tt(}))(
|
|
pindex(GLOB_SUBST, toggle)
|
|
Turn on the tt(GLOB_SUBST) option for the evaluation of
|
|
var(spec); if the `tt(~)' is doubled, turn it off. When this option is
|
|
set, the string resulting from the expansion will be interpreted as a
|
|
pattern anywhere that is possible, such as in filename expansion and
|
|
filename generation and pattern-matching contexts like the right
|
|
hand side of the `tt(=)' and `tt(!=)' operators in conditions.
|
|
)
|
|
enditem()
|
|
|
|
If a tt(${)...tt(}) type parameter expression or a
|
|
tt($LPAR())...tt(RPAR()) type command substitution is used in place of
|
|
var(name) above, it is expanded first and the result is used as if
|
|
it were the value of var(name). Thus it is
|
|
possible to perform nested operations: tt(${${foo#head}%tail})
|
|
substitutes the value of tt($foo) with both `tt(head)' and `tt(tail)'
|
|
deleted. The form with tt($LPAR())...tt(RPAR()) is often useful in
|
|
combination with the flags described next; see the examples below.
|
|
Each var(name) or nested tt(${)...tt(}) in a parameter expansion may
|
|
also be followed by a subscript expression as described in
|
|
ifzman(em(Array Parameters) in zmanref(zshparam))\
|
|
ifnzman(noderef(Array Parameters)).
|
|
|
|
Note that double quotes may appear around nested expressions, in which
|
|
case only the part inside is treated as quoted; for example,
|
|
tt(${(f)"$(foo)"}) quotes the result of tt($(foo)), but the flag `tt((f))'
|
|
(see below) is applied using the rules for unquoted expansions. Note
|
|
further that quotes are themselves nested in this context; for example, in
|
|
tt("${(@f)"$(foo)"}"), there are two sets of quotes, one surrounding the
|
|
whole expression, the other (redundant) surrounding the tt($(foo)) as
|
|
before.
|
|
|
|
subsect(Parameter Expansion Flags)
|
|
cindex(parameter expansion flags)
|
|
cindex(flags, parameter expansion)
|
|
cindex(substitution, parameter, flags)
|
|
If the opening brace is directly followed by an opening parenthesis,
|
|
the string up to the matching closing parenthesis will be taken as a
|
|
list of flags. In cases where repeating a flag is meaningful, the
|
|
repetitions need not be consecutive; for example, `(tt(q%q%q))'
|
|
means the same thing as the more readable `(tt(%%qqq))'. The
|
|
following flags are supported:
|
|
|
|
startitem()
|
|
item(tt(#))(
|
|
Evaluate the resulting words as numeric expressions and output the
|
|
characters corresponding to the resulting integer. Note that this form is
|
|
entirely distinct from use of the tt(#) without parentheses.
|
|
)
|
|
item(tt(%))(
|
|
Expand all tt(%) escapes in the resulting words in the same way as in in
|
|
prompts (see noderef(Prompt Expansion)). If this flag is given twice,
|
|
full prompt expansion is done on the resulting words, depending on the
|
|
setting of the tt(PROMPT_PERCENT), tt(PROMPT_SUBST) and tt(PROMPT_BANG)
|
|
options.
|
|
)
|
|
item(tt(@))(
|
|
In double quotes, array elements are put into separate words.
|
|
E.g., `tt("${(@)foo}")' is equivalent to `tt("${foo[@]}")' and
|
|
`tt("${(@)foo[1,2]}")' is the same as `tt("$foo[1]" "$foo[2]")'.
|
|
This is distinct from em(field splitting) by the the tt(f), tt(s)
|
|
or tt(z) flags, which still applies within each array element.
|
|
)
|
|
item(tt(A))(
|
|
Create an array parameter with `tt(${)...tt(=)...tt(})',
|
|
`tt(${)...tt(:=)...tt(})' or `tt(${)...tt(::=)...tt(})'.
|
|
If this flag is repeated (as in `tt(AA)'), create an associative
|
|
array parameter. Assignment is made before sorting or padding.
|
|
The var(name) part may be a subscripted range for ordinary
|
|
arrays; the var(word) part em(must) be converted to an array, for
|
|
example by using `tt(${(AA)=)var(name)tt(=)...tt(})' to activate
|
|
field splitting, when creating an associative array.
|
|
)
|
|
item(tt(a))(
|
|
With tt(o) or tt(O), sort in array index order. Note that `tt(oa)' is
|
|
therefore equivalent to the default but `tt(Oa)' is useful for
|
|
obtaining an array's elements in reverse order.
|
|
)
|
|
item(tt(c))(
|
|
With tt(${#)var(name)tt(}), count the total number of characters in an array,
|
|
as if the elements were concatenated with spaces between them.
|
|
)
|
|
item(tt(C))(
|
|
Capitalize the resulting words. `Words' in this case refers to sequences
|
|
of alphanumeric characters separated by non-alphanumerics, em(not) to words
|
|
that result from field splitting.
|
|
)
|
|
item(tt(e))(
|
|
Perform em(parameter expansion), em(command substitution) and
|
|
em(arithmetic expansion) on the result. Such expansions can be
|
|
nested but too deep recursion may have unpredictable effects.
|
|
)
|
|
item(tt(f))(
|
|
Split the result of the expansion to lines. This is a shorthand
|
|
for `tt(ps:\n:)'.
|
|
)
|
|
item(tt(F))(
|
|
Join the words of arrays together using newline as a separator.
|
|
This is a shorthand for `tt(pj:\n:)'.
|
|
)
|
|
item(tt(i))(
|
|
With tt(o) or tt(O), sort case-independently.
|
|
)
|
|
item(tt(k))(
|
|
If var(name) refers to an associative array, substitute the em(keys)
|
|
(element names) rather than the values of the elements. Used with
|
|
subscripts (including ordinary arrays), force indices or keys to be
|
|
substituted even if the subscript form refers to values. However,
|
|
this flag may not be combined with subscript ranges.
|
|
)
|
|
item(tt(L))(
|
|
Convert all letters in the result to lower case.
|
|
)
|
|
item(tt(n))(
|
|
With tt(o) or tt(O), sort numerically.
|
|
)
|
|
item(tt(o))(
|
|
Sort the resulting words in ascending order.
|
|
)
|
|
item(tt(O))(
|
|
Sort the resulting words in descending order.
|
|
)
|
|
item(tt(P))(
|
|
This forces the value of the parameter var(name) to be interpreted as a
|
|
further parameter name, whose value will be used where appropriate. If
|
|
used with a nested parameter or command substitution, the result of that
|
|
will be taken as a parameter name in the same way. For example, if you
|
|
have `tt(foo=bar)' and `tt(bar=baz)', the strings tt(${(P)foo}),
|
|
tt(${(P)${foo}}), and tt(${(P)$(echo bar)}) will be expanded to `tt(baz)'.
|
|
)
|
|
item(tt(q))(
|
|
Quote the resulting words with backslashes. If this flag is given
|
|
twice, the resulting words are quoted in single quotes and if it is
|
|
given three times, the words are quoted in double quotes. If it is
|
|
given four times, the words are quoted in single quotes preceded by a tt($).
|
|
)
|
|
item(tt(Q))(
|
|
Remove one level of quotes from the resulting words.
|
|
)
|
|
item(tt(t))(
|
|
Use a string describing the type of the parameter where the value
|
|
of the parameter would usually appear. This string consists of keywords
|
|
separated by hyphens (`tt(-)'). The first keyword in the string describes
|
|
the main type, it can be one of `tt(scalar)', `tt(array)', `tt(integer)',
|
|
`tt(float)' or `tt(association)'. The other keywords describe the type in
|
|
more detail:
|
|
|
|
startitem()
|
|
item(tt(local))(
|
|
for local parameters
|
|
)
|
|
item(tt(left))(
|
|
for left justified parameters
|
|
)
|
|
item(tt(right_blanks))(
|
|
for right justified parameters with leading blanks
|
|
)
|
|
item(tt(right_zeros))(
|
|
for right justified parameters with leading zeros
|
|
)
|
|
item(tt(lower))(
|
|
for parameters whose value is converted to all lower case when it is
|
|
expanded
|
|
)
|
|
item(tt(upper))(
|
|
for parameters whose value is converted to all upper case when it is
|
|
expanded
|
|
)
|
|
item(tt(readonly))(
|
|
for readonly parameters
|
|
)
|
|
item(tt(tag))(
|
|
for tagged parameters
|
|
)
|
|
item(tt(export))(
|
|
for exported parameters
|
|
)
|
|
item(tt(unique))(
|
|
for arrays which keep only the first occurrence of duplicated values
|
|
)
|
|
item(tt(hide))(
|
|
for parameters with the `hide' flag
|
|
)
|
|
item(tt(special))(
|
|
for special parameters defined by the shell
|
|
)
|
|
enditem()
|
|
)
|
|
item(tt(u))(
|
|
Expand only the first occurrence of each unique word.
|
|
)
|
|
item(tt(U))(
|
|
Convert all letters in the result to upper case.
|
|
)
|
|
item(tt(v))(
|
|
Used with tt(k), substitute (as two consecutive words) both the key
|
|
and the value of each associative array element. Used with subscripts,
|
|
force values to be substituted even if the subscript form refers to
|
|
indices or keys.
|
|
)
|
|
item(tt(V))(
|
|
Make any special characters in the resulting words visible.
|
|
)
|
|
item(tt(w))(
|
|
With tt(${#)var(name)tt(}), count words in arrays or strings; the tt(s)
|
|
flag may be used to set a word delimiter.
|
|
)
|
|
item(tt(W))(
|
|
Similar to tt(w) with the difference that empty words between
|
|
repeated delimiters are also counted.
|
|
)
|
|
item(tt(X))(
|
|
With this flag parsing errors occurring with the tt(Q) and tt(e) flags or the
|
|
pattern matching forms such as `tt(${)var(name)tt(#)var(pattern)tt(})'
|
|
are reported. Without the flag they are silently ignored.
|
|
)
|
|
item(tt(z))(
|
|
Split the result of the expansion into words using shell parsing to
|
|
find the words, i.e. taking into account any quoting in the value.
|
|
|
|
Note that this is done very late, as for the `tt((s))' flag. So to
|
|
access single words in the result, one has to use nested expansions as
|
|
in `tt(${${(z)foo}[2]})'. Likewise, to remove the quotes in the
|
|
resulting words one would do: `tt(${(Q)${(z)foo}})'.
|
|
)
|
|
enditem()
|
|
|
|
The following flags (except tt(p)) are followed by one or more arguments
|
|
as shown. Any character, or the matching pairs `tt(LPAR())...tt(RPAR())',
|
|
`tt({)...tt(})', `tt([)...tt(])', or `tt(<)...tt(>)', may be used in place
|
|
of a colon as delimiters, but note that when a flag takes more than one
|
|
argument, a matched pair of delimiters must surround each argument.
|
|
|
|
startitem()
|
|
item(tt(p))(
|
|
Recognize the same escape sequences as the tt(print) builtin
|
|
in string arguments to any of the flags described below.
|
|
)
|
|
item(tt(j:)var(string)tt(:))(
|
|
Join the words of arrays together using var(string) as a separator.
|
|
pindex(SH_WORD_SPLIT, use of)
|
|
Note that this occurs before field splitting by the tt(SH_WORD_SPLIT)
|
|
option.
|
|
)
|
|
item(tt(l:)var(expr)tt(::)var(string1)tt(::)var(string2)tt(:))(
|
|
Pad the resulting words on the left. Each word will be truncated if
|
|
required and placed in a field var(expr) characters wide. The space
|
|
to the left will be filled with var(string1) (concatenated as often
|
|
as needed) or spaces if var(string1) is not given. If both
|
|
var(string1) and var(string2) are given, this string is inserted
|
|
once directly to the left of each word, before padding.
|
|
)
|
|
item(tt(r:)var(expr)tt(::)var(string1)tt(::)var(string2)tt(:))(
|
|
As tt(l), but pad the words on the right and insert var(string2)
|
|
on the right.
|
|
)
|
|
item(tt(s:)var(string)tt(:))(
|
|
Force field splitting (see the option tt(SH_WORD_SPLIT)) at the
|
|
separator var(string). Note that a var(string) of two or more
|
|
characters means all must all match in sequence; this differs from
|
|
the treatment of two or more characters in the tt(IFS) parameter.
|
|
)
|
|
enditem()
|
|
|
|
The following flags are meaningful with the tt(${)...tt(#)...tt(}) or
|
|
tt(${)...tt(%)...tt(}) forms. The tt(S) and tt(I) flags may also be
|
|
used with the tt(${)...tt(/)...tt(}) forms.
|
|
|
|
startitem()
|
|
item(tt(S))(
|
|
Search substrings as well as beginnings or ends; with tt(#) start
|
|
from the beginning and with tt(%) start from the end of the string.
|
|
With substitution via tt(${)...tt(/)...tt(}) or
|
|
tt(${)...tt(//)...tt(}), specifies non-greedy matching, i.e. that the
|
|
shortest instead of the longest match should be replaced.
|
|
)
|
|
item(tt(I:)var(expr)tt(:))(
|
|
Search the var(expr)th match (where var(expr) evaluates to a number).
|
|
This only applies when searching for substrings, either with the tt(S)
|
|
flag, or with tt(${)...tt(/)...tt(}) (only the var(expr)th match is
|
|
substituted) or tt(${)...tt(//)...tt(}) (all matches from the
|
|
var(expr)th on are substituted). The default is to take the first match.
|
|
|
|
The var(expr)th match is counted such that there is either one or zero
|
|
matches from each starting position in the string, although for global
|
|
substitution matches overlapping previous replacements are ignored. With
|
|
the tt(${)...tt(%)...tt(}) and tt(${)...tt(%%)...tt(}) forms, the starting
|
|
position for the match moves backwards from the end as the index increases,
|
|
while with the other forms it moves forward from the start.
|
|
|
|
Hence with the string
|
|
example(which switch is the right switch for Ipswich?)
|
|
substitutions of the form
|
|
tt(${)LPAR()tt(SI:)var(N)tt(:)RPAR()tt(string#w*ch}) as var(N) increases
|
|
from 1 will match and remove `tt(which)', `tt(witch)', `tt(witch)' and
|
|
`tt(wich)'; the form using `tt(##)' will match and remove `tt(which switch
|
|
is the right switch for Ipswich)', `tt(witch is the right switch for
|
|
Ipswich)', `tt(witch for Ipswich)' and `tt(wich)'. The form using `tt(%)'
|
|
will remove the same matches as for `tt(#)', but in reverse order, and the
|
|
form using `tt(%%)' will remove the same matches as for `tt(##)' in reverse
|
|
order.
|
|
)
|
|
item(tt(B))(
|
|
Include the index of the beginning of the match in the result.
|
|
)
|
|
item(tt(E))(
|
|
Include the index of the end of the match in the result.
|
|
)
|
|
item(tt(M))(
|
|
Include the matched portion in the result.
|
|
)
|
|
item(tt(N))(
|
|
Include the length of the match in the result.
|
|
)
|
|
item(tt(R))(
|
|
Include the unmatched portion in the result (the em(R)est).
|
|
)
|
|
enditem()
|
|
|
|
subsect(Rules)
|
|
|
|
Here is a summary of the rules for substitution; this assumes that braces
|
|
are present around the substitution, i.e. tt(${...}). Some particular
|
|
examples are given below. Note that the Zsh Development Group accepts
|
|
em(no responsibility) for any brain damage which may occur during the
|
|
reading of the following rules.
|
|
|
|
startitem()
|
|
item(tt(1.) em(Nested Substitution))(
|
|
If multiple nested tt(${...}) forms are present, substitution is
|
|
performed from the inside outwards. At each level, the substitution takes
|
|
account of whether the current value is a scalar or an array, whether the
|
|
whole substitution is in double quotes, and what flags are supplied to the
|
|
current level of substitution, just as if the nested substitution were the
|
|
outermost. The flags are not propagated up to enclosing
|
|
substitutions; the nested substitution will return either a scalar or an
|
|
array as determined by the flags, possibly adjusted for quoting. All the
|
|
following steps take place where applicable at all levels of substitution.
|
|
Note that, unless the `tt((P))' flag is present, the flags and any subscripts
|
|
apply directly to the value of the nested substitution; for example, the
|
|
expansion tt(${${foo}}) behaves exactly the same as tt(${foo}).
|
|
)
|
|
item(tt(2.) em(Parameter Subscripting))(
|
|
If the value is a raw parameter reference with a subscript, such as
|
|
tt(${)var(var)tt([3]}), the effect of subscripting is applied directly to
|
|
the parameter. Subscripts are evaluated left to right; subsequent
|
|
subscripts apply to the scalar or array value yielded by the previous
|
|
subscript. Thus if tt(var) is an array, tt(${var[1][2]}) is the second
|
|
character of the first word, but tt(${var[2,4][2]}) is the entire third
|
|
word (the second word of the range of words two through four of the
|
|
original array). Any number of subscripts may appear.
|
|
)
|
|
item(tt(3.) em(Parameter Name Replacement))(
|
|
The effect of any tt((P)) flag, which treats the value so far as a
|
|
parameter name and replaces it with the corresponding value, is applied.
|
|
)
|
|
item(tt(4.) em(Double-Quoted Joining))(
|
|
If the value after this process is an array, and the substitution
|
|
appears in double quotes, and no tt((@)) flag is present at the current
|
|
level, the words of the value are joined with the first character of the
|
|
parameter tt($IFS), by default a space, between each word (single word
|
|
arrays are not modified). If the tt((j)) flag is present, that is used for
|
|
joining instead of tt($IFS).
|
|
)
|
|
item(tt(5.) em(Nested Subscripting))(
|
|
Any remaining subscripts (i.e. of a nested substitution) are evaluated at
|
|
this point, based on whether the value is an array or a scalar. As with
|
|
tt(2.), multiple subscripts can appear. Note that tt(${foo[2,4][2]}) is
|
|
thus equivalent to tt(${${foo[2,4]}[2]}) and also to
|
|
tt("${${(@)foo[2,4]}[2]}") (the nested substitution returns an array in
|
|
both cases), but not to tt("${${foo[2,4]}[2]}") (the nested substitution
|
|
returns a scalar because of the quotes).
|
|
)
|
|
item(tt(6.) em(Modifiers))(
|
|
Any modifiers, as specified by a trailing `tt(#)', `tt(%)', `tt(/)'
|
|
(possibly doubled) or by a set of modifiers of the form tt(:...) (see
|
|
noderef(Modifiers) in noderef(History Expansion)), are applied to the words
|
|
of the value at this level.
|
|
)
|
|
item(tt(7.) em(Forced Joining))(
|
|
If the `tt((j))' flag is present, or no `tt((j))' flag is present but
|
|
the string is to be split as given by rules tt(8.) or tt(9.), and joining
|
|
did not take place at step tt(4.), any words in the value are joined
|
|
together using the given string or the first character of tt($IFS) if none.
|
|
Note that the `tt((F))' flag implicitly supplies a string for joining in this
|
|
manner.
|
|
)
|
|
item(tt(8.) em(Forced Splitting))(
|
|
If one of the `tt((s))', `tt((f))' or `tt((z))' flags are present, or the `tt(=)'
|
|
specifier was present (e.g. tt(${=)var(var)tt(})), the word is split on
|
|
occurrences of the specified string, or (for tt(=) with neither of the two
|
|
flags present) any of the characters in tt($IFS).
|
|
)
|
|
item(tt(9.) em(Shell Word Splitting))(
|
|
If no `tt((s))', `tt((f))' or `tt(=)' was given, but the word is not
|
|
quoted and the option tt(SH_WORD_SPLIT) is set, the word is split on
|
|
occurrences of any of the characters in tt($IFS). Note this step, too,
|
|
takes place at all levels of a nested substitution.
|
|
)
|
|
item(tt(10.) em(Uniqueness))(
|
|
If the result is an array and the `tt((u))' flag was present, duplicate
|
|
elements are removed from the array.
|
|
)
|
|
item(tt(11.) em(Ordering))(
|
|
If the result is still an array and one of the `tt((o))' or `tt((O))' flags
|
|
was present, the array is reordered.
|
|
)
|
|
item(tt(12.) em(Re-Evaluation))(
|
|
Any `tt((e))' flag is applied to the value, forcing it to be re-examined
|
|
for new parameter substitutions, but also for command and arithmetic
|
|
substitutions.
|
|
)
|
|
item(tt(13.) em(Padding))(
|
|
Any padding of the value by the `tt(LPAR()l.)var(fill)tt(.RPAR())' or
|
|
`tt(LPAR()r.)var(fill)tt(.RPAR())' flags is applied.
|
|
)
|
|
item(tt(14.) em(Semantic Joining))(
|
|
In contexts where expansion semantics requires a single word to
|
|
result, all words are rejoined with the first character of tt(IFS)
|
|
between. So in `tt(${LPAR()P)tt(RPAR()${LPAR()f)tt(RPAR()lines}})'
|
|
the value of tt(${lines}) is split at newlines, but then must be
|
|
joined again before the tt(P) flag can be applied.
|
|
|
|
If a single word is not required, this rule is skipped.
|
|
)
|
|
enditem()
|
|
|
|
subsect(Examples)
|
|
The flag tt(f) is useful to split a double-quoted substitution line by
|
|
line. For example, tt(${(f)"$LPAR()<)var(file)tt(RPAR()"})
|
|
substitutes the contents of var(file) divided so that each line is
|
|
an element of the resulting array. Compare this with the effect of
|
|
tt($)tt(LPAR()<)var(file)tt(RPAR()) alone, which divides the file
|
|
up by words, or the same inside double quotes, which makes the entire
|
|
content of the file a single string.
|
|
|
|
The following illustrates the rules for nested parameter expansions.
|
|
Suppose that tt($foo) contains the array tt(LPAR()bar baz)tt(RPAR()):
|
|
|
|
startitem()
|
|
item(tt("${(@)${foo}[1]}"))(
|
|
This produces the result tt(b). First, the inner substitution
|
|
tt("${foo}"), which has no array (tt(@)) flag, produces a single word
|
|
result tt("bar baz"). The outer substitution tt("${(@)...[1]}") detects
|
|
that this is a scalar, so that (despite the `tt((@))' flag) the subscript
|
|
picks the first character.
|
|
)
|
|
item(tt("${${(@)foo}[1]}"))(
|
|
This produces the result `tt(bar)'. In this case, the inner substitution
|
|
tt("${(@)foo}") produces the array `tt(LPAR()bar baz)tt(RPAR())'. The outer
|
|
substitution tt("${...[1]}") detects that this is an array and picks the
|
|
first word. This is similar to the simple case tt("${foo[1]}").
|
|
)
|
|
enditem()
|
|
|
|
As an example of the rules for word splitting and joining, suppose tt($foo)
|
|
contains the array `tt(LPAR()ax1 bx1)tt(RPAR())'. Then
|
|
|
|
startitem()
|
|
item(tt(${(s/x/)foo}))(
|
|
produces the words `tt(a)', `tt(1 b)' and `tt(1)'.
|
|
)
|
|
item(tt(${(j/x/s/x/)foo}))(
|
|
produces `tt(a)', `tt(1)', `tt(b)' and `tt(1)'.
|
|
)
|
|
item(tt(${(s/x/)foo%%1*}))(
|
|
produces `tt(a)' and `tt( b)' (note the extra space). As substitution
|
|
occurs before either joining or splitting, the operation first generates
|
|
the modified array tt(LPAR()ax bx)tt(RPAR()), which is joined to give
|
|
tt("ax bx"), and then split to give `tt(a)', `tt( b)' and `'. The final
|
|
empty string will then be elided, as it is not in double quotes.
|
|
)
|
|
enditem()
|
|
|
|
texinode(Command Substitution)(Arithmetic Expansion)(Parameter Expansion)(Expansion)
|
|
sect(Command Substitution)
|
|
cindex(command substitution)
|
|
cindex(substitution, command)
|
|
A command enclosed in parentheses preceded by a dollar sign, like
|
|
`tt($LPAR())...tt(RPAR())', or quoted with grave
|
|
accents, like `tt(`)...tt(`)', is replaced with its standard output, with
|
|
any trailing newlines deleted.
|
|
If the substitution is not enclosed in double quotes, the
|
|
output is broken into words using the tt(IFS) parameter.
|
|
vindex(IFS, use of)
|
|
The substitution `tt($LPAR()cat) var(foo)tt(RPAR())' may be replaced
|
|
by the equivalent but faster `tt($LPAR()<)var(foo)tt(RPAR())'.
|
|
In either case, if the option tt(GLOB_SUBST) is set,
|
|
the output is eligible for filename generation.
|
|
texinode(Arithmetic Expansion)(Brace Expansion)(Command Substitution)(Expansion)
|
|
sect(Arithmetic Expansion)
|
|
cindex(arithmetic expansion)
|
|
cindex(expansion, arithmetic)
|
|
A string of the form `tt($[)var(exp)tt(])' or
|
|
`tt($LPAR()LPAR())var(exp)tt(RPAR()RPAR())' is substituted
|
|
with the value of the arithmetic expression var(exp). var(exp) is
|
|
subjected to em(parameter expansion), em(command substitution)
|
|
and em(arithmetic expansion) before it is evaluated.
|
|
See noderef(Arithmetic Evaluation).
|
|
texinode(Brace Expansion)(Filename Expansion)(Arithmetic Expansion)(Expansion)
|
|
sect(Brace Expansion)
|
|
cindex(brace expansion)
|
|
cindex(expansion, brace)
|
|
A string of the form
|
|
`var(foo)tt({)var(xx)tt(,)var(yy)tt(,)var(zz)tt(})var(bar)'
|
|
is expanded to the individual words
|
|
`var(fooxxbar)', `var(fooyybar)' and `var(foozzbar)'.
|
|
Left-to-right order is preserved. This construct
|
|
may be nested. Commas may be quoted in order to
|
|
include them literally in a word.
|
|
|
|
An expression of the form `tt({)var(n1)tt(..)var(n2)tt(})',
|
|
where var(n1) and var(n2) are integers,
|
|
is expanded to every number between
|
|
var(n1) and var(n2) inclusive. If either number begins with a
|
|
zero, all the resulting numbers will be padded with leading zeroes to
|
|
that minimum width. If the numbers are in decreasing order the
|
|
resulting sequence will also be in decreasing order.
|
|
|
|
If a brace expression matches none of the above forms, it is left
|
|
unchanged, unless the tt(BRACE_CCL) option is set.
|
|
pindex(BRACE_CCL, use of)
|
|
In that case, it is expanded to a sorted list of the individual
|
|
characters between the braces, in the manner of a search set.
|
|
`tt(-)' is treated specially as in a search set, but `tt(^)' or `tt(!)' as
|
|
the first character is treated normally.
|
|
|
|
Note that brace expansion is not part of filename generation (globbing); an
|
|
expression such as tt(*/{foo,bar}) is split into two separate words
|
|
tt(*/foo) and tt(*/bar) before filename generation takes place. In
|
|
particular, note that this is liable to produce a `no match' error if
|
|
em(either) of the two expressions does not match; this is to be contrasted
|
|
with tt(*/(foo|bar)), which is treated as a single pattern but otherwise
|
|
has similar effects.
|
|
texinode(Filename Expansion)(Filename Generation)(Brace Expansion)(Expansion)
|
|
sect(Filename Expansion)
|
|
cindex(filename expansion)
|
|
cindex(expansion, filename)
|
|
Each word is checked to see if it begins with an unquoted `tt(~)'.
|
|
If it does, then the word up to a `tt(/)',
|
|
or the end of the word if there is no `tt(/)',
|
|
is checked to see if it can be substituted in one of the ways
|
|
described here. If so, then the `tt(~)' and the checked portion are
|
|
replaced with the appropriate substitute value.
|
|
|
|
A `tt(~)' by itself is replaced by the value of tt($HOME).
|
|
A `tt(~)' followed by a `tt(PLUS())' or a `tt(-)' is replaced by the value of
|
|
tt($PWD) or tt($OLDPWD), respectively.
|
|
|
|
A `tt(~)' followed by a number is replaced by the directory at that
|
|
position in the directory stack.
|
|
`tt(~0)' is equivalent to `tt(~PLUS())',
|
|
and `tt(~1)' is the top of the stack.
|
|
`tt(~PLUS())' followed by a number is replaced by the directory at that
|
|
position in the directory stack.
|
|
`tt(~PLUS()0)' is equivalent to `tt(~PLUS())',
|
|
and `tt(~PLUS()1)' is the top of the stack.
|
|
`tt(~-)' followed by a number is replaced by the directory that
|
|
many positions from the bottom of the stack.
|
|
`tt(~-0)' is the bottom of the stack.
|
|
pindex(PUSHD_MINUS, use of)
|
|
The tt(PUSHD_MINUS)
|
|
option exchanges the effects of `tt(~PLUS())' and `tt(~-)' where they are
|
|
followed by a number.
|
|
|
|
cindex(directories, named)
|
|
cindex(named directories)
|
|
A `tt(~)' followed by anything not already covered is looked up as a
|
|
named directory, and replaced by the value of that named directory if found.
|
|
Named directories are typically home directories for users on the system.
|
|
They may also be defined if the text after the `tt(~)' is the name
|
|
of a string shell parameter whose value begins with a `tt(/)'.
|
|
Note that trailing slashes will be removed from the path to the directory
|
|
(though the original parameter is not modified).
|
|
It is also possible to define directory names using the tt(-d) option to the
|
|
tt(hash) builtin.
|
|
|
|
In certain circumstances (in prompts, for instance), when the shell
|
|
prints a path, the path is checked to see if it has a named
|
|
directory as its prefix. If so, then the prefix portion
|
|
is replaced with a `tt(~)' followed by the name of the directory.
|
|
The shortest way of referring to the directory is used,
|
|
with ties broken in favour of using a named directory,
|
|
except when the directory is tt(/) itself. The parameters tt($PWD) and
|
|
tt($OLDPWD) are never abbreviated in this fashion.
|
|
|
|
If a word begins with an unquoted `tt(=)'
|
|
and the tt(EQUALS) option is set,
|
|
the remainder of the word is taken as the
|
|
name of a command. If a command
|
|
exists by that name, the word is replaced
|
|
by the full pathname of the command.
|
|
|
|
Filename expansion is performed on the right hand side of a parameter
|
|
assignment, including those appearing after commands of the
|
|
tt(typeset) family. In this case, the right hand side will be treated
|
|
as a colon-separated list in the manner of the tt(PATH) parameter,
|
|
so that a `tt(~)' or an `tt(=)' following a `tt(:)' is eligible for expansion.
|
|
All such behaviour can be
|
|
disabled by quoting the `tt(~)', the `tt(=)', or the whole expression (but not
|
|
simply the colon); the tt(EQUALS) option is also respected.
|
|
|
|
If the option tt(MAGIC_EQUAL_SUBST) is set, any unquoted shell
|
|
argument in the form `var(identifier)tt(=)var(expression)' becomes eligible
|
|
for file expansion as described in the previous paragraph. Quoting the
|
|
first `tt(=)' also inhibits this.
|
|
texinode(Filename Generation)()(Filename Expansion)(Expansion)
|
|
sect(Filename Generation)
|
|
cindex(filename generation)
|
|
If a word contains an unquoted instance of one of the characters
|
|
`tt(*)', `tt(LPAR())', `tt(|)', `tt(<)', `tt([)', or `tt(?)', it is regarded
|
|
as a pattern for filename generation, unless the tt(GLOB) option is unset.
|
|
pindex(GLOB, use of)
|
|
If the tt(EXTENDED_GLOB) option is set,
|
|
pindex(EXTENDED_GLOB, use of)
|
|
the `tt(^)' and `tt(#)' characters also denote a pattern; otherwise
|
|
they are not treated specially by the shell.
|
|
|
|
The word is replaced with a list of sorted filenames that match
|
|
the pattern. If no matching pattern is found, the shell gives
|
|
an error message, unless the tt(NULL_GLOB) option is set,
|
|
pindex(NULL_GLOB, use of)
|
|
in which case the word is deleted; or unless the tt(NOMATCH)
|
|
option is unset, in which case the word is left unchanged.
|
|
pindex(NOMATCH, use of)
|
|
|
|
In filename generation,
|
|
the character `tt(/)' must be matched explicitly;
|
|
also, a `tt(.)' must be matched
|
|
explicitly at the beginning of a pattern or after a `tt(/)', unless the
|
|
tt(GLOB_DOTS) option is set.
|
|
pindex(GLOB_DOTS, use of)
|
|
No filename generation pattern
|
|
matches the files `tt(.)' or `tt(..)'. In other instances of pattern
|
|
matching, the `tt(/)' and `tt(.)' are not treated specially.
|
|
subsect(Glob Operators)
|
|
startitem()
|
|
item(tt(*))(
|
|
Matches any string, including the null string.
|
|
)
|
|
item(tt(?))(
|
|
Matches any character.
|
|
)
|
|
item(tt([)...tt(]))(
|
|
Matches any of the enclosed characters. Ranges of characters
|
|
can be specified by separating two characters by a `tt(-)'.
|
|
A `tt(-)' or `tt(])' may be matched by including it as the
|
|
first character in the list.
|
|
cindex(character classes)
|
|
There are also several named classes of characters, in the form
|
|
`tt([:)var(name)tt(:])' with the following meanings.
|
|
The first set use the macros provided by
|
|
the operating system to test for the given character combinations,
|
|
including any modifications due to local language settings, see
|
|
manref(ctype)(3):
|
|
|
|
startitem()
|
|
item(tt([:alnum:]))(
|
|
The character is alphanumeric
|
|
)
|
|
item(tt([:alpha:]))
|
|
(
|
|
The character is alphabetic
|
|
)
|
|
item(tt([:ascii:]))(
|
|
The character is 7-bit, i.e. is a single-byte character without
|
|
the top bit set.
|
|
)
|
|
item(tt([:blank:]))(
|
|
The character is either space or tab
|
|
)
|
|
item(tt([:cntrl:]))(
|
|
The character is a control character
|
|
)
|
|
item(tt([:digit:]))(
|
|
The character is a decimal digit
|
|
)
|
|
item(tt([:graph:]))(
|
|
The character is a printable character other than whitespace
|
|
)
|
|
item(tt([:lower:]))(l
|
|
The character is a lowercase letter
|
|
)
|
|
item(tt([:print:]))(
|
|
The character is printable
|
|
)
|
|
item(tt([:punct:]))(
|
|
The character is printable but neither alphanumeric nor whitespace
|
|
)
|
|
item(tt([:space:]))(
|
|
The character is whitespace
|
|
)
|
|
item(tt([:upper:]))(
|
|
The character is an uppercase letter
|
|
)
|
|
item(tt([:xdigit:]))(
|
|
The character is a hexadecimal digit
|
|
)
|
|
enditem()
|
|
|
|
Another set of named classes is handled internally by the shell and
|
|
is not sensitive to the locale:
|
|
|
|
startitem()
|
|
item(tt([:IDENT:]))(
|
|
The character is allowed to form part of a shell identifier, such
|
|
as a parameter name
|
|
)
|
|
item(tt([:IFS:]))(
|
|
The character is used as an input field separator, i.e. is contained in the
|
|
tt(IFS) parameter
|
|
)
|
|
item(tt([:IFSSPACE:]))(
|
|
The character is an IFS white space character; see the documentation
|
|
for tt(IFS) in
|
|
ifzman(the zmanref(zshparams) manual page)\
|
|
ifnzman(noderef(Parameters Used By The Shell))\
|
|
.
|
|
)
|
|
item(tt([:WORD:]))(
|
|
The character is treated as part of a word; this test is sensitive
|
|
to the value of the tt(WORDCHARS) parameter
|
|
)
|
|
enditem()
|
|
|
|
Note that the square brackets are additional
|
|
to those enclosing the whole set of characters, so to test for a
|
|
single alphanumeric character you need `tt([[:alnum:]])'. Named
|
|
character sets can be used alongside other types,
|
|
e.g. `tt([[:alpha:]0-9])'.
|
|
)
|
|
xitem(tt([^)...tt(]))
|
|
item(tt([!)...tt(]))(
|
|
Like tt([)...tt(]), except that it matches any character which is
|
|
not in the given set.
|
|
)
|
|
item(tt(<)[var(x)]tt(-)[var(y)]tt(>))(
|
|
Matches any number in the range var(x) to var(y), inclusive.
|
|
Either of the numbers may be omitted to make the range open-ended;
|
|
hence `tt(<->)' matches any number. To match individual digits, the
|
|
tt([)...tt(]) form is more efficient.
|
|
|
|
Be careful when using other wildcards adjacent to patterns of this form;
|
|
for example, tt(<0-9>*) will actually match any number whatsoever at the
|
|
start of the string, since the `tt(<0-9>)' will match the first digit, and
|
|
the `tt(*)' will match any others. This is a trap for the unwary, but is
|
|
in fact an inevitable consequence of the rule that the longest possible
|
|
match always succeeds. Expressions such as `tt(<0-9>[^[:digit:]]*)' can be
|
|
used instead.
|
|
)
|
|
item(tt(LPAR())...tt(RPAR()))(
|
|
Matches the enclosed pattern. This is used for grouping.
|
|
If the tt(KSH_GLOB) option is set, then a
|
|
`tt(@)', `tt(*)', `tt(+)', `tt(?)' or `tt(!)' immediately preceding
|
|
the `tt(LPAR())' is treated specially, as detailed below. The option
|
|
tt(SH_GLOB) prevents bare parentheses from being used in this way, though
|
|
the tt(KSH_GLOB) option is still available.
|
|
|
|
Note that grouping cannot extend over multiple directories: it is an error
|
|
to have a `tt(/)' within a group (this only applies for patterns used in
|
|
filename generation). There is one exception: a group of the form
|
|
tt(LPAR())var(pat)tt(/RPAR()#) appearing as a complete path segment can
|
|
match a sequence of directories. For example, tt(foo/(a*/)#bar) matches
|
|
tt(foo/bar), tt(foo/any/bar), tt(foo/any/anyother/bar), and so on.
|
|
)
|
|
item(var(x)tt(|)var(y))(
|
|
Matches either var(x) or var(y).
|
|
This operator has lower precedence than any other.
|
|
The `tt(|)' character
|
|
must be within parentheses, to avoid interpretation as a pipeline.
|
|
)
|
|
item(tt(^)var(x))(
|
|
(Requires tt(EXTENDED_GLOB) to be set.)
|
|
Matches anything except the pattern var(x).
|
|
This has a higher precedence than `tt(/)', so `tt(^foo/bar)'
|
|
will search directories in `tt(.)' except `tt(./foo)'
|
|
for a file named `tt(bar)'.
|
|
)
|
|
item(var(x)tt(~)var(y))(
|
|
(Requires tt(EXTENDED_GLOB) to be set.)
|
|
Match anything that matches the pattern var(x) but does not match var(y).
|
|
This has lower precedence than any operator except `tt(|)', so
|
|
`tt(*/*~foo/bar)' will search for all files in all directories in `tt(.)'
|
|
and then exclude `tt(foo/bar)' if there was such a match.
|
|
Multiple patterns can be excluded by
|
|
`var(foo)tt(~)var(bar)tt(~)var(baz)'.
|
|
In the exclusion pattern (var(y)), `tt(/)' and `tt(.)' are not treated
|
|
specially the way they usually are in globbing.
|
|
)
|
|
item(var(x)tt(#))(
|
|
(Requires tt(EXTENDED_GLOB) to be set.)
|
|
Matches zero or more occurrences of the pattern var(x).
|
|
This operator has high precedence; `tt(12#)' is equivalent to `tt(1(2#))',
|
|
rather than `tt((12)#)'. It is an error for an unquoted `tt(#)' to follow
|
|
something which cannot be repeated; this includes an empty string, a
|
|
pattern already followed by `tt(##)', or parentheses when part of a
|
|
tt(KSH_GLOB) pattern (for example, `tt(!LPAR())var(foo)tt(RPAR()#)' is
|
|
invalid and must be replaced by
|
|
`tt(*LPAR()!LPAR())var(foo)tt(RPAR()RPAR())').
|
|
)
|
|
item(var(x)tt(##))(
|
|
(Requires tt(EXTENDED_GLOB) to be set.)
|
|
Matches one or more occurrences of the pattern var(x).
|
|
This operator has high precedence; `tt(12##)' is equivalent to `tt(1(2##))',
|
|
rather than `tt((12)##)'. No more than two active `tt(#)' characters may
|
|
appear together.
|
|
)
|
|
enditem()
|
|
subsect(ksh-like Glob Operators)
|
|
pindex(KSH_GLOB, use of)
|
|
If the tt(KSH_GLOB) option is set, the effects of parentheses can be
|
|
modified by a preceding `tt(@)', `tt(*)', `tt(+)', `tt(?)' or `tt(!)'.
|
|
This character need not be unquoted to have special effects,
|
|
but the `tt(LPAR())' must be.
|
|
|
|
startitem()
|
|
item(tt(@LPAR())...tt(RPAR()))(
|
|
Match the pattern in the parentheses. (Like `tt(LPAR())...tt(RPAR())'.)
|
|
)
|
|
item(tt(*LPAR())...tt(RPAR()))(
|
|
Match any number of occurrences. (Like `tt(LPAR())...tt(RPAR()#)'.)
|
|
)
|
|
item(tt(PLUS()LPAR())...tt(RPAR()))(
|
|
Match at least one occurrence. (Like `tt(LPAR())...tt(RPAR()##)'.)
|
|
)
|
|
item(tt(?LPAR())...tt(RPAR()))(
|
|
Match zero or one occurrence. (Like `tt(LPAR()|)...tt(RPAR())'.)
|
|
)
|
|
item(tt(!LPAR())...tt(RPAR()))(
|
|
Match anything but the expression in parentheses.
|
|
(Like `tt(LPAR()^LPAR())...tt(RPAR()RPAR())'.)
|
|
)
|
|
enditem()
|
|
subsect(Precedence)
|
|
cindex(precedence of glob operators)
|
|
The precedence of the operators given above is (highest) `tt(^)', `tt(/)',
|
|
`tt(~)', `tt(|)' (lowest); the
|
|
remaining operators are simply treated from left to right as part of a
|
|
string, with `tt(#)' and `tt(##)' applying to the shortest possible
|
|
preceding unit (i.e. a character, `tt(?)', `tt([)...tt(])',
|
|
`tt(<)...tt(>)', or a parenthesised expression). As mentioned
|
|
above, a `tt(/)' used as a directory separator may not appear inside
|
|
parentheses, while a `tt(|)' must do so; in patterns used in other contexts
|
|
than filename generation (for example, in tt(case) statements and tests
|
|
within `tt([[)...tt(]])'), a `tt(/)' is not special; and `tt(/)' is also
|
|
not special after a `tt(~)' appearing outside parentheses in a filename
|
|
pattern.
|
|
subsect(Globbing Flags)
|
|
There are various flags which affect any text to their right up to the
|
|
end of the enclosing group or to the end of the pattern; they require
|
|
the tt(EXTENDED_GLOB) option. All take the form
|
|
tt(LPAR()#)var(X)tt(RPAR()) where var(X) may have one of the following
|
|
forms:
|
|
|
|
startitem()
|
|
item(i)(
|
|
Case insensitive: upper or lower case characters in the pattern match
|
|
upper or lower case characters.
|
|
)
|
|
item(l)(
|
|
Lower case characters in the pattern match upper or lower case
|
|
characters; upper case characters in the pattern still only match
|
|
upper case characters.
|
|
)
|
|
item(I)(
|
|
Case sensitive: locally negates the effect of tt(i) or tt(l) from
|
|
that point on.
|
|
)
|
|
item(b)(
|
|
Activate backreferences for parenthesised groups in the pattern;
|
|
this does not work in filename generation. When a pattern with a set of
|
|
active parentheses is matched, the strings matched by the groups are
|
|
stored in the array tt($match), the indices of the beginning of the matched
|
|
parentheses in the array tt($mbegin), and the indices of the end in the array
|
|
tt($mend), with the first element of each array corresponding to the first
|
|
parenthesised group, and so on. These arrays are not otherwise special to
|
|
the shell. The indices use the same convention as does parameter
|
|
substitution, so that elements of tt($mend) and tt($mbegin) may be used in
|
|
subscripts; the tt(KSH_ARRAYS) option is respected. Sets of globbing flags
|
|
are not considered parenthesised groups; only the first nine active
|
|
parentheses can be referenced.
|
|
|
|
For example,
|
|
|
|
example(foo="a string with a message"
|
|
if [[ $foo = (a|an)' '(#b)(*)' '* ]]; then
|
|
print ${foo[$mbegin[1],$mend[1]]}
|
|
fi)
|
|
|
|
prints `tt(string with a)'. Note that the first parenthesis is before the
|
|
tt((#b)) and does not create a backreference.
|
|
|
|
Backreferences work with all forms of pattern matching other than filename
|
|
generation, but note that when performing matches on an entire array, such
|
|
as tt(${)var(array)tt(#)var(pattern)tt(}), or a global substitution, such
|
|
as tt(${)var(param)tt(//)var(pat)tt(/)var(repl)tt(}), only the data for the
|
|
last match remains available. In the case of global replacements this may
|
|
still be useful. See the example for the tt(m) flag below.
|
|
|
|
The numbering of backreferences strictly follows the order of the opening
|
|
parentheses from left to right in the pattern string, although sets of
|
|
parentheses may be nested. There are special rules for parentheses followed
|
|
by `tt(#)' or `tt(##)'. Only the last match of the parenthesis is
|
|
remembered: for example, in `tt([[ abab = (#b)([ab])# ]])', only the final
|
|
`tt(b)' is stored in tt(match[1]). Thus extra parentheses may be necessary
|
|
to match the complete segment: for example, use `tt(X((ab|cd)#)Y)' to match
|
|
a whole string of either `tt(ab)' or `tt(cd)' between `tt(X)' and `tt(Y)',
|
|
using the value of tt($match[1]) rather than tt($match[2]).
|
|
|
|
If the match fails none of the parameters is altered, so in some cases it
|
|
may be necessary to initialise them beforehand. If some of the
|
|
backreferences fail to match DASH()- which happens if they are in an alternate
|
|
branch which fails to match, or if they are followed by tt(#) and matched
|
|
zero times DASH()- then the matched string is set to the empty string, and the
|
|
start and end indices are set to -1.
|
|
|
|
Pattern matching with backreferences is slightly slower than without.
|
|
)
|
|
item(B)(
|
|
Deactivate backreferences, negating the effect of the tt(b) flag from that
|
|
point on.
|
|
)
|
|
item(m)(
|
|
Set references to the match data for the entire string matched; this is
|
|
similar to backreferencing and does not work in filename generation. The
|
|
flag must be in effect at the end of the pattern, i.e. not local to a
|
|
group. The parameters tt($MATCH), tt($MBEGIN) and tt($MEND) will be set to
|
|
the string matched and to the indices of the beginning and end of the
|
|
string, respectively. This is most useful in parameter substitutions, as
|
|
otherwise the string matched is obvious.
|
|
|
|
For example,
|
|
|
|
example(arr=(veldt jynx grimps waqf zho buck)
|
|
print ${arr//(#m)[aeiou]/${(U)MATCH}})
|
|
|
|
forces all the matches (i.e. all vowels) into uppercase, printing
|
|
`tt(vEldt jynx grImps wAqf zhO bUck)'.
|
|
|
|
Unlike backreferences, there is no speed penalty for using match
|
|
references, other than the extra substitutions required for the
|
|
replacement strings in cases such as the example shown.
|
|
)
|
|
item(M)(
|
|
Deactivate the tt(m) flag, hence no references to match data will be
|
|
created.
|
|
)
|
|
item(tt(a)var(num))(
|
|
Approximate matching: var(num) errors are allowed in the string matched by
|
|
the pattern. The rules for this are described in the next subsection.
|
|
)
|
|
item(tt(s), tt(e))(
|
|
Unlike the other flags, these have only a local effect, and each must
|
|
appear on its own: `tt((#s))' and `tt((#e))' are the only valid forms.
|
|
The `tt((#s))' flag succeeds only at the start of the test string, and the
|
|
`tt((#e))' flag succeeds only at the end of the test string; they
|
|
correspond to `tt(^)' and `tt($)' in standard regular expressions. They
|
|
are useful for matching path segments in patterns other than those in
|
|
filename generation (where path segments are in any case treated
|
|
separately). For example, `tt(*((#s)|/)test((#e)|/)*)' matches a path
|
|
segment `tt(test)' in any of the following strings: tt(test),
|
|
tt(test/at/start), tt(at/end/test), tt(in/test/middle).
|
|
|
|
Another use is in parameter substitution; for example
|
|
`tt(${array/(#s)A*Z(#e)})' will remove only elements of an array which
|
|
match the complete pattern `tt(A*Z)'. There are other ways of performing
|
|
many operations of this type, however the combination of the substitution
|
|
operations `tt(/)' and `tt(//)' with the `tt((#s))' and `tt((#e))' flags
|
|
provides a single simple and memorable method.
|
|
|
|
Note that assertions of the form `tt((^(#s)))' also work, i.e. match
|
|
anywhere except at the start of the string, although this actually means
|
|
`anything except a zero-length portion at the start of the string'; you
|
|
need to use `tt((""~(#s)))' to match a zero-length portion of the string
|
|
not at the start.
|
|
)
|
|
item(tt(q))(
|
|
A `tt(q)' and everything up to the closing parenthesis of the globbing
|
|
flags are ignored by the pattern matching code. This is intended to
|
|
support the use of glob qualifiers, see below. The result is that
|
|
the pattern `tt((#b)(*).c(#q.))' can be used both for globbing and for
|
|
matching against a string. In the former case, the `tt((#q.))' will be
|
|
treated as a glob qualifier and the `tt((#b))' will not be useful, while in
|
|
the latter case the `tt((#b))' is useful for backreferences and the
|
|
`tt((#q.))' will be ignored. Note that colon modifiers in the glob
|
|
qualifiers are also not applied in ordinary pattern matching.
|
|
)
|
|
enditem()
|
|
|
|
For example, the test string tt(fooxx) can be matched by the pattern
|
|
tt(LPAR()#i)tt(RPAR()FOOXX), but not by tt(LPAR()#l)tt(RPAR()FOOXX),
|
|
tt(LPAR()#i)tt(RPAR()FOO)tt(LPAR()#I)tt(RPAR()XX) or
|
|
tt(LPAR()LPAR()#i)tt(RPAR()FOOX)tt(RPAR()X). The string
|
|
tt(LPAR()#ia2)tt(RPAR()readme) specifies case-insensitive matching of
|
|
tt(readme) with up to two errors.
|
|
|
|
When using the ksh syntax for grouping both tt(KSH_GLOB) and
|
|
tt(EXTENDED_GLOB) must be set and the left parenthesis should be
|
|
preceded by tt(@). Note also that the flags do not affect letters
|
|
inside tt([...]) groups, in other words tt(LPAR()#i)tt(RPAR()[a-z])
|
|
still matches only lowercase letters. Finally, note that when
|
|
examining whole paths case-insensitively every directory must be
|
|
searched for all files which match, so that a pattern of the form
|
|
tt(LPAR()#i)tt(RPAR()/foo/bar/...) is potentially slow.
|
|
|
|
subsect(Approximate Matching)
|
|
When matching approximately, the shell keeps a count of the errors found,
|
|
which cannot exceed the number specified in the
|
|
tt(LPAR()#a)var(num)tt(RPAR()) flags. Four types of error are recognised:
|
|
|
|
startitem()
|
|
item(1.)(
|
|
Different characters, as in tt(fooxbar) and tt(fooybar).
|
|
)
|
|
item(2.)(
|
|
Transposition of characters, as in tt(banana) and tt(abnana).
|
|
)
|
|
item(3.)(
|
|
A character missing in the target string, as with the pattern tt(road) and
|
|
target string tt(rod).
|
|
)
|
|
item(4.)(
|
|
An extra character appearing in the target string, as with tt(stove)
|
|
and tt(strove).
|
|
)
|
|
enditem()
|
|
|
|
Thus, the pattern tt(LPAR()#a3)tt(RPAR()abcd) matches tt(dcba), with the
|
|
errors occurring by using the first rule twice and the second once,
|
|
grouping the string as tt([d][cb][a]) and tt([a][bc][d]).
|
|
|
|
Non-literal parts of the pattern must match exactly, including characters
|
|
in character ranges: hence tt(LPAR()#a1)tt(RPAR()???) matches strings of
|
|
length four, by applying rule 4 to an empty part of the pattern, but not
|
|
strings of length two, since all the tt(?) must match. Other characters
|
|
which must match exactly are initial dots in filenames (unless the
|
|
tt(GLOB_DOTS) option is set), and all slashes in filenames, so that
|
|
tt(a/bc) is two errors from tt(ab/c) (the slash cannot be transposed with
|
|
another character). Similarly, errors are counted separately for
|
|
non-contiguous strings in the pattern, so that tt(LPAR()ab|cd)tt(RPAR()ef)
|
|
is two errors from tt(aebf).
|
|
|
|
When using exclusion via the tt(~) operator, approximate matching is
|
|
treated entirely separately for the excluded part and must be activated
|
|
separately. Thus, tt(LPAR()#a1)tt(RPAR()README~READ_ME) matches
|
|
tt(READ.ME) but not tt(READ_ME), as the trailing tt(READ_ME) is matched
|
|
without approximation. However,
|
|
tt(LPAR()#a1)tt(RPAR()README~LPAR()#a1)tt(RPAR()READ_ME)
|
|
does not match any pattern of the form tt(READ)var(?)tt(ME) as all
|
|
such forms are now excluded.
|
|
|
|
Apart from exclusions, there is only one overall error count; however, the
|
|
maximum errors allowed may be altered locally, and this can be delimited by
|
|
grouping. For example,
|
|
tt(LPAR()#a1)tt(RPAR()cat)tt(LPAR()LPAR()#a0)tt(RPAR()dog)tt(RPAR()fox)
|
|
allows one error in total, which may not occur in the tt(dog) section, and
|
|
the pattern
|
|
tt(LPAR()#a1)tt(RPAR()cat)tt(LPAR()#a0)tt(RPAR()dog)tt(LPAR()#a1)tt(RPAR()fox)
|
|
is equivalent. Note that the point at which an error is first found is the
|
|
crucial one for establishing whether to use approximation; for example,
|
|
tt((#a1)abc(#a0)xyz) will not match tt(abcdxyz), because the error occurs
|
|
at the `tt(x)', where approximation is turned off.
|
|
|
|
Entire path segments may be matched approximately, so that
|
|
`tt((#a1)/foo/d/is/available/at/the/bar)' allows one error in any path
|
|
segment. This is much less efficient than without the tt((#a1)), however,
|
|
since every directory in the path must be scanned for a possible
|
|
approximate match. It is best to place the tt((#a1)) after any path
|
|
segments which are known to be correct.
|
|
|
|
subsect(Recursive Globbing)
|
|
A pathname component of the form `tt(LPAR())var(foo)tt(/RPAR()#)'
|
|
matches a path consisting of zero or more directories
|
|
matching the pattern var(foo).
|
|
|
|
As a shorthand, `tt(**/)' is equivalent to `tt((*/)#)'; note that this
|
|
therefore matches files in the current directory as well as
|
|
subdirectories.
|
|
Thus:
|
|
|
|
example(ls (*/)#bar)
|
|
|
|
or
|
|
|
|
example(ls **/bar)
|
|
|
|
does a recursive directory search for files named `tt(bar)' (potentially
|
|
including the file `tt(bar)' in the current directory). This form does not
|
|
follow symbolic links; the alternative form `tt(***/)' does, but is
|
|
otherwise identical. Neither of these can be combined with other forms of
|
|
globbing within the same path segment; in that case, the `tt(*)'
|
|
operators revert to their usual effect.
|
|
subsect(Glob Qualifiers)
|
|
cindex(globbing, qualifiers)
|
|
cindex(qualifiers, globbing)
|
|
Patterns used for filename generation may end in a
|
|
list of qualifiers enclosed in parentheses.
|
|
The qualifiers specify which filenames that otherwise match the given pattern
|
|
will be inserted in the argument list.
|
|
|
|
pindex(BARE_GLOB_QUAL, use of)
|
|
If the option tt(BARE_GLOB_QUAL) is set, then a trailing set of parentheses
|
|
containing no `tt(|)' or `tt(LPAR())' characters (or `tt(~)' if it is special)
|
|
is taken as a set of
|
|
glob qualifiers. A glob subexpression that would normally be taken as glob
|
|
qualifiers, for example `tt((^x))', can be forced to be treated as part of
|
|
the glob pattern by doubling the parentheses, in this case producing
|
|
`tt(((^x)))'.
|
|
|
|
If the option tt(EXTENDED_GLOB) is set, a different syntax for glob
|
|
qualifiers is available, namely `tt((#qx))' where tt(x) is any of the same
|
|
glob qualifiers used in the other format. The qualifiers must still appear
|
|
at the end of the pattern. However, with this syntax multiple glob
|
|
qualifiers may be chained together. They are treated as a logical AND of
|
|
the individual sets of flags. Also, as the syntax is unambiguous, the
|
|
expression will be treated as glob qualifiers just as long any parentheses
|
|
contained within it are balanced; appearance of `tt(|)', `tt(LPAR())' or
|
|
`tt(~)' does not negate the effect. Note that qualifiers will be
|
|
recognised in this form even if a bare glob qualifier exists at the end of
|
|
the pattern, for example `tt(*(#q*)(.))' will recognise executable regular
|
|
files if both options are set; however, mixed syntax should probably be
|
|
avoided for the sake of clarity.
|
|
|
|
A qualifier may be any one of the following:
|
|
|
|
startitem()
|
|
item(tt(/))(
|
|
directories
|
|
)
|
|
item(tt(F))(
|
|
`full' (i.e. non-empty) directories. Note that the
|
|
opposite sense tt(LPAR()^F)tt(RPAR()) expands to empty directories
|
|
and all non-directories. Use tt(LPAR()/^F)tt(RPAR()) for
|
|
empty directories
|
|
)
|
|
item(tt(.))(
|
|
plain files
|
|
)
|
|
item(tt(@))(
|
|
symbolic links
|
|
)
|
|
item(tt(=))(
|
|
sockets
|
|
)
|
|
item(tt(p))(
|
|
named pipes (FIFOs)
|
|
)
|
|
item(tt(*))(
|
|
executable plain files (0100)
|
|
)
|
|
item(tt(%))(
|
|
device files (character or block special)
|
|
)
|
|
item(tt(%b))(
|
|
block special files
|
|
)
|
|
item(tt(%c))(
|
|
character special files
|
|
)
|
|
item(tt(r))(
|
|
owner-readable files (0400)
|
|
)
|
|
item(tt(w))(
|
|
owner-writable files (0200)
|
|
)
|
|
item(tt(x))(
|
|
owner-executable files (0100)
|
|
)
|
|
item(tt(A))(
|
|
group-readable files (0040)
|
|
)
|
|
item(tt(I))(
|
|
group-writable files (0020)
|
|
)
|
|
item(tt(E))(
|
|
group-executable files (0010)
|
|
)
|
|
item(tt(R))(
|
|
world-readable files (0004)
|
|
)
|
|
item(tt(W))(
|
|
world-writable files (0002)
|
|
)
|
|
item(tt(X))(
|
|
world-executable files (0001)
|
|
)
|
|
item(tt(s))(
|
|
setuid files (04000)
|
|
)
|
|
item(tt(S))(
|
|
setgid files (02000)
|
|
)
|
|
item(tt(t))(
|
|
files with the sticky bit (01000)
|
|
)
|
|
item(tt(f)var(spec))(
|
|
files with access rights matching var(spec). This var(spec) may be a
|
|
octal number optionally preceded by a `tt(=)', a `tt(PLUS())', or a
|
|
`tt(-)'. If none of these characters is given, the behavior is the
|
|
same as for `tt(=)'. The octal number describes the mode bits to be
|
|
expected, if combined with a `tt(=)', the value given must match the
|
|
file-modes exactly, with a `tt(PLUS())', at least the bits in the
|
|
given number must be set in the file-modes, and with a `tt(-)', the
|
|
bits in the number must not be set. Giving a `tt(?)' instead of a
|
|
octal digit anywhere in the number ensures that the corresponding bits
|
|
in the file-modes are not checked, this is only useful in combination
|
|
with `tt(=)'.
|
|
|
|
If the qualifier `tt(f)' is followed by any other character anything
|
|
up to the next matching character (`tt([)', `tt({)', and `tt(<)' match
|
|
`tt(])', `tt(})', and `tt(>)' respectively, any other character
|
|
matches itself) is taken as a list of comma-separated
|
|
var(sub-spec)s. Each var(sub-spec) may be either an octal number as
|
|
described above or a list of any of the characters `tt(u)', `tt(g)',
|
|
`tt(o)', and `tt(a)', followed by a `tt(=)', a `tt(PLUS())', or a
|
|
`tt(-)', followed by a list of any of the characters `tt(r)', `tt(w)',
|
|
`tt(x)', `tt(s)', and `tt(t)', or an octal digit. The first list of
|
|
characters specify which access rights are to be checked. If a `tt(u)'
|
|
is given, those for the owner of the file are used, if a `tt(g)' is
|
|
given, those of the group are checked, a `tt(o)' means to test those
|
|
of other users, and the `tt(a)' says to test all three groups. The
|
|
`tt(=)', `tt(PLUS())', and `tt(-)' again says how the modes are to be
|
|
checked and have the same meaning as described for the first form
|
|
above. The second list of characters finally says which access rights
|
|
are to be expected: `tt(r)' for read access, `tt(w)' for write access,
|
|
`tt(x)' for the right to execute the file (or to search a directory),
|
|
`tt(s)' for the setuid and setgid bits, and `tt(t)' for the sticky
|
|
bit.
|
|
|
|
Thus, `tt(*(f70?))' gives the files for which the owner has read,
|
|
write, and execute permission, and for which other group members have
|
|
no rights, independent of the permissions for other users. The pattern
|
|
`tt(*(f-100))' gives all files for which the owner does not have
|
|
execute permission, and `tt(*(f:gu+w,o-rx:))' gives the files for which
|
|
the owner and the other members of the group have at least write
|
|
permission, and for which other users don't have read or execute
|
|
permission.
|
|
)
|
|
xitem(tt(e)var(string))
|
|
item(tt(PLUS())var(cmd))(
|
|
The var(string) will be executed as shell code. The filename will be
|
|
included in the list if and only if the code returns a zero status (usually
|
|
the status of the last command). The first character after the `tt(e)'
|
|
will be used as a separator and anything up to the next matching separator
|
|
will be taken as the var(string); `tt([)', `tt({)', and `tt(<)' match
|
|
`tt(])', `tt(})', and `tt(>)', respectively, while any other character
|
|
matches itself. Note that expansions must be quoted in the var(string)
|
|
to prevent them from being expanded before globbing is done.
|
|
|
|
vindex(REPLY, use of)
|
|
vindex(reply, use of)
|
|
During the execution of var(string) the filename currently being tested is
|
|
available in the parameter tt(REPLY); the parameter may be altered to
|
|
a string to be inserted into the list instead of the original
|
|
filename. In addition, the parameter tt(reply) may be set to an array or a
|
|
string, which overrides the value of tt(REPLY). If set to an array, the
|
|
latter is inserted into the command line word by word.
|
|
|
|
For example, suppose a directory contains a single file `tt(lonely)'. Then
|
|
the expression `tt(*(e:'reply=(${REPLY}{1,2})':))' will cause the words
|
|
`tt(lonely1 lonely2)' to be inserted into the command line. Note the
|
|
quotation marks.
|
|
|
|
The form tt(PLUS())var(cmd) has the same effect, but no delimiters appear
|
|
around var(cmd). Instead, var(cmd) is taken as the longest sequence of
|
|
characters following the tt(PLUS()) that are alphanumeric or underscore.
|
|
Typically var(cmd) will be the name of a shell function that contains the
|
|
appropriate test. For example,
|
|
|
|
example(nt() { [[ $REPLY -nt $NTREF ]] }
|
|
NTREF=reffile
|
|
ls -l *(+nt))
|
|
|
|
lists all files in the directory that have been modified more recently than
|
|
tt(reffile).
|
|
)
|
|
item(tt(d)var(dev))(
|
|
files on the device var(dev)
|
|
)
|
|
item(tt(l)[tt(-)|tt(PLUS())]var(ct))(
|
|
files having a link count less than var(ct) (tt(-)), greater than
|
|
var(ct) (tt(PLUS())), or equal to var(ct)
|
|
)
|
|
item(tt(U))(
|
|
files owned by the effective user ID
|
|
)
|
|
item(tt(G))(
|
|
files owned by the effective group ID
|
|
)
|
|
item(tt(u)var(id))(
|
|
files owned by user ID var(id) if that is a number. Otherwise,
|
|
var(id) specifies a user name: the
|
|
character after the `tt(u)' will be taken as a separator and the string
|
|
between it and the next matching separator will be taken as a user name.
|
|
The starting separators `tt([)', `tt({)', and `tt(<)'
|
|
match the final separators `tt(])', `tt(})', and `tt(>)', respectively;
|
|
any other character matches itself. The selected files are those
|
|
owned by this user. For example, `tt(u:foo:)' or `tt(u[foo])' selects
|
|
files owned by user `tt(foo)'.
|
|
)
|
|
item(tt(g)var(id))(
|
|
like tt(u)var(id) but with group IDs or names
|
|
)
|
|
item(tt(a)[tt(Mwhms)][tt(-)|tt(PLUS())]var(n))(
|
|
files accessed exactly var(n) days ago. Files accessed within the last
|
|
var(n) days are selected using a negative value for var(n) (tt(-)var(n)).
|
|
Files accessed more than var(n) days ago are selected by a positive var(n)
|
|
value (tt(PLUS())var(n)). Optional unit specifiers `tt(M)', `tt(w)',
|
|
`tt(h)', `tt(m)' or `tt(s)' (e.g. `tt(ah5)') cause the check to be
|
|
performed with months (of 30 days), weeks, hours, minutes or seconds
|
|
instead of days, respectively. For instance, `tt(echo *(ah-5))' would
|
|
echo files accessed within the last five hours.
|
|
)
|
|
item(tt(m)[tt(Mwhms)][tt(-)|tt(PLUS())]var(n))(
|
|
like the file access qualifier, except that it uses the file modification
|
|
time.
|
|
)
|
|
item(tt(c)[tt(Mwhms)][tt(-)|tt(PLUS())]var(n))(
|
|
like the file access qualifier, except that it uses the file inode change
|
|
time.
|
|
)
|
|
item(tt(L)[tt(PLUS())|tt(-)]var(n))(
|
|
files less than var(n) bytes (tt(-)), more than var(n) bytes (tt(PLUS())), or
|
|
exactly var(n) bytes in length. If this flag is directly followed by a `tt(k)'
|
|
(`tt(K)'), `tt(m)' (`tt(M)'), or `tt(p)' (`tt(P)') (e.g. `tt(Lk-50)')
|
|
the check is performed with kilobytes, megabytes, or blocks (of 512 bytes)
|
|
instead.
|
|
)
|
|
item(tt(^))(
|
|
negates all qualifiers following it
|
|
)
|
|
item(tt(-))(
|
|
toggles between making the qualifiers work on symbolic links (the
|
|
default) and the files they point to
|
|
)
|
|
item(tt(M))(
|
|
sets the tt(MARK_DIRS) option for the current pattern
|
|
pindex(MARK_DIRS, setting in pattern)
|
|
)
|
|
item(tt(T))(
|
|
appends a trailing qualifier mark to the filenames, analogous to the
|
|
tt(LIST_TYPES) option, for the current pattern (overrides tt(M))
|
|
)
|
|
item(tt(N))(
|
|
sets the tt(NULL_GLOB) option for the current pattern
|
|
pindex(NULL_GLOB, setting in pattern)
|
|
)
|
|
item(tt(D))(
|
|
sets the tt(GLOB_DOTS) option for the current pattern
|
|
pindex(GLOB_DOTS, setting in pattern)
|
|
)
|
|
item(tt(n))(
|
|
sets the tt(NUMERIC_GLOB_SORT) option for the current pattern
|
|
pindex(NUMERIC_GLOB_SORT, setting in pattern)
|
|
)
|
|
item(tt(o)var(c))(
|
|
specifies how the names of the files should be sorted. If var(c) is
|
|
tt(n) they are sorted by name (the default); if it is tt(L) they
|
|
are sorted depending on the size (length) of the files; if tt(l)
|
|
they are sorted by the number of links; if tt(a), tt(m), or tt(c)
|
|
they are sorted by the time of the last access, modification, or
|
|
inode change respectively; if tt(d), files in subdirectories appear before
|
|
those in the current directory at each level of the search DASH()- this is best
|
|
combined with other criteria, for example `tt(odon)' to sort on names for
|
|
files within the same directory; if tt(N), no sorting is performed.
|
|
Note that tt(a), tt(m), and tt(c) compare
|
|
the age against the current time, hence the first name in the list is the
|
|
youngest file. Also note that the modifiers tt(^) and tt(-) are used,
|
|
so `tt(*(^-oL))' gives a list of all files sorted by file size in descending
|
|
order, following any symbolic links. Unless tt(oN) is used, multiple order
|
|
specifiers may occur to resolve ties.
|
|
)
|
|
item(tt(O)var(c))(
|
|
like `tt(o)', but sorts in descending order; i.e. `tt(*(^oc))' is the
|
|
same as `tt(*(Oc))' and `tt(*(^Oc))' is the same as `tt(*(oc))'; `tt(Od)'
|
|
puts files in the current directory before those in subdirectories at each
|
|
level of the search.
|
|
)
|
|
item(tt([)var(beg)[tt(,)var(end)]tt(]))(
|
|
specifies which of the matched filenames should be included in the
|
|
returned list. The syntax is the same as for array
|
|
subscripts. var(beg) and the optional var(end) may be mathematical
|
|
expressions. As in parameter subscripting they may be negative to make
|
|
them count from the last match backward. E.g.: `tt(*(-OL[1,3]))'
|
|
gives a list of the names of the three largest files.
|
|
)
|
|
enditem()
|
|
|
|
More than one of these lists can be combined, separated by commas. The
|
|
whole list matches if at least one of the sublists matches (they are
|
|
`or'ed, the qualifiers in the sublists are `and'ed). Some qualifiers,
|
|
however, affect all matches generated, independent of the sublist in
|
|
which they are given. These are the qualifiers `tt(M)', `tt(T)',
|
|
`tt(N)', `tt(D)', `tt(n)', `tt(o)', `tt(O)' and the subscripts given
|
|
in brackets (`tt([...])').
|
|
|
|
If a `tt(:)' appears in a qualifier list, the remainder of the expression in
|
|
parenthesis is interpreted as a modifier (see noderef(Modifiers)
|
|
in noderef(History Expansion)). Note that
|
|
each modifier must be introduced by a separate `tt(:)'. Note also that the
|
|
result after modification does not have to be an existing file. The
|
|
name of any existing file can be followed by a modifier of the form
|
|
`tt((:..))' even if no actual filename generation is performed.
|
|
Thus:
|
|
|
|
example(ls *(-/))
|
|
|
|
lists all directories and symbolic links that point to directories,
|
|
and
|
|
|
|
example(ls *(%W))
|
|
|
|
lists all world-writable device files in the current directory, and
|
|
|
|
example(ls *(W,X))
|
|
|
|
lists all files in the current directory that are
|
|
world-writable or world-executable, and
|
|
|
|
example(echo /tmp/foo*(u0^@:t))
|
|
|
|
outputs the basename of all root-owned files beginning with the string
|
|
`tt(foo)' in tt(/tmp), ignoring symlinks, and
|
|
|
|
example(ls *.*~(lex|parse).[ch](^D^l1))
|
|
|
|
lists all files having a link count of one whose names contain a dot
|
|
(but not those starting with a dot, since tt(GLOB_DOTS) is explicitly
|
|
switched off) except for tt(lex.c), tt(lex.h), tt(parse.c) and tt(parse.h).
|
|
|
|
example(print b*.pro(#q:s/pro/shmo/)(#q.:s/builtin/shmiltin/))
|
|
|
|
demonstrates how colon modifiers and other qualifiers may be chained
|
|
together. The ordinary qualifier `tt(.)' is applied first, then the colon
|
|
modifiers in order from left to right. So if tt(EXTENDED_GLOB) is set and
|
|
the base pattern matches the regular file tt(builtin.pro), the shell will
|
|
print `tt(shmiltin.shmo)'.
|