]>
Commit | Line | Data |
---|---|---|
28f540f4 | 1 | @node Pattern Matching, I/O Overview, Searching and Sorting, Top |
7a68c94a | 2 | @c %MENU% Matching shell ``globs'' and regular expressions |
28f540f4 RM |
3 | @chapter Pattern Matching |
4 | ||
5 | The GNU C Library provides pattern matching facilities for two kinds of | |
6 | patterns: regular expressions and file-name wildcards. The library also | |
7 | provides a facility for expanding variable and command references and | |
8 | parsing text into words in the way the shell does. | |
9 | ||
10 | @menu | |
11 | * Wildcard Matching:: Matching a wildcard pattern against a single string. | |
12 | * Globbing:: Finding the files that match a wildcard pattern. | |
13 | * Regular Expressions:: Matching regular expressions against strings. | |
14 | * Word Expansion:: Expanding shell variables, nested commands, | |
15 | arithmetic, and wildcards. | |
16 | This is what the shell does with shell commands. | |
17 | @end menu | |
18 | ||
19 | @node Wildcard Matching | |
20 | @section Wildcard Matching | |
21 | ||
22 | @pindex fnmatch.h | |
23 | This section describes how to match a wildcard pattern against a | |
24 | particular string. The result is a yes or no answer: does the | |
25 | string fit the pattern or not. The symbols described here are all | |
26 | declared in @file{fnmatch.h}. | |
27 | ||
28 | @comment fnmatch.h | |
29 | @comment POSIX.2 | |
30 | @deftypefun int fnmatch (const char *@var{pattern}, const char *@var{string}, int @var{flags}) | |
31 | This function tests whether the string @var{string} matches the pattern | |
32 | @var{pattern}. It returns @code{0} if they do match; otherwise, it | |
33 | returns the nonzero value @code{FNM_NOMATCH}. The arguments | |
34 | @var{pattern} and @var{string} are both strings. | |
35 | ||
36 | The argument @var{flags} is a combination of flag bits that alter the | |
37 | details of matching. See below for a list of the defined flags. | |
38 | ||
39 | In the GNU C Library, @code{fnmatch} cannot experience an ``error''---it | |
40 | always returns an answer for whether the match succeeds. However, other | |
41 | implementations of @code{fnmatch} might sometimes report ``errors''. | |
42 | They would do so by returning nonzero values that are not equal to | |
43 | @code{FNM_NOMATCH}. | |
44 | @end deftypefun | |
45 | ||
46 | These are the available flags for the @var{flags} argument: | |
47 | ||
48 | @table @code | |
49 | @comment fnmatch.h | |
50 | @comment GNU | |
51 | @item FNM_FILE_NAME | |
52 | Treat the @samp{/} character specially, for matching file names. If | |
53 | this flag is set, wildcard constructs in @var{pattern} cannot match | |
54 | @samp{/} in @var{string}. Thus, the only way to match @samp{/} is with | |
55 | an explicit @samp{/} in @var{pattern}. | |
56 | ||
57 | @comment fnmatch.h | |
58 | @comment POSIX.2 | |
59 | @item FNM_PATHNAME | |
60 | This is an alias for @code{FNM_FILE_NAME}; it comes from POSIX.2. We | |
61 | don't recommend this name because we don't use the term ``pathname'' for | |
62 | file names. | |
63 | ||
64 | @comment fnmatch.h | |
65 | @comment POSIX.2 | |
66 | @item FNM_PERIOD | |
67 | Treat the @samp{.} character specially if it appears at the beginning of | |
68 | @var{string}. If this flag is set, wildcard constructs in @var{pattern} | |
69 | cannot match @samp{.} as the first character of @var{string}. | |
70 | ||
71 | If you set both @code{FNM_PERIOD} and @code{FNM_FILE_NAME}, then the | |
72 | special treatment applies to @samp{.} following @samp{/} as well as to | |
73 | @samp{.} at the beginning of @var{string}. (The shell uses the | |
6952e59e | 74 | @code{FNM_PERIOD} and @code{FNM_FILE_NAME} flags together for matching |
28f540f4 RM |
75 | file names.) |
76 | ||
77 | @comment fnmatch.h | |
78 | @comment POSIX.2 | |
79 | @item FNM_NOESCAPE | |
80 | Don't treat the @samp{\} character specially in patterns. Normally, | |
81 | @samp{\} quotes the following character, turning off its special meaning | |
82 | (if any) so that it matches only itself. When quoting is enabled, the | |
83 | pattern @samp{\?} matches only the string @samp{?}, because the question | |
84 | mark in the pattern acts like an ordinary character. | |
85 | ||
86 | If you use @code{FNM_NOESCAPE}, then @samp{\} is an ordinary character. | |
87 | ||
88 | @comment fnmatch.h | |
89 | @comment GNU | |
90 | @item FNM_LEADING_DIR | |
91 | Ignore a trailing sequence of characters starting with a @samp{/} in | |
92 | @var{string}; that is to say, test whether @var{string} starts with a | |
93 | directory name that @var{pattern} matches. | |
94 | ||
95 | If this flag is set, either @samp{foo*} or @samp{foobar} as a pattern | |
96 | would match the string @samp{foobar/frobozz}. | |
97 | ||
98 | @comment fnmatch.h | |
99 | @comment GNU | |
100 | @item FNM_CASEFOLD | |
101 | Ignore case in comparing @var{string} to @var{pattern}. | |
821a6bb4 UD |
102 | |
103 | @comment fnmatch.h | |
104 | @comment GNU | |
105 | @item FNM_EXTMATCH | |
106 | @cindex Korn Shell | |
107 | @pindex ksh | |
108 | Recognize beside the normal patterns also the extended patterns | |
109 | introduced in @file{ksh}. The patterns are written in the form | |
110 | explained in the following table where @var{pattern-list} is a @code{|} | |
111 | separated list of patterns. | |
112 | ||
113 | @table @code | |
114 | @item ?(@var{pattern-list}) | |
0bc93a2f | 115 | The pattern matches if zero or one occurrences of any of the patterns |
821a6bb4 UD |
116 | in the @var{pattern-list} allow matching the input string. |
117 | ||
118 | @item *(@var{pattern-list}) | |
0bc93a2f | 119 | The pattern matches if zero or more occurrences of any of the patterns |
821a6bb4 UD |
120 | in the @var{pattern-list} allow matching the input string. |
121 | ||
122 | @item +(@var{pattern-list}) | |
0bc93a2f | 123 | The pattern matches if one or more occurrences of any of the patterns |
821a6bb4 UD |
124 | in the @var{pattern-list} allow matching the input string. |
125 | ||
126 | @item @@(@var{pattern-list}) | |
0bc93a2f | 127 | The pattern matches if exactly one occurrence of any of the patterns in |
821a6bb4 UD |
128 | the @var{pattern-list} allows matching the input string. |
129 | ||
130 | @item !(@var{pattern-list}) | |
131 | The pattern matches if the input string cannot be matched with any of | |
132 | the patterns in the @var{pattern-list}. | |
133 | @end table | |
28f540f4 RM |
134 | @end table |
135 | ||
136 | @node Globbing | |
137 | @section Globbing | |
138 | ||
139 | @cindex globbing | |
140 | The archetypal use of wildcards is for matching against the files in a | |
141 | directory, and making a list of all the matches. This is called | |
142 | @dfn{globbing}. | |
143 | ||
144 | You could do this using @code{fnmatch}, by reading the directory entries | |
145 | one by one and testing each one with @code{fnmatch}. But that would be | |
146 | slow (and complex, since you would have to handle subdirectories by | |
147 | hand). | |
148 | ||
149 | The library provides a function @code{glob} to make this particular use | |
150 | of wildcards convenient. @code{glob} and the other symbols in this | |
151 | section are declared in @file{glob.h}. | |
152 | ||
153 | @menu | |
714a562f UD |
154 | * Calling Glob:: Basic use of @code{glob}. |
155 | * Flags for Globbing:: Flags that enable various options in @code{glob}. | |
156 | * More Flags for Globbing:: GNU specific extensions to @code{glob}. | |
28f540f4 RM |
157 | @end menu |
158 | ||
159 | @node Calling Glob | |
160 | @subsection Calling @code{glob} | |
161 | ||
162 | The result of globbing is a vector of file names (strings). To return | |
163 | this vector, @code{glob} uses a special data type, @code{glob_t}, which | |
164 | is a structure. You pass @code{glob} the address of the structure, and | |
165 | it fills in the structure's fields to tell you about the results. | |
166 | ||
167 | @comment glob.h | |
168 | @comment POSIX.2 | |
169 | @deftp {Data Type} glob_t | |
170 | This data type holds a pointer to a word vector. More precisely, it | |
714a562f UD |
171 | records both the address of the word vector and its size. The GNU |
172 | implementation contains some more fields which are non-standard | |
173 | extensions. | |
28f540f4 RM |
174 | |
175 | @table @code | |
176 | @item gl_pathc | |
460adbb8 UD |
177 | The number of elements in the vector, excluding the initial null entries |
178 | if the GLOB_DOOFFS flag is used (see gl_offs below). | |
28f540f4 RM |
179 | |
180 | @item gl_pathv | |
181 | The address of the vector. This field has type @w{@code{char **}}. | |
182 | ||
183 | @item gl_offs | |
184 | The offset of the first real element of the vector, from its nominal | |
185 | address in the @code{gl_pathv} field. Unlike the other fields, this | |
186 | is always an input to @code{glob}, rather than an output from it. | |
187 | ||
188 | If you use a nonzero offset, then that many elements at the beginning of | |
189 | the vector are left empty. (The @code{glob} function fills them with | |
190 | null pointers.) | |
191 | ||
192 | The @code{gl_offs} field is meaningful only if you use the | |
193 | @code{GLOB_DOOFFS} flag. Otherwise, the offset is always zero | |
194 | regardless of what is in this field, and the first real element comes at | |
195 | the beginning of the vector. | |
714a562f UD |
196 | |
197 | @item gl_closedir | |
198 | The address of an alternative implementation of the @code{closedir} | |
199 | function. It is used if the @code{GLOB_ALTDIRFUNC} bit is set in | |
200 | the flag parameter. The type of this field is | |
201 | @w{@code{void (*) (void *)}}. | |
202 | ||
203 | This is a GNU extension. | |
204 | ||
205 | @item gl_readdir | |
206 | The address of an alternative implementation of the @code{readdir} | |
207 | function used to read the contents of a directory. It is used if the | |
208 | @code{GLOB_ALTDIRFUNC} bit is set in the flag parameter. The type of | |
209 | this field is @w{@code{struct dirent *(*) (void *)}}. | |
210 | ||
211 | This is a GNU extension. | |
212 | ||
213 | @item gl_opendir | |
214 | The address of an alternative implementation of the @code{opendir} | |
215 | function. It is used if the @code{GLOB_ALTDIRFUNC} bit is set in | |
216 | the flag parameter. The type of this field is | |
217 | @w{@code{void *(*) (const char *)}}. | |
218 | ||
219 | This is a GNU extension. | |
220 | ||
221 | @item gl_stat | |
222 | The address of an alternative implementation of the @code{stat} function | |
223 | to get information about an object in the filesystem. It is used if the | |
224 | @code{GLOB_ALTDIRFUNC} bit is set in the flag parameter. The type of | |
225 | this field is @w{@code{int (*) (const char *, struct stat *)}}. | |
226 | ||
227 | This is a GNU extension. | |
228 | ||
229 | @item gl_lstat | |
230 | The address of an alternative implementation of the @code{lstat} | |
231 | function to get information about an object in the filesystems, not | |
232 | following symbolic links. It is used if the @code{GLOB_ALTDIRFUNC} bit | |
838e5ffe UD |
233 | is set in the flag parameter. The type of this field is @code{@w{int |
234 | (*) (const char *,} @w{struct stat *)}}. | |
714a562f UD |
235 | |
236 | This is a GNU extension. | |
28f540f4 RM |
237 | @end table |
238 | @end deftp | |
239 | ||
0fc95b82 UD |
240 | For use in the @code{glob64} function @file{glob.h} contains another |
241 | definition for a very similar type. @code{glob64_t} differs from | |
242 | @code{glob_t} only in the types of the members @code{gl_readdir}, | |
243 | @code{gl_stat}, and @code{gl_lstat}. | |
244 | ||
245 | @comment glob.h | |
246 | @comment GNU | |
247 | @deftp {Data Type} glob64_t | |
248 | This data type holds a pointer to a word vector. More precisely, it | |
249 | records both the address of the word vector and its size. The GNU | |
250 | implementation contains some more fields which are non-standard | |
251 | extensions. | |
252 | ||
253 | @table @code | |
254 | @item gl_pathc | |
255 | The number of elements in the vector, excluding the initial null entries | |
256 | if the GLOB_DOOFFS flag is used (see gl_offs below). | |
257 | ||
258 | @item gl_pathv | |
259 | The address of the vector. This field has type @w{@code{char **}}. | |
260 | ||
261 | @item gl_offs | |
262 | The offset of the first real element of the vector, from its nominal | |
263 | address in the @code{gl_pathv} field. Unlike the other fields, this | |
264 | is always an input to @code{glob}, rather than an output from it. | |
265 | ||
266 | If you use a nonzero offset, then that many elements at the beginning of | |
267 | the vector are left empty. (The @code{glob} function fills them with | |
268 | null pointers.) | |
269 | ||
270 | The @code{gl_offs} field is meaningful only if you use the | |
271 | @code{GLOB_DOOFFS} flag. Otherwise, the offset is always zero | |
272 | regardless of what is in this field, and the first real element comes at | |
273 | the beginning of the vector. | |
274 | ||
275 | @item gl_closedir | |
276 | The address of an alternative implementation of the @code{closedir} | |
277 | function. It is used if the @code{GLOB_ALTDIRFUNC} bit is set in | |
278 | the flag parameter. The type of this field is | |
279 | @w{@code{void (*) (void *)}}. | |
280 | ||
281 | This is a GNU extension. | |
282 | ||
283 | @item gl_readdir | |
284 | The address of an alternative implementation of the @code{readdir64} | |
285 | function used to read the contents of a directory. It is used if the | |
286 | @code{GLOB_ALTDIRFUNC} bit is set in the flag parameter. The type of | |
287 | this field is @w{@code{struct dirent64 *(*) (void *)}}. | |
288 | ||
289 | This is a GNU extension. | |
290 | ||
291 | @item gl_opendir | |
292 | The address of an alternative implementation of the @code{opendir} | |
293 | function. It is used if the @code{GLOB_ALTDIRFUNC} bit is set in | |
294 | the flag parameter. The type of this field is | |
295 | @w{@code{void *(*) (const char *)}}. | |
296 | ||
297 | This is a GNU extension. | |
298 | ||
299 | @item gl_stat | |
300 | The address of an alternative implementation of the @code{stat64} function | |
301 | to get information about an object in the filesystem. It is used if the | |
302 | @code{GLOB_ALTDIRFUNC} bit is set in the flag parameter. The type of | |
303 | this field is @w{@code{int (*) (const char *, struct stat64 *)}}. | |
304 | ||
305 | This is a GNU extension. | |
306 | ||
307 | @item gl_lstat | |
308 | The address of an alternative implementation of the @code{lstat64} | |
309 | function to get information about an object in the filesystems, not | |
310 | following symbolic links. It is used if the @code{GLOB_ALTDIRFUNC} bit | |
311 | is set in the flag parameter. The type of this field is @code{@w{int | |
312 | (*) (const char *,} @w{struct stat64 *)}}. | |
313 | ||
314 | This is a GNU extension. | |
315 | @end table | |
316 | @end deftp | |
317 | ||
28f540f4 RM |
318 | @comment glob.h |
319 | @comment POSIX.2 | |
320 | @deftypefun int glob (const char *@var{pattern}, int @var{flags}, int (*@var{errfunc}) (const char *@var{filename}, int @var{error-code}), glob_t *@var{vector-ptr}) | |
321 | The function @code{glob} does globbing using the pattern @var{pattern} | |
322 | in the current directory. It puts the result in a newly allocated | |
323 | vector, and stores the size and address of this vector into | |
324 | @code{*@var{vector-ptr}}. The argument @var{flags} is a combination of | |
325 | bit flags; see @ref{Flags for Globbing}, for details of the flags. | |
326 | ||
327 | The result of globbing is a sequence of file names. The function | |
328 | @code{glob} allocates a string for each resulting word, then | |
329 | allocates a vector of type @code{char **} to store the addresses of | |
330 | these strings. The last element of the vector is a null pointer. | |
331 | This vector is called the @dfn{word vector}. | |
332 | ||
333 | To return this vector, @code{glob} stores both its address and its | |
334 | length (number of elements, not counting the terminating null pointer) | |
335 | into @code{*@var{vector-ptr}}. | |
336 | ||
6d52618b | 337 | Normally, @code{glob} sorts the file names alphabetically before |
28f540f4 RM |
338 | returning them. You can turn this off with the flag @code{GLOB_NOSORT} |
339 | if you want to get the information as fast as possible. Usually it's | |
340 | a good idea to let @code{glob} sort them---if you process the files in | |
341 | alphabetical order, the users will have a feel for the rate of progress | |
342 | that your application is making. | |
343 | ||
344 | If @code{glob} succeeds, it returns 0. Otherwise, it returns one | |
345 | of these error codes: | |
346 | ||
0fc95b82 | 347 | @vtable @code |
28f540f4 RM |
348 | @comment glob.h |
349 | @comment POSIX.2 | |
350 | @item GLOB_ABORTED | |
351 | There was an error opening a directory, and you used the flag | |
352 | @code{GLOB_ERR} or your specified @var{errfunc} returned a nonzero | |
353 | value. | |
354 | @iftex | |
355 | See below | |
356 | @end iftex | |
357 | @ifinfo | |
358 | @xref{Flags for Globbing}, | |
359 | @end ifinfo | |
360 | for an explanation of the @code{GLOB_ERR} flag and @var{errfunc}. | |
361 | ||
362 | @comment glob.h | |
363 | @comment POSIX.2 | |
364 | @item GLOB_NOMATCH | |
365 | The pattern didn't match any existing files. If you use the | |
366 | @code{GLOB_NOCHECK} flag, then you never get this error code, because | |
367 | that flag tells @code{glob} to @emph{pretend} that the pattern matched | |
368 | at least one file. | |
369 | ||
370 | @comment glob.h | |
371 | @comment POSIX.2 | |
372 | @item GLOB_NOSPACE | |
373 | It was impossible to allocate memory to hold the result. | |
0fc95b82 | 374 | @end vtable |
28f540f4 RM |
375 | |
376 | In the event of an error, @code{glob} stores information in | |
377 | @code{*@var{vector-ptr}} about all the matches it has found so far. | |
0fc95b82 | 378 | |
0bc93a2f | 379 | It is important to notice that the @code{glob} function will not fail if |
0fc95b82 UD |
380 | it encounters directories or files which cannot be handled without the |
381 | LFS interfaces. The implementation of @code{glob} is supposed to use | |
382 | these functions internally. This at least is the assumptions made by | |
383 | the Unix standard. The GNU extension of allowing the user to provide | |
384 | own directory handling and @code{stat} functions complicates things a | |
385 | bit. If these callback functions are used and a large file or directory | |
386 | is encountered @code{glob} @emph{can} fail. | |
387 | @end deftypefun | |
388 | ||
389 | @comment glob.h | |
390 | @comment GNU | |
391 | @deftypefun int glob64 (const char *@var{pattern}, int @var{flags}, int (*@var{errfunc}) (const char *@var{filename}, int @var{error-code}), glob64_t *@var{vector-ptr}) | |
392 | The @code{glob64} function was added as part of the Large File Summit | |
393 | extensions but is not part of the original LFS proposal. The reason for | |
394 | this is simple: it is not necessary. The necessity for a @code{glob64} | |
395 | function is added by the extensions of the GNU @code{glob} | |
396 | implementation which allows the user to provide own directory handling | |
397 | and @code{stat} functions. The @code{readdir} and @code{stat} functions | |
398 | do depend on the choice of @code{_FILE_OFFSET_BITS} since the definition | |
399 | of the types @code{struct dirent} and @code{struct stat} will change | |
400 | depending on the choice. | |
401 | ||
402 | Beside this difference the @code{glob64} works just like @code{glob} in | |
403 | all aspects. | |
404 | ||
405 | This function is a GNU extension. | |
28f540f4 RM |
406 | @end deftypefun |
407 | ||
408 | @node Flags for Globbing | |
409 | @subsection Flags for Globbing | |
410 | ||
6d52618b | 411 | This section describes the flags that you can specify in the |
28f540f4 RM |
412 | @var{flags} argument to @code{glob}. Choose the flags you want, |
413 | and combine them with the C bitwise OR operator @code{|}. | |
414 | ||
0fc95b82 | 415 | @vtable @code |
28f540f4 RM |
416 | @comment glob.h |
417 | @comment POSIX.2 | |
418 | @item GLOB_APPEND | |
419 | Append the words from this expansion to the vector of words produced by | |
420 | previous calls to @code{glob}. This way you can effectively expand | |
421 | several words as if they were concatenated with spaces between them. | |
422 | ||
423 | In order for appending to work, you must not modify the contents of the | |
424 | word vector structure between calls to @code{glob}. And, if you set | |
425 | @code{GLOB_DOOFFS} in the first call to @code{glob}, you must also | |
426 | set it when you append to the results. | |
427 | ||
428 | Note that the pointer stored in @code{gl_pathv} may no longer be valid | |
429 | after you call @code{glob} the second time, because @code{glob} might | |
430 | have relocated the vector. So always fetch @code{gl_pathv} from the | |
431 | @code{glob_t} structure after each @code{glob} call; @strong{never} save | |
432 | the pointer across calls. | |
433 | ||
434 | @comment glob.h | |
435 | @comment POSIX.2 | |
436 | @item GLOB_DOOFFS | |
437 | Leave blank slots at the beginning of the vector of words. | |
438 | The @code{gl_offs} field says how many slots to leave. | |
439 | The blank slots contain null pointers. | |
440 | ||
441 | @comment glob.h | |
442 | @comment POSIX.2 | |
443 | @item GLOB_ERR | |
444 | Give up right away and report an error if there is any difficulty | |
445 | reading the directories that must be read in order to expand @var{pattern} | |
446 | fully. Such difficulties might include a directory in which you don't | |
447 | have the requisite access. Normally, @code{glob} tries its best to keep | |
448 | on going despite any errors, reading whatever directories it can. | |
449 | ||
450 | You can exercise even more control than this by specifying an | |
451 | error-handler function @var{errfunc} when you call @code{glob}. If | |
452 | @var{errfunc} is not a null pointer, then @code{glob} doesn't give up | |
453 | right away when it can't read a directory; instead, it calls | |
454 | @var{errfunc} with two arguments, like this: | |
455 | ||
456 | @smallexample | |
457 | (*@var{errfunc}) (@var{filename}, @var{error-code}) | |
458 | @end smallexample | |
459 | ||
460 | @noindent | |
461 | The argument @var{filename} is the name of the directory that | |
462 | @code{glob} couldn't open or couldn't read, and @var{error-code} is the | |
463 | @code{errno} value that was reported to @code{glob}. | |
464 | ||
465 | If the error handler function returns nonzero, then @code{glob} gives up | |
466 | right away. Otherwise, it continues. | |
467 | ||
468 | @comment glob.h | |
469 | @comment POSIX.2 | |
470 | @item GLOB_MARK | |
471 | If the pattern matches the name of a directory, append @samp{/} to the | |
472 | directory's name when returning it. | |
473 | ||
474 | @comment glob.h | |
475 | @comment POSIX.2 | |
476 | @item GLOB_NOCHECK | |
477 | If the pattern doesn't match any file names, return the pattern itself | |
478 | as if it were a file name that had been matched. (Normally, when the | |
479 | pattern doesn't match anything, @code{glob} returns that there were no | |
480 | matches.) | |
481 | ||
482 | @comment glob.h | |
483 | @comment POSIX.2 | |
484 | @item GLOB_NOSORT | |
485 | Don't sort the file names; return them in no particular order. | |
486 | (In practice, the order will depend on the order of the entries in | |
487 | the directory.) The only reason @emph{not} to sort is to save time. | |
488 | ||
489 | @comment glob.h | |
490 | @comment POSIX.2 | |
491 | @item GLOB_NOESCAPE | |
492 | Don't treat the @samp{\} character specially in patterns. Normally, | |
493 | @samp{\} quotes the following character, turning off its special meaning | |
494 | (if any) so that it matches only itself. When quoting is enabled, the | |
495 | pattern @samp{\?} matches only the string @samp{?}, because the question | |
496 | mark in the pattern acts like an ordinary character. | |
497 | ||
498 | If you use @code{GLOB_NOESCAPE}, then @samp{\} is an ordinary character. | |
499 | ||
500 | @code{glob} does its work by calling the function @code{fnmatch} | |
501 | repeatedly. It handles the flag @code{GLOB_NOESCAPE} by turning on the | |
502 | @code{FNM_NOESCAPE} flag in calls to @code{fnmatch}. | |
0fc95b82 | 503 | @end vtable |
28f540f4 | 504 | |
714a562f UD |
505 | @node More Flags for Globbing |
506 | @subsection More Flags for Globbing | |
507 | ||
f2ea0f5b | 508 | Beside the flags described in the last section, the GNU implementation of |
714a562f UD |
509 | @code{glob} allows a few more flags which are also defined in the |
510 | @file{glob.h} file. Some of the extensions implement functionality | |
511 | which is available in modern shell implementations. | |
512 | ||
0fc95b82 | 513 | @vtable @code |
714a562f UD |
514 | @comment glob.h |
515 | @comment GNU | |
516 | @item GLOB_PERIOD | |
517 | The @code{.} character (period) is treated special. It cannot be | |
518 | matched by wildcards. @xref{Wildcard Matching}, @code{FNM_PERIOD}. | |
519 | ||
520 | @comment glob.h | |
521 | @comment GNU | |
522 | @item GLOB_MAGCHAR | |
523 | The @code{GLOB_MAGCHAR} value is not to be given to @code{glob} in the | |
524 | @var{flags} parameter. Instead, @code{glob} sets this bit in the | |
525 | @var{gl_flags} element of the @var{glob_t} structure provided as the | |
526 | result if the pattern used for matching contains any wildcard character. | |
527 | ||
528 | @comment glob.h | |
529 | @comment GNU | |
530 | @item GLOB_ALTDIRFUNC | |
531 | Instead of the using the using the normal functions for accessing the | |
532 | filesystem the @code{glob} implementation uses the user-supplied | |
533 | functions specified in the structure pointed to by @var{pglob} | |
534 | parameter. For more information about the functions refer to the | |
8b7fb588 | 535 | sections about directory handling see @ref{Accessing Directories}, and |
714a562f UD |
536 | @ref{Reading Attributes}. |
537 | ||
538 | @comment glob.h | |
539 | @comment GNU | |
540 | @item GLOB_BRACE | |
541 | If this flag is given the handling of braces in the pattern is changed. | |
542 | It is now required that braces appear correctly grouped. I.e., for each | |
543 | opening brace there must be a closing one. Braces can be used | |
544 | recursively. So it is possible to define one brace expression in | |
545 | another one. It is important to note that the range of each brace | |
546 | expression is completely contained in the outer brace expression (if | |
547 | there is one). | |
548 | ||
f2ea0f5b | 549 | The string between the matching braces is separated into single |
714a562f | 550 | expressions by splitting at @code{,} (comma) characters. The commas |
0bc93a2f | 551 | themselves are discarded. Please note what we said above about recursive |
714a562f UD |
552 | brace expressions. The commas used to separate the subexpressions must |
553 | be at the same level. Commas in brace subexpressions are not matched. | |
554 | They are used during expansion of the brace expression of the deeper | |
555 | level. The example below shows this | |
556 | ||
557 | @smallexample | |
558 | glob ("@{foo/@{,bar,biz@},baz@}", GLOB_BRACE, NULL, &result) | |
559 | @end smallexample | |
560 | ||
561 | @noindent | |
562 | is equivalent to the sequence | |
563 | ||
564 | @smallexample | |
565 | glob ("foo/", GLOB_BRACE, NULL, &result) | |
566 | glob ("foo/bar", GLOB_BRACE|GLOB_APPEND, NULL, &result) | |
567 | glob ("foo/biz", GLOB_BRACE|GLOB_APPEND, NULL, &result) | |
568 | glob ("baz", GLOB_BRACE|GLOB_APPEND, NULL, &result) | |
569 | @end smallexample | |
570 | ||
571 | @noindent | |
572 | if we leave aside error handling. | |
573 | ||
574 | @comment glob.h | |
575 | @comment GNU | |
576 | @item GLOB_NOMAGIC | |
577 | If the pattern contains no wildcard constructs (it is a literal file name), | |
578 | return it as the sole ``matching'' word, even if no file exists by that name. | |
579 | ||
580 | @comment glob.h | |
581 | @comment GNU | |
582 | @item GLOB_TILDE | |
583 | If this flag is used the character @code{~} (tilde) is handled special | |
584 | if it appears at the beginning of the pattern. Instead of being taken | |
585 | verbatim it is used to represent the home directory of a known user. | |
586 | ||
587 | If @code{~} is the only character in pattern or it is followed by a | |
588 | @code{/} (slash), the home directory of the process owner is | |
589 | substituted. Using @code{getlogin} and @code{getpwnam} the information | |
590 | is read from the system databases. As an example take user @code{bart} | |
591 | with his home directory at @file{/home/bart}. For him a call like | |
592 | ||
593 | @smallexample | |
594 | glob ("~/bin/*", GLOB_TILDE, NULL, &result) | |
595 | @end smallexample | |
596 | ||
597 | @noindent | |
598 | would return the contents of the directory @file{/home/bart/bin}. | |
599 | Instead of referring to the own home directory it is also possible to | |
600 | name the home directory of other users. To do so one has to append the | |
601 | user name after the tilde character. So the contents of user | |
602 | @code{homer}'s @file{bin} directory can be retrieved by | |
603 | ||
604 | @smallexample | |
605 | glob ("~homer/bin/*", GLOB_TILDE, NULL, &result) | |
606 | @end smallexample | |
607 | ||
1bc21e7a UD |
608 | If the user name is not valid or the home directory cannot be determined |
609 | for some reason the pattern is left untouched and itself used as the | |
610 | result. I.e., if in the last example @code{home} is not available the | |
611 | tilde expansion yields to @code{"~homer/bin/*"} and @code{glob} is not | |
612 | looking for a directory named @code{~homer}. | |
613 | ||
614 | This functionality is equivalent to what is available in C-shells if the | |
615 | @code{nonomatch} flag is set. | |
616 | ||
617 | @comment glob.h | |
618 | @comment GNU | |
619 | @item GLOB_TILDE_CHECK | |
620 | If this flag is used @code{glob} behaves like as if @code{GLOB_TILDE} is | |
621 | given. The only difference is that if the user name is not available or | |
622 | the home directory cannot be determined for other reasons this leads to | |
623 | an error. @code{glob} will return @code{GLOB_NOMATCH} instead of using | |
624 | the pattern itself as the name. | |
625 | ||
ec986e23 | 626 | This functionality is equivalent to what is available in C-shells if |
1bc21e7a | 627 | @code{nonomatch} flag is not set. |
1cab5444 UD |
628 | |
629 | @comment glob.h | |
630 | @comment GNU | |
631 | @item GLOB_ONLYDIR | |
632 | If this flag is used the globbing function takes this as a | |
633 | @strong{hint} that the caller is only interested in directories | |
634 | matching the pattern. If the information about the type of the file | |
635 | is easily available non-directories will be rejected but no extra | |
636 | work will be done to determine the information for each file. I.e., | |
637 | the caller must still be able to filter directories out. | |
638 | ||
cc3fa755 | 639 | This functionality is only available with the GNU @code{glob} |
1cab5444 UD |
640 | implementation. It is mainly used internally to increase the |
641 | performance but might be useful for a user as well and therefore is | |
642 | documented here. | |
0fc95b82 | 643 | @end vtable |
714a562f | 644 | |
af6f3906 UD |
645 | Calling @code{glob} will in most cases allocate resources which are used |
646 | to represent the result of the function call. If the same object of | |
647 | type @code{glob_t} is used in multiple call to @code{glob} the resources | |
648 | are freed or reused so that no leaks appear. But this does not include | |
649 | the time when all @code{glob} calls are done. | |
650 | ||
651 | @comment glob.h | |
652 | @comment POSIX.2 | |
653 | @deftypefun void globfree (glob_t *@var{pglob}) | |
654 | The @code{globfree} function frees all resources allocated by previous | |
655 | calls to @code{glob} associated with the object pointed to by | |
656 | @var{pglob}. This function should be called whenever the currently used | |
657 | @code{glob_t} typed object isn't used anymore. | |
658 | @end deftypefun | |
659 | ||
0fc95b82 UD |
660 | @comment glob.h |
661 | @comment GNU | |
662 | @deftypefun void globfree64 (glob64_t *@var{pglob}) | |
663 | This function is equivalent to @code{globfree} but it frees records of | |
664 | type @code{glob64_t} which were allocated by @code{glob64}. | |
665 | @end deftypefun | |
666 | ||
714a562f | 667 | |
28f540f4 RM |
668 | @node Regular Expressions |
669 | @section Regular Expression Matching | |
670 | ||
671 | The GNU C library supports two interfaces for matching regular | |
672 | expressions. One is the standard POSIX.2 interface, and the other is | |
673 | what the GNU system has had for many years. | |
674 | ||
675 | Both interfaces are declared in the header file @file{regex.h}. | |
676 | If you define @w{@code{_POSIX_C_SOURCE}}, then only the POSIX.2 | |
677 | functions, structures, and constants are declared. | |
678 | @c !!! we only document the POSIX.2 interface here!! | |
679 | ||
680 | @menu | |
681 | * POSIX Regexp Compilation:: Using @code{regcomp} to prepare to match. | |
682 | * Flags for POSIX Regexps:: Syntax variations for @code{regcomp}. | |
683 | * Matching POSIX Regexps:: Using @code{regexec} to match the compiled | |
684 | pattern that you get from @code{regcomp}. | |
685 | * Regexp Subexpressions:: Finding which parts of the string were matched. | |
686 | * Subexpression Complications:: Find points of which parts were matched. | |
687 | * Regexp Cleanup:: Freeing storage; reporting errors. | |
688 | @end menu | |
689 | ||
690 | @node POSIX Regexp Compilation | |
691 | @subsection POSIX Regular Expression Compilation | |
692 | ||
693 | Before you can actually match a regular expression, you must | |
694 | @dfn{compile} it. This is not true compilation---it produces a special | |
695 | data structure, not machine instructions. But it is like ordinary | |
696 | compilation in that its purpose is to enable you to ``execute'' the | |
697 | pattern fast. (@xref{Matching POSIX Regexps}, for how to use the | |
698 | compiled regular expression for matching.) | |
699 | ||
700 | There is a special data type for compiled regular expressions: | |
701 | ||
702 | @comment regex.h | |
703 | @comment POSIX.2 | |
704 | @deftp {Data Type} regex_t | |
705 | This type of object holds a compiled regular expression. | |
706 | It is actually a structure. It has just one field that your programs | |
707 | should look at: | |
708 | ||
709 | @table @code | |
710 | @item re_nsub | |
711 | This field holds the number of parenthetical subexpressions in the | |
712 | regular expression that was compiled. | |
713 | @end table | |
714 | ||
715 | There are several other fields, but we don't describe them here, because | |
716 | only the functions in the library should use them. | |
717 | @end deftp | |
718 | ||
719 | After you create a @code{regex_t} object, you can compile a regular | |
720 | expression into it by calling @code{regcomp}. | |
721 | ||
722 | @comment regex.h | |
723 | @comment POSIX.2 | |
a334319f | 724 | @deftypefun int regcomp (regex_t *@var{compiled}, const char *@var{pattern}, int @var{cflags}) |
28f540f4 RM |
725 | The function @code{regcomp} ``compiles'' a regular expression into a |
726 | data structure that you can use with @code{regexec} to match against a | |
727 | string. The compiled regular expression format is designed for | |
728 | efficient matching. @code{regcomp} stores it into @code{*@var{compiled}}. | |
729 | ||
730 | It's up to you to allocate an object of type @code{regex_t} and pass its | |
731 | address to @code{regcomp}. | |
732 | ||
733 | The argument @var{cflags} lets you specify various options that control | |
734 | the syntax and semantics of regular expressions. @xref{Flags for POSIX | |
735 | Regexps}. | |
736 | ||
737 | If you use the flag @code{REG_NOSUB}, then @code{regcomp} omits from | |
738 | the compiled regular expression the information necessary to record | |
739 | how subexpressions actually match. In this case, you might as well | |
740 | pass @code{0} for the @var{matchptr} and @var{nmatch} arguments when | |
741 | you call @code{regexec}. | |
742 | ||
743 | If you don't use @code{REG_NOSUB}, then the compiled regular expression | |
744 | does have the capacity to record how subexpressions match. Also, | |
745 | @code{regcomp} tells you how many subexpressions @var{pattern} has, by | |
746 | storing the number in @code{@var{compiled}->re_nsub}. You can use that | |
747 | value to decide how long an array to allocate to hold information about | |
748 | subexpression matches. | |
749 | ||
750 | @code{regcomp} returns @code{0} if it succeeds in compiling the regular | |
751 | expression; otherwise, it returns a nonzero error code (see the table | |
752 | below). You can use @code{regerror} to produce an error message string | |
753 | describing the reason for a nonzero value; see @ref{Regexp Cleanup}. | |
754 | ||
755 | @end deftypefun | |
756 | ||
757 | Here are the possible nonzero values that @code{regcomp} can return: | |
758 | ||
759 | @table @code | |
760 | @comment regex.h | |
761 | @comment POSIX.2 | |
762 | @item REG_BADBR | |
763 | There was an invalid @samp{\@{@dots{}\@}} construct in the regular | |
764 | expression. A valid @samp{\@{@dots{}\@}} construct must contain either | |
765 | a single number, or two numbers in increasing order separated by a | |
766 | comma. | |
767 | ||
768 | @comment regex.h | |
769 | @comment POSIX.2 | |
770 | @item REG_BADPAT | |
771 | There was a syntax error in the regular expression. | |
772 | ||
773 | @comment regex.h | |
774 | @comment POSIX.2 | |
775 | @item REG_BADRPT | |
776 | A repetition operator such as @samp{?} or @samp{*} appeared in a bad | |
777 | position (with no preceding subexpression to act on). | |
778 | ||
779 | @comment regex.h | |
780 | @comment POSIX.2 | |
781 | @item REG_ECOLLATE | |
782 | The regular expression referred to an invalid collating element (one not | |
783 | defined in the current locale for string collation). @xref{Locale | |
784 | Categories}. | |
785 | ||
786 | @comment regex.h | |
787 | @comment POSIX.2 | |
788 | @item REG_ECTYPE | |
789 | The regular expression referred to an invalid character class name. | |
790 | ||
791 | @comment regex.h | |
792 | @comment POSIX.2 | |
793 | @item REG_EESCAPE | |
794 | The regular expression ended with @samp{\}. | |
795 | ||
796 | @comment regex.h | |
797 | @comment POSIX.2 | |
798 | @item REG_ESUBREG | |
799 | There was an invalid number in the @samp{\@var{digit}} construct. | |
800 | ||
801 | @comment regex.h | |
802 | @comment POSIX.2 | |
803 | @item REG_EBRACK | |
804 | There were unbalanced square brackets in the regular expression. | |
805 | ||
806 | @comment regex.h | |
807 | @comment POSIX.2 | |
808 | @item REG_EPAREN | |
809 | An extended regular expression had unbalanced parentheses, | |
810 | or a basic regular expression had unbalanced @samp{\(} and @samp{\)}. | |
811 | ||
812 | @comment regex.h | |
813 | @comment POSIX.2 | |
814 | @item REG_EBRACE | |
815 | The regular expression had unbalanced @samp{\@{} and @samp{\@}}. | |
816 | ||
817 | @comment regex.h | |
818 | @comment POSIX.2 | |
819 | @item REG_ERANGE | |
820 | One of the endpoints in a range expression was invalid. | |
821 | ||
822 | @comment regex.h | |
823 | @comment POSIX.2 | |
824 | @item REG_ESPACE | |
825 | @code{regcomp} ran out of memory. | |
826 | @end table | |
827 | ||
828 | @node Flags for POSIX Regexps | |
829 | @subsection Flags for POSIX Regular Expressions | |
830 | ||
831 | These are the bit flags that you can use in the @var{cflags} operand when | |
832 | compiling a regular expression with @code{regcomp}. | |
6d52618b | 833 | |
28f540f4 RM |
834 | @table @code |
835 | @comment regex.h | |
836 | @comment POSIX.2 | |
837 | @item REG_EXTENDED | |
838 | Treat the pattern as an extended regular expression, rather than as a | |
839 | basic regular expression. | |
840 | ||
841 | @comment regex.h | |
842 | @comment POSIX.2 | |
843 | @item REG_ICASE | |
844 | Ignore case when matching letters. | |
845 | ||
846 | @comment regex.h | |
847 | @comment POSIX.2 | |
848 | @item REG_NOSUB | |
849 | Don't bother storing the contents of the @var{matches-ptr} array. | |
850 | ||
851 | @comment regex.h | |
852 | @comment POSIX.2 | |
853 | @item REG_NEWLINE | |
854 | Treat a newline in @var{string} as dividing @var{string} into multiple | |
855 | lines, so that @samp{$} can match before the newline and @samp{^} can | |
856 | match after. Also, don't permit @samp{.} to match a newline, and don't | |
857 | permit @samp{[^@dots{}]} to match a newline. | |
858 | ||
859 | Otherwise, newline acts like any other ordinary character. | |
860 | @end table | |
861 | ||
862 | @node Matching POSIX Regexps | |
863 | @subsection Matching a Compiled POSIX Regular Expression | |
864 | ||
865 | Once you have compiled a regular expression, as described in @ref{POSIX | |
866 | Regexp Compilation}, you can match it against strings using | |
867 | @code{regexec}. A match anywhere inside the string counts as success, | |
868 | unless the regular expression contains anchor characters (@samp{^} or | |
869 | @samp{$}). | |
870 | ||
871 | @comment regex.h | |
872 | @comment POSIX.2 | |
a334319f | 873 | @deftypefun int regexec (regex_t *@var{compiled}, char *@var{string}, size_t @var{nmatch}, regmatch_t @var{matchptr} @t{[]}, int @var{eflags}) |
28f540f4 RM |
874 | This function tries to match the compiled regular expression |
875 | @code{*@var{compiled}} against @var{string}. | |
876 | ||
877 | @code{regexec} returns @code{0} if the regular expression matches; | |
878 | otherwise, it returns a nonzero value. See the table below for | |
879 | what nonzero values mean. You can use @code{regerror} to produce an | |
6d52618b | 880 | error message string describing the reason for a nonzero value; |
28f540f4 RM |
881 | see @ref{Regexp Cleanup}. |
882 | ||
883 | The argument @var{eflags} is a word of bit flags that enable various | |
884 | options. | |
885 | ||
886 | If you want to get information about what part of @var{string} actually | |
887 | matched the regular expression or its subexpressions, use the arguments | |
6d52618b | 888 | @var{matchptr} and @var{nmatch}. Otherwise, pass @code{0} for |
28f540f4 RM |
889 | @var{nmatch}, and @code{NULL} for @var{matchptr}. @xref{Regexp |
890 | Subexpressions}. | |
891 | @end deftypefun | |
892 | ||
893 | You must match the regular expression with the same set of current | |
894 | locales that were in effect when you compiled the regular expression. | |
895 | ||
896 | The function @code{regexec} accepts the following flags in the | |
897 | @var{eflags} argument: | |
898 | ||
6d52618b | 899 | @table @code |
28f540f4 RM |
900 | @comment regex.h |
901 | @comment POSIX.2 | |
902 | @item REG_NOTBOL | |
903 | Do not regard the beginning of the specified string as the beginning of | |
904 | a line; more generally, don't make any assumptions about what text might | |
905 | precede it. | |
906 | ||
907 | @comment regex.h | |
908 | @comment POSIX.2 | |
909 | @item REG_NOTEOL | |
910 | Do not regard the end of the specified string as the end of a line; more | |
911 | generally, don't make any assumptions about what text might follow it. | |
912 | @end table | |
913 | ||
914 | Here are the possible nonzero values that @code{regexec} can return: | |
915 | ||
916 | @table @code | |
917 | @comment regex.h | |
918 | @comment POSIX.2 | |
919 | @item REG_NOMATCH | |
920 | The pattern didn't match the string. This isn't really an error. | |
921 | ||
922 | @comment regex.h | |
923 | @comment POSIX.2 | |
924 | @item REG_ESPACE | |
925 | @code{regexec} ran out of memory. | |
926 | @end table | |
927 | ||
928 | @node Regexp Subexpressions | |
929 | @subsection Match Results with Subexpressions | |
930 | ||
931 | When @code{regexec} matches parenthetical subexpressions of | |
932 | @var{pattern}, it records which parts of @var{string} they match. It | |
933 | returns that information by storing the offsets into an array whose | |
934 | elements are structures of type @code{regmatch_t}. The first element of | |
935 | the array (index @code{0}) records the part of the string that matched | |
936 | the entire regular expression. Each other element of the array records | |
937 | the beginning and end of the part that matched a single parenthetical | |
938 | subexpression. | |
939 | ||
940 | @comment regex.h | |
941 | @comment POSIX.2 | |
942 | @deftp {Data Type} regmatch_t | |
943 | This is the data type of the @var{matcharray} array that you pass to | |
6d52618b | 944 | @code{regexec}. It contains two structure fields, as follows: |
28f540f4 RM |
945 | |
946 | @table @code | |
947 | @item rm_so | |
948 | The offset in @var{string} of the beginning of a substring. Add this | |
949 | value to @var{string} to get the address of that part. | |
950 | ||
951 | @item rm_eo | |
952 | The offset in @var{string} of the end of the substring. | |
953 | @end table | |
954 | @end deftp | |
955 | ||
956 | @comment regex.h | |
957 | @comment POSIX.2 | |
958 | @deftp {Data Type} regoff_t | |
959 | @code{regoff_t} is an alias for another signed integer type. | |
960 | The fields of @code{regmatch_t} have type @code{regoff_t}. | |
961 | @end deftp | |
962 | ||
963 | The @code{regmatch_t} elements correspond to subexpressions | |
964 | positionally; the first element (index @code{1}) records where the first | |
965 | subexpression matched, the second element records the second | |
966 | subexpression, and so on. The order of the subexpressions is the order | |
967 | in which they begin. | |
968 | ||
969 | When you call @code{regexec}, you specify how long the @var{matchptr} | |
970 | array is, with the @var{nmatch} argument. This tells @code{regexec} how | |
971 | many elements to store. If the actual regular expression has more than | |
972 | @var{nmatch} subexpressions, then you won't get offset information about | |
973 | the rest of them. But this doesn't alter whether the pattern matches a | |
974 | particular string or not. | |
975 | ||
976 | If you don't want @code{regexec} to return any information about where | |
977 | the subexpressions matched, you can either supply @code{0} for | |
978 | @var{nmatch}, or use the flag @code{REG_NOSUB} when you compile the | |
979 | pattern with @code{regcomp}. | |
980 | ||
981 | @node Subexpression Complications | |
982 | @subsection Complications in Subexpression Matching | |
983 | ||
984 | Sometimes a subexpression matches a substring of no characters. This | |
985 | happens when @samp{f\(o*\)} matches the string @samp{fum}. (It really | |
986 | matches just the @samp{f}.) In this case, both of the offsets identify | |
987 | the point in the string where the null substring was found. In this | |
988 | example, the offsets are both @code{1}. | |
989 | ||
990 | Sometimes the entire regular expression can match without using some of | |
991 | its subexpressions at all---for example, when @samp{ba\(na\)*} matches the | |
992 | string @samp{ba}, the parenthetical subexpression is not used. When | |
993 | this happens, @code{regexec} stores @code{-1} in both fields of the | |
994 | element for that subexpression. | |
995 | ||
996 | Sometimes matching the entire regular expression can match a particular | |
997 | subexpression more than once---for example, when @samp{ba\(na\)*} | |
998 | matches the string @samp{bananana}, the parenthetical subexpression | |
999 | matches three times. When this happens, @code{regexec} usually stores | |
1000 | the offsets of the last part of the string that matched the | |
1001 | subexpression. In the case of @samp{bananana}, these offsets are | |
1002 | @code{6} and @code{8}. | |
1003 | ||
1004 | But the last match is not always the one that is chosen. It's more | |
1005 | accurate to say that the last @emph{opportunity} to match is the one | |
1006 | that takes precedence. What this means is that when one subexpression | |
1007 | appears within another, then the results reported for the inner | |
1008 | subexpression reflect whatever happened on the last match of the outer | |
1009 | subexpression. For an example, consider @samp{\(ba\(na\)*s \)*} matching | |
1010 | the string @samp{bananas bas }. The last time the inner expression | |
6d52618b | 1011 | actually matches is near the end of the first word. But it is |
28f540f4 RM |
1012 | @emph{considered} again in the second word, and fails to match there. |
1013 | @code{regexec} reports nonuse of the ``na'' subexpression. | |
1014 | ||
1015 | Another place where this rule applies is when the regular expression | |
838e5ffe UD |
1016 | @smallexample |
1017 | \(ba\(na\)*s \|nefer\(ti\)* \)* | |
1018 | @end smallexample | |
1019 | @noindent | |
1020 | matches @samp{bananas nefertiti}. The ``na'' subexpression does match | |
1021 | in the first word, but it doesn't match in the second word because the | |
1022 | other alternative is used there. Once again, the second repetition of | |
1023 | the outer subexpression overrides the first, and within that second | |
1024 | repetition, the ``na'' subexpression is not used. So @code{regexec} | |
1025 | reports nonuse of the ``na'' subexpression. | |
28f540f4 RM |
1026 | |
1027 | @node Regexp Cleanup | |
1028 | @subsection POSIX Regexp Matching Cleanup | |
1029 | ||
1030 | When you are finished using a compiled regular expression, you can | |
1031 | free the storage it uses by calling @code{regfree}. | |
1032 | ||
1033 | @comment regex.h | |
1034 | @comment POSIX.2 | |
1035 | @deftypefun void regfree (regex_t *@var{compiled}) | |
1036 | Calling @code{regfree} frees all the storage that @code{*@var{compiled}} | |
1037 | points to. This includes various internal fields of the @code{regex_t} | |
1038 | structure that aren't documented in this manual. | |
1039 | ||
1040 | @code{regfree} does not free the object @code{*@var{compiled}} itself. | |
1041 | @end deftypefun | |
1042 | ||
1043 | You should always free the space in a @code{regex_t} structure with | |
1044 | @code{regfree} before using the structure to compile another regular | |
1045 | expression. | |
1046 | ||
1047 | When @code{regcomp} or @code{regexec} reports an error, you can use | |
1048 | the function @code{regerror} to turn it into an error message string. | |
1049 | ||
1050 | @comment regex.h | |
1051 | @comment POSIX.2 | |
a334319f | 1052 | @deftypefun size_t regerror (int @var{errcode}, regex_t *@var{compiled}, char *@var{buffer}, size_t @var{length}) |
28f540f4 RM |
1053 | This function produces an error message string for the error code |
1054 | @var{errcode}, and stores the string in @var{length} bytes of memory | |
1055 | starting at @var{buffer}. For the @var{compiled} argument, supply the | |
1056 | same compiled regular expression structure that @code{regcomp} or | |
1057 | @code{regexec} was working with when it got the error. Alternatively, | |
1058 | you can supply @code{NULL} for @var{compiled}; you will still get a | |
1059 | meaningful error message, but it might not be as detailed. | |
1060 | ||
1061 | If the error message can't fit in @var{length} bytes (including a | |
1062 | terminating null character), then @code{regerror} truncates it. | |
1063 | The string that @code{regerror} stores is always null-terminated | |
1064 | even if it has been truncated. | |
1065 | ||
1066 | The return value of @code{regerror} is the minimum length needed to | |
1067 | store the entire error message. If this is less than @var{length}, then | |
1068 | the error message was not truncated, and you can use it. Otherwise, you | |
1069 | should call @code{regerror} again with a larger buffer. | |
1070 | ||
1071 | Here is a function which uses @code{regerror}, but always dynamically | |
1072 | allocates a buffer for the error message: | |
1073 | ||
1074 | @smallexample | |
1075 | char *get_regerror (int errcode, regex_t *compiled) | |
1076 | @{ | |
1077 | size_t length = regerror (errcode, compiled, NULL, 0); | |
1078 | char *buffer = xmalloc (length); | |
1079 | (void) regerror (errcode, compiled, buffer, length); | |
1080 | return buffer; | |
1081 | @} | |
1082 | @end smallexample | |
1083 | @end deftypefun | |
1084 | ||
28f540f4 RM |
1085 | @node Word Expansion |
1086 | @section Shell-Style Word Expansion | |
1087 | @cindex word expansion | |
1088 | @cindex expansion of shell words | |
1089 | ||
6d52618b | 1090 | @dfn{Word expansion} means the process of splitting a string into |
28f540f4 RM |
1091 | @dfn{words} and substituting for variables, commands, and wildcards |
1092 | just as the shell does. | |
1093 | ||
1094 | For example, when you write @samp{ls -l foo.c}, this string is split | |
1095 | into three separate words---@samp{ls}, @samp{-l} and @samp{foo.c}. | |
1096 | This is the most basic function of word expansion. | |
1097 | ||
1098 | When you write @samp{ls *.c}, this can become many words, because | |
1099 | the word @samp{*.c} can be replaced with any number of file names. | |
1100 | This is called @dfn{wildcard expansion}, and it is also a part of | |
1101 | word expansion. | |
1102 | ||
1103 | When you use @samp{echo $PATH} to print your path, you are taking | |
1104 | advantage of @dfn{variable substitution}, which is also part of word | |
1105 | expansion. | |
1106 | ||
1107 | Ordinary programs can perform word expansion just like the shell by | |
1108 | calling the library function @code{wordexp}. | |
1109 | ||
1110 | @menu | |
14eb5d5d UD |
1111 | * Expansion Stages:: What word expansion does to a string. |
1112 | * Calling Wordexp:: How to call @code{wordexp}. | |
1113 | * Flags for Wordexp:: Options you can enable in @code{wordexp}. | |
1114 | * Wordexp Example:: A sample program that does word expansion. | |
1115 | * Tilde Expansion:: Details of how tilde expansion works. | |
1116 | * Variable Substitution:: Different types of variable substitution. | |
28f540f4 RM |
1117 | @end menu |
1118 | ||
1119 | @node Expansion Stages | |
1120 | @subsection The Stages of Word Expansion | |
1121 | ||
1122 | When word expansion is applied to a sequence of words, it performs the | |
1123 | following transformations in the order shown here: | |
1124 | ||
1125 | @enumerate | |
1126 | @item | |
1127 | @cindex tilde expansion | |
1128 | @dfn{Tilde expansion}: Replacement of @samp{~foo} with the name of | |
1129 | the home directory of @samp{foo}. | |
1130 | ||
1131 | @item | |
1132 | Next, three different transformations are applied in the same step, | |
1133 | from left to right: | |
1134 | ||
1135 | @itemize @bullet | |
1136 | @item | |
1137 | @cindex variable substitution | |
1138 | @cindex substitution of variables and commands | |
1139 | @dfn{Variable substitution}: Environment variables are substituted for | |
1140 | references such as @samp{$foo}. | |
1141 | ||
1142 | @item | |
1143 | @cindex command substitution | |
1144 | @dfn{Command substitution}: Constructs such as @w{@samp{`cat foo`}} and | |
1145 | the equivalent @w{@samp{$(cat foo)}} are replaced with the output from | |
1146 | the inner command. | |
1147 | ||
1148 | @item | |
1149 | @cindex arithmetic expansion | |
1150 | @dfn{Arithmetic expansion}: Constructs such as @samp{$(($x-1))} are | |
1151 | replaced with the result of the arithmetic computation. | |
1152 | @end itemize | |
1153 | ||
1154 | @item | |
1155 | @cindex field splitting | |
1156 | @dfn{Field splitting}: subdivision of the text into @dfn{words}. | |
1157 | ||
1158 | @item | |
1159 | @cindex wildcard expansion | |
1160 | @dfn{Wildcard expansion}: The replacement of a construct such as @samp{*.c} | |
1161 | with a list of @samp{.c} file names. Wildcard expansion applies to an | |
1162 | entire word at a time, and replaces that word with 0 or more file names | |
1163 | that are themselves words. | |
1164 | ||
1165 | @item | |
1166 | @cindex quote removal | |
1167 | @cindex removal of quotes | |
1168 | @dfn{Quote removal}: The deletion of string-quotes, now that they have | |
1169 | done their job by inhibiting the above transformations when appropriate. | |
1170 | @end enumerate | |
1171 | ||
1172 | For the details of these transformations, and how to write the constructs | |
1173 | that use them, see @w{@cite{The BASH Manual}} (to appear). | |
1174 | ||
1175 | @node Calling Wordexp | |
1176 | @subsection Calling @code{wordexp} | |
1177 | ||
1178 | All the functions, constants and data types for word expansion are | |
1179 | declared in the header file @file{wordexp.h}. | |
1180 | ||
1181 | Word expansion produces a vector of words (strings). To return this | |
1182 | vector, @code{wordexp} uses a special data type, @code{wordexp_t}, which | |
1183 | is a structure. You pass @code{wordexp} the address of the structure, | |
1184 | and it fills in the structure's fields to tell you about the results. | |
1185 | ||
1186 | @comment wordexp.h | |
1187 | @comment POSIX.2 | |
1188 | @deftp {Data Type} {wordexp_t} | |
1189 | This data type holds a pointer to a word vector. More precisely, it | |
1190 | records both the address of the word vector and its size. | |
1191 | ||
1192 | @table @code | |
1193 | @item we_wordc | |
1194 | The number of elements in the vector. | |
1195 | ||
1196 | @item we_wordv | |
1197 | The address of the vector. This field has type @w{@code{char **}}. | |
1198 | ||
1199 | @item we_offs | |
1200 | The offset of the first real element of the vector, from its nominal | |
1201 | address in the @code{we_wordv} field. Unlike the other fields, this | |
1202 | is always an input to @code{wordexp}, rather than an output from it. | |
1203 | ||
1204 | If you use a nonzero offset, then that many elements at the beginning of | |
1205 | the vector are left empty. (The @code{wordexp} function fills them with | |
1206 | null pointers.) | |
1207 | ||
1208 | The @code{we_offs} field is meaningful only if you use the | |
1209 | @code{WRDE_DOOFFS} flag. Otherwise, the offset is always zero | |
1210 | regardless of what is in this field, and the first real element comes at | |
1211 | the beginning of the vector. | |
1212 | @end table | |
1213 | @end deftp | |
1214 | ||
1215 | @comment wordexp.h | |
1216 | @comment POSIX.2 | |
1217 | @deftypefun int wordexp (const char *@var{words}, wordexp_t *@var{word-vector-ptr}, int @var{flags}) | |
1218 | Perform word expansion on the string @var{words}, putting the result in | |
1219 | a newly allocated vector, and store the size and address of this vector | |
1220 | into @code{*@var{word-vector-ptr}}. The argument @var{flags} is a | |
1221 | combination of bit flags; see @ref{Flags for Wordexp}, for details of | |
1222 | the flags. | |
1223 | ||
1224 | You shouldn't use any of the characters @samp{|&;<>} in the string | |
1225 | @var{words} unless they are quoted; likewise for newline. If you use | |
1226 | these characters unquoted, you will get the @code{WRDE_BADCHAR} error | |
1227 | code. Don't use parentheses or braces unless they are quoted or part of | |
1228 | a word expansion construct. If you use quotation characters @samp{'"`}, | |
1229 | they should come in pairs that balance. | |
1230 | ||
1231 | The results of word expansion are a sequence of words. The function | |
1232 | @code{wordexp} allocates a string for each resulting word, then | |
1233 | allocates a vector of type @code{char **} to store the addresses of | |
1234 | these strings. The last element of the vector is a null pointer. | |
1235 | This vector is called the @dfn{word vector}. | |
1236 | ||
1237 | To return this vector, @code{wordexp} stores both its address and its | |
1238 | length (number of elements, not counting the terminating null pointer) | |
1239 | into @code{*@var{word-vector-ptr}}. | |
1240 | ||
1241 | If @code{wordexp} succeeds, it returns 0. Otherwise, it returns one | |
1242 | of these error codes: | |
1243 | ||
1244 | @table @code | |
1245 | @comment wordexp.h | |
1246 | @comment POSIX.2 | |
1247 | @item WRDE_BADCHAR | |
1248 | The input string @var{words} contains an unquoted invalid character such | |
1249 | as @samp{|}. | |
1250 | ||
1251 | @comment wordexp.h | |
1252 | @comment POSIX.2 | |
1253 | @item WRDE_BADVAL | |
1254 | The input string refers to an undefined shell variable, and you used the flag | |
1255 | @code{WRDE_UNDEF} to forbid such references. | |
1256 | ||
1257 | @comment wordexp.h | |
1258 | @comment POSIX.2 | |
1259 | @item WRDE_CMDSUB | |
1260 | The input string uses command substitution, and you used the flag | |
1261 | @code{WRDE_NOCMD} to forbid command substitution. | |
1262 | ||
1263 | @comment wordexp.h | |
1264 | @comment POSIX.2 | |
1265 | @item WRDE_NOSPACE | |
1266 | It was impossible to allocate memory to hold the result. In this case, | |
1267 | @code{wordexp} can store part of the results---as much as it could | |
1268 | allocate room for. | |
1269 | ||
1270 | @comment wordexp.h | |
1271 | @comment POSIX.2 | |
1272 | @item WRDE_SYNTAX | |
1273 | There was a syntax error in the input string. For example, an unmatched | |
1274 | quoting character is a syntax error. | |
1275 | @end table | |
1276 | @end deftypefun | |
1277 | ||
1278 | @comment wordexp.h | |
1279 | @comment POSIX.2 | |
1280 | @deftypefun void wordfree (wordexp_t *@var{word-vector-ptr}) | |
1281 | Free the storage used for the word-strings and vector that | |
1282 | @code{*@var{word-vector-ptr}} points to. This does not free the | |
1283 | structure @code{*@var{word-vector-ptr}} itself---only the other | |
1284 | data it points to. | |
1285 | @end deftypefun | |
1286 | ||
1287 | @node Flags for Wordexp | |
1288 | @subsection Flags for Word Expansion | |
1289 | ||
6d52618b | 1290 | This section describes the flags that you can specify in the |
28f540f4 RM |
1291 | @var{flags} argument to @code{wordexp}. Choose the flags you want, |
1292 | and combine them with the C operator @code{|}. | |
1293 | ||
1294 | @table @code | |
1295 | @comment wordexp.h | |
1296 | @comment POSIX.2 | |
1297 | @item WRDE_APPEND | |
1298 | Append the words from this expansion to the vector of words produced by | |
1299 | previous calls to @code{wordexp}. This way you can effectively expand | |
1300 | several words as if they were concatenated with spaces between them. | |
1301 | ||
1302 | In order for appending to work, you must not modify the contents of the | |
1303 | word vector structure between calls to @code{wordexp}. And, if you set | |
1304 | @code{WRDE_DOOFFS} in the first call to @code{wordexp}, you must also | |
1305 | set it when you append to the results. | |
1306 | ||
1307 | @comment wordexp.h | |
1308 | @comment POSIX.2 | |
1309 | @item WRDE_DOOFFS | |
1310 | Leave blank slots at the beginning of the vector of words. | |
1311 | The @code{we_offs} field says how many slots to leave. | |
1312 | The blank slots contain null pointers. | |
1313 | ||
1314 | @comment wordexp.h | |
1315 | @comment POSIX.2 | |
1316 | @item WRDE_NOCMD | |
1317 | Don't do command substitution; if the input requests command substitution, | |
1318 | report an error. | |
1319 | ||
1320 | @comment wordexp.h | |
1321 | @comment POSIX.2 | |
1322 | @item WRDE_REUSE | |
1323 | Reuse a word vector made by a previous call to @code{wordexp}. | |
1324 | Instead of allocating a new vector of words, this call to @code{wordexp} | |
1325 | will use the vector that already exists (making it larger if necessary). | |
1326 | ||
1327 | Note that the vector may move, so it is not safe to save an old pointer | |
1328 | and use it again after calling @code{wordexp}. You must fetch | |
1329 | @code{we_pathv} anew after each call. | |
1330 | ||
1331 | @comment wordexp.h | |
1332 | @comment POSIX.2 | |
1333 | @item WRDE_SHOWERR | |
1334 | Do show any error messages printed by commands run by command substitution. | |
1335 | More precisely, allow these commands to inherit the standard error output | |
1336 | stream of the current process. By default, @code{wordexp} gives these | |
1337 | commands a standard error stream that discards all output. | |
1338 | ||
1339 | @comment wordexp.h | |
1340 | @comment POSIX.2 | |
1341 | @item WRDE_UNDEF | |
1342 | If the input refers to a shell variable that is not defined, report an | |
1343 | error. | |
1344 | @end table | |
1345 | ||
1346 | @node Wordexp Example | |
1347 | @subsection @code{wordexp} Example | |
1348 | ||
1349 | Here is an example of using @code{wordexp} to expand several strings | |
1350 | and use the results to run a shell command. It also shows the use of | |
1351 | @code{WRDE_APPEND} to concatenate the expansions and of @code{wordfree} | |
1352 | to free the space allocated by @code{wordexp}. | |
1353 | ||
1354 | @smallexample | |
1355 | int | |
1daa8164 | 1356 | expand_and_execute (const char *program, const char **options) |
28f540f4 RM |
1357 | @{ |
1358 | wordexp_t result; | |
1359 | pid_t pid | |
1360 | int status, i; | |
1361 | ||
1362 | /* @r{Expand the string for the program to run.} */ | |
1363 | switch (wordexp (program, &result, 0)) | |
1364 | @{ | |
1365 | case 0: /* @r{Successful}. */ | |
1366 | break; | |
1367 | case WRDE_NOSPACE: | |
1368 | /* @r{If the error was @code{WRDE_NOSPACE},} | |
1369 | @r{then perhaps part of the result was allocated.} */ | |
1370 | wordfree (&result); | |
1371 | default: /* @r{Some other error.} */ | |
1372 | return -1; | |
1373 | @} | |
1374 | ||
1375 | /* @r{Expand the strings specified for the arguments.} */ | |
1daa8164 | 1376 | for (i = 0; options[i] != NULL; i++) |
28f540f4 | 1377 | @{ |
1daa8164 | 1378 | if (wordexp (options[i], &result, WRDE_APPEND)) |
28f540f4 RM |
1379 | @{ |
1380 | wordfree (&result); | |
1381 | return -1; | |
1382 | @} | |
1383 | @} | |
1384 | ||
1385 | pid = fork (); | |
1386 | if (pid == 0) | |
1387 | @{ | |
1388 | /* @r{This is the child process. Execute the command.} */ | |
1389 | execv (result.we_wordv[0], result.we_wordv); | |
1390 | exit (EXIT_FAILURE); | |
1391 | @} | |
1392 | else if (pid < 0) | |
1393 | /* @r{The fork failed. Report failure.} */ | |
1394 | status = -1; | |
1395 | else | |
1396 | /* @r{This is the parent process. Wait for the child to complete.} */ | |
1397 | if (waitpid (pid, &status, 0) != pid) | |
1398 | status = -1; | |
1399 | ||
1400 | wordfree (&result); | |
1401 | return status; | |
1402 | @} | |
1403 | @end smallexample | |
1404 | ||
28f540f4 RM |
1405 | @node Tilde Expansion |
1406 | @subsection Details of Tilde Expansion | |
1407 | ||
1408 | It's a standard part of shell syntax that you can use @samp{~} at the | |
1409 | beginning of a file name to stand for your own home directory. You | |
1410 | can use @samp{~@var{user}} to stand for @var{user}'s home directory. | |
1411 | ||
1412 | @dfn{Tilde expansion} is the process of converting these abbreviations | |
1413 | to the directory names that they stand for. | |
1414 | ||
1415 | Tilde expansion applies to the @samp{~} plus all following characters up | |
1416 | to whitespace or a slash. It takes place only at the beginning of a | |
1417 | word, and only if none of the characters to be transformed is quoted in | |
1418 | any way. | |
1419 | ||
1420 | Plain @samp{~} uses the value of the environment variable @code{HOME} | |
1421 | as the proper home directory name. @samp{~} followed by a user name | |
1422 | uses @code{getpwname} to look up that user in the user database, and | |
1423 | uses whatever directory is recorded there. Thus, @samp{~} followed | |
1424 | by your own name can give different results from plain @samp{~}, if | |
1425 | the value of @code{HOME} is not really your home directory. | |
1426 | ||
1427 | @node Variable Substitution | |
1428 | @subsection Details of Variable Substitution | |
1429 | ||
1430 | Part of ordinary shell syntax is the use of @samp{$@var{variable}} to | |
1431 | substitute the value of a shell variable into a command. This is called | |
1432 | @dfn{variable substitution}, and it is one part of doing word expansion. | |
1433 | ||
1434 | There are two basic ways you can write a variable reference for | |
1435 | substitution: | |
1436 | ||
1437 | @table @code | |
1438 | @item $@{@var{variable}@} | |
1439 | If you write braces around the variable name, then it is completely | |
1440 | unambiguous where the variable name ends. You can concatenate | |
1441 | additional letters onto the end of the variable value by writing them | |
1442 | immediately after the close brace. For example, @samp{$@{foo@}s} | |
1443 | expands into @samp{tractors}. | |
1444 | ||
1445 | @item $@var{variable} | |
1446 | If you do not put braces around the variable name, then the variable | |
1447 | name consists of all the alphanumeric characters and underscores that | |
1448 | follow the @samp{$}. The next punctuation character ends the variable | |
1449 | name. Thus, @samp{$foo-bar} refers to the variable @code{foo} and expands | |
1450 | into @samp{tractor-bar}. | |
1451 | @end table | |
1452 | ||
1453 | When you use braces, you can also use various constructs to modify the | |
1454 | value that is substituted, or test it in various ways. | |
1455 | ||
1456 | @table @code | |
1457 | @item $@{@var{variable}:-@var{default}@} | |
1458 | Substitute the value of @var{variable}, but if that is empty or | |
1459 | undefined, use @var{default} instead. | |
1460 | ||
1461 | @item $@{@var{variable}:=@var{default}@} | |
1462 | Substitute the value of @var{variable}, but if that is empty or | |
1463 | undefined, use @var{default} instead and set the variable to | |
1464 | @var{default}. | |
1465 | ||
1466 | @item $@{@var{variable}:?@var{message}@} | |
1467 | If @var{variable} is defined and not empty, substitute its value. | |
1468 | ||
1469 | Otherwise, print @var{message} as an error message on the standard error | |
1470 | stream, and consider word expansion a failure. | |
1471 | ||
1472 | @c ??? How does wordexp report such an error? | |
14eb5d5d | 1473 | @c WRDE_BADVAL is returned. |
28f540f4 RM |
1474 | |
1475 | @item $@{@var{variable}:+@var{replacement}@} | |
1476 | Substitute @var{replacement}, but only if @var{variable} is defined and | |
1477 | nonempty. Otherwise, substitute nothing for this construct. | |
1478 | @end table | |
1479 | ||
1480 | @table @code | |
1481 | @item $@{#@var{variable}@} | |
1482 | Substitute a numeral which expresses in base ten the number of | |
1483 | characters in the value of @var{variable}. @samp{$@{#foo@}} stands for | |
1484 | @samp{7}, because @samp{tractor} is seven characters. | |
1485 | @end table | |
1486 | ||
1487 | These variants of variable substitution let you remove part of the | |
6d52618b | 1488 | variable's value before substituting it. The @var{prefix} and |
28f540f4 RM |
1489 | @var{suffix} are not mere strings; they are wildcard patterns, just |
1490 | like the patterns that you use to match multiple file names. But | |
1491 | in this context, they match against parts of the variable value | |
1492 | rather than against file names. | |
1493 | ||
1494 | @table @code | |
1495 | @item $@{@var{variable}%%@var{suffix}@} | |
1496 | Substitute the value of @var{variable}, but first discard from that | |
1497 | variable any portion at the end that matches the pattern @var{suffix}. | |
1498 | ||
1499 | If there is more than one alternative for how to match against | |
1500 | @var{suffix}, this construct uses the longest possible match. | |
1501 | ||
1502 | Thus, @samp{$@{foo%%r*@}} substitutes @samp{t}, because the largest | |
1503 | match for @samp{r*} at the end of @samp{tractor} is @samp{ractor}. | |
1504 | ||
1505 | @item $@{@var{variable}%@var{suffix}@} | |
1506 | Substitute the value of @var{variable}, but first discard from that | |
1507 | variable any portion at the end that matches the pattern @var{suffix}. | |
1508 | ||
1509 | If there is more than one alternative for how to match against | |
1510 | @var{suffix}, this construct uses the shortest possible alternative. | |
1511 | ||
d6b3602f | 1512 | Thus, @samp{$@{foo%r*@}} substitutes @samp{tracto}, because the shortest |
28f540f4 RM |
1513 | match for @samp{r*} at the end of @samp{tractor} is just @samp{r}. |
1514 | ||
1515 | @item $@{@var{variable}##@var{prefix}@} | |
1516 | Substitute the value of @var{variable}, but first discard from that | |
1517 | variable any portion at the beginning that matches the pattern @var{prefix}. | |
1518 | ||
1519 | If there is more than one alternative for how to match against | |
1520 | @var{prefix}, this construct uses the longest possible match. | |
1521 | ||
d6b3602f RM |
1522 | Thus, @samp{$@{foo##*t@}} substitutes @samp{or}, because the largest |
1523 | match for @samp{*t} at the beginning of @samp{tractor} is @samp{tract}. | |
28f540f4 RM |
1524 | |
1525 | @item $@{@var{variable}#@var{prefix}@} | |
1526 | Substitute the value of @var{variable}, but first discard from that | |
1527 | variable any portion at the beginning that matches the pattern @var{prefix}. | |
1528 | ||
1529 | If there is more than one alternative for how to match against | |
1530 | @var{prefix}, this construct uses the shortest possible alternative. | |
1531 | ||
d6b3602f RM |
1532 | Thus, @samp{$@{foo#*t@}} substitutes @samp{ractor}, because the shortest |
1533 | match for @samp{*t} at the beginning of @samp{tractor} is just @samp{t}. | |
28f540f4 | 1534 | |
14eb5d5d | 1535 | @end table |