tris/recoll
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

doc

Browse Source
This commit is contained in:
Jean-Francois Dockes 2013-04-01 18:40:42 +02:00
parent 39456d8135
commit 4d5cd413af
1 changed files with 46 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
src/doc/user/usermanual.sgml
View File

@ -2780,14 +2780,16 @@ text/html [file:///Users/uncrypted-dockes/projets/bateaux/ilur/factEtCie/r
<itemizedlist> <itemizedlist>
<listitem><para><literal>dir</literal> for filtering the <listitem><para><literal>dir</literal> for filtering the
results on file location (Ex: results on file location
<literal>dir:/home/me/somedir</literal>). <literal>-dir</literal> (Ex: <literal>dir:/home/me/somedir</literal>).
<literal>-dir</literal>
also works to find results not in the specified directory also works to find results not in the specified directory
(release >= 1.15.8). A tilde inside the value will be expanded (release >= 1.15.8). A tilde inside the value will be
to the home directory. Wildcards will <emphasis>not</emphasis> expanded to the home directory. Wildcards will be
be expanded. You cannot use <literal>OR</literal> with expanded, but
<literal>dir</literal> clauses (this restriction may go away in please <link linkend="RCL.SEARCH.WILDCARDS.PATH"> have a
the future).</para> look</link> at an important limitation of wildcards in
path filters.</para>
<para>Relative paths also make sense, for example, <para>Relative paths also make sense, for example,
<literal>dir:share/doc</literal> would match either <literal>dir:share/doc</literal> would match either
@ -2804,7 +2806,10 @@ dir:recoll dir:src -dir:utils -dir:common
<filename>utils</filename> or <filename>utils</filename> or
<filename>common</filename>.</para> <filename>common</filename>.</para>
<para>Another special aspect of <literal>dir</literal> clauses is <para>You can also use <literal>OR</literal> conjunctions
with <literal>dir:</literal> clauses.</para>
<para>A special aspect of <literal>dir</literal> clauses is
that the values in the index are not transcoded to UTF-8, and that the values in the index are not transcoded to UTF-8, and
never lower-cased or unaccented, but stored as binary. This means never lower-cased or unaccented, but stored as binary. This means
that you need to enter the values in the exact lower or upper that you need to enter the values in the exact lower or upper
@ -3094,6 +3099,31 @@ dir:recoll dir:src -dir:utils -dir:common
term).</para></listitem> term).</para></listitem>
</itemizedlist> </itemizedlist>
<sect3 id="RCL.SEARCH.WILDCARDS.PATH">
<title>Wildcards and path filtering</title>
<para>Due to the way that &RCL; processes wildcards
inside <literal>dir</literal> path filtering clauses, they
will have a multiplicative effect on the query size. A clause
containg wildcards in several paths elements, like, for
example,
<literal>dir:</literal><replaceable>/home/me/*/*/docdir</replaceable>,
will almost certainly fail if your indexed tree is of any realistic
size.</para>
<para>Depending on the case, you may be able to work around
the issue by specifying the paths elements more narrowly, with
a constant prefix, or by using 2
separate <literal>dir:</literal> clauses instead of multiple
wildcards, as
in <literal>dir:</literal><replaceable>/home/me</replaceable> <literal>dir:</literal><replaceable>docdir</replaceable>. The
latter query is not equivalent to the initial one because it
does not specify a number of directory levels, but that's
the best we can do (and it may be actually more useful in
some cases).</para>
</sect3>
</sect2> <!-- wildchars --> </sect2> <!-- wildchars -->
<sect2 id="RCL.SEARCH.ANCHOR"> <sect2 id="RCL.SEARCH.ANCHOR">