1. Introduction
Usually wildcards are managed by the calling shell.
So if you use for excample
./path/*.szs,
the shell searches the files, expand the command line, so that the SZS tools
gets a list of files,
something like
./path/a.szs ./path/b.szs ./path/c.szs.
This list can become very, very long, so that the permitted characters
for the command line are no longer sufficient.
Another problem is the use of wildcards in options. So --add-section *.gct
expands to --add-section a.gct b.gct.
Only the first file a.gct is considered as a parameter of the option.
For this case, the SZS tools evaluate so-called wildcards for some commands and options by themself.
In the above examples, it would then only have to be prevented that the outer shell
evaluates the wildcards. This is usually done by quoting the parameters.
For the examples of above, use "./path/*.szs"
or --add-section "*.gct".
You can test the expansion with command EXPAND
that is available for all tools.
So try for example wlect EXPAND "./path/to/*.szs".
The following sections describe how placeholders are resolved.
1.1 Behavior
Some commands and options accept wildcards and expand them internally.
Wildcards were implemented in the commands in 2 different methods.
The built-in help and this website inform about the details of the implementation.
In the classic method, each individual parameter is checked for wildcards. If available,
the wildcards are evaluated immediately and all matching files are processed directly.
In the current method, wildcards are evaluated and the matching file names are
stored in a list together with the simple file names.
This list is sorted by file paths and duplicates are deleted.
After adding all file names, the individual files are processed.
1.2 --in-order
Process the input files in order of the command line and don't delete duplicates.
Option
--in-order is only available for the current method and disables sorting
so that all file names are appended to the list in the order of the command line.
This means that no duplicates are recognized or deleted.
This then leads to an evaluation similar to the classic method.
2. Simple Wildcards
The SZS tools choose between doing a simple string match and wildcard matching
by checking if the pattern contains one of these wildcard characters:
*,
?,
#,
[,
{ and
TAB.
This check is done for every directory and for the base name of the path.
- * matches any path component, but it stops at slashes.
- ? matches any character except a slash (/).
- # matches 1 or more digits (0-9).
- [ introduces a character class, such as [a-z].
- { introduces a comma-separated list of alternatives,
such as {anton,bert}.
- TAB The tabulator matches any white space.
3. Wildcard **
A special case is the wildcard
**.
It is recognized only at the beginning of a path component.
Optionally it can be followed by a range specification to declare
the minimum and/or maximum recursion (sub-directory) depth.
The following list explains all allowed variants:
- **
- This matches any number (≥0) sub-directories.
- **A
- If A is an unsigned integer,
then it matches exact A sub-directories.
- **A-
- If A is an unsigned integer,
then it matches from A to unlimited sub-directories.
- **A-B
- If A and B
are unsigned integers, then it matches from A to B sub-directories.
- **-B
- If B is an unsigned integer,
then it matches from 0 to B sub-directories.
Examples:
./tracks/**/*.szs **-2/*.szs
Due to a programming error,
** did not work correctly.
The recursion depth was always 1 level higher than specified.
So level 0 was never possible.
The error is included up to version v2.28a
and has been fixed with version v2.29a (2022-10-27).
