Skip to content

Commit 306be1a

Browse files
authored
Merge pull request #3590 from AmaiKinono/fix-ctags-client-tools
docs(man): improve the section on building readtags expressions
2 parents b66c218 + 2ab82cc commit 306be1a

File tree

2 files changed

+48
-36
lines changed

2 files changed

+48
-36
lines changed

docs/man/ctags-client-tools.7.rst

Lines changed: 24 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -296,19 +296,28 @@ example, when searching for a tag that matches ``a\?b``, if using a filter
296296
expression like ``'(eq? $name "a\?b")'``, since ``\?`` is translated into a
297297
single ``?`` by readtags, it actually searches for ``a?b``.
298298

299-
Another problem is if a single quote appear in filter expressions (which is
300-
also wrapped by single quotes), it terminates the expression, producing broken
301-
expressions, and may even cause unintended shell injection. Single quotes can
302-
be escaped using ``'"'"'``.
299+
Another problem is: If the client tools talks to readtags not by subprocess
300+
directly, but through a shell, then if a single quote appear in filter
301+
expressions (which is also wrapped by single quotes), it terminates the
302+
expression, producing broken expressions, and may even cause unintended shell
303+
injection. Single quotes can be escaped using ``'"'"'``.
303304

304305
So, client tools need to:
305306

306307
* Replace ``\`` by ``\\``
307-
* Replace ``'`` by ``'"'"'``
308+
* Replace ``'`` by ``'"'"'``, if it talks to readtags through a shell.
308309

309310
inside the expressions. If the expression also contains strings, ``"`` in the
310311
strings needs to be replaced by ``\"``.
311312

313+
Another thing to notice is that missing fields are represented by ``#f``, and
314+
applying string operators to them will produce an error. You should always
315+
check if a field is missing before applying string operators. See the
316+
"Filtering" section in :ref:`readtags(1) <readtags(1)>` to know how to do this. Run "readtags -H
317+
filter" to see which operators take string arguments.
318+
319+
Build Filter/Sorter Expressions using Lisp Languages
320+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
312321
Client tools written in Lisp could build the expression using lists. ``prin1``
313322
(in Common Lisp style Lisps) and ``write`` (in Scheme style Lisps) can
314323
translate the list into a string that can be directly used. For example, in
@@ -320,11 +329,13 @@ EmacsLisp:
320329
(prin1 `(eq? $name ,name)))
321330
=> "(eq\\? $name "hi")"
322331
323-
The "?" is escaped, and readtags can handle it. Scheme style Lisps should do
324-
proper escaping so the expression readtags gets is just the expression passed
325-
into ``write``. Common Lisp style Lisps may produce unrecognized escape
326-
sequences by readtags, like ``\#``. Readtags provides some aliases for these
327-
Lisps:
332+
The "?" is escaped, and readtags can handle it.
333+
334+
Escape sequences produced by ``write`` in Scheme style Lisps are exactly those
335+
supported by readtags, so any legal readtags expressions can be used. Common
336+
Lisp style Lisps may produce escape sequences that are unrecgonized by
337+
readtags, like ``\#``, so symbols that contain "#" can't be used. Readtags
338+
provides some aliases for these Lisps, so they should:
328339

329340
* Use ``true`` for ``#t``.
330341
* Use ``false`` for ``#f``.
@@ -333,14 +344,9 @@ Lisps:
333344
``(string->regexp "PATTERN" :case-fold true)`` for ``#/PATTERN/i``. Notice
334345
that ``string->regexp`` doesn't require escaping "/" in the pattern.
335346

336-
Notice that even when the client tool uses this method, ``'`` still needs to be
337-
replaced by ``'"'"'`` to prevent broken expressions and shell injection.
338-
339-
Another thing to notice is that missing fields are represented by ``#f``, and
340-
applying string operators to them will produce an error. You should always
341-
check if a field is missing before applying string operators. See the
342-
"Filtering" section in :ref:`readtags(1) <readtags(1)>` to know how to do this. Run "readtags -H
343-
filter" to see which operators take string arguments.
347+
Notice that if the client tool talks to readtags through a shell, then in the
348+
produced string, ``'`` still needs to be replaced by ``'"'"'`` to prevent
349+
broken expressions and shell injection.
344350

345351
Parse Readtags Output
346352
~~~~~~~~~~~~~~~~~~~~~

man/ctags-client-tools.7.rst.in

Lines changed: 24 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -296,19 +296,28 @@ example, when searching for a tag that matches ``a\?b``, if using a filter
296296
expression like ``'(eq? $name "a\?b")'``, since ``\?`` is translated into a
297297
single ``?`` by readtags, it actually searches for ``a?b``.
298298

299-
Another problem is if a single quote appear in filter expressions (which is
300-
also wrapped by single quotes), it terminates the expression, producing broken
301-
expressions, and may even cause unintended shell injection. Single quotes can
302-
be escaped using ``'"'"'``.
299+
Another problem is: If the client tools talks to readtags not by subprocess
300+
directly, but through a shell, then if a single quote appear in filter
301+
expressions (which is also wrapped by single quotes), it terminates the
302+
expression, producing broken expressions, and may even cause unintended shell
303+
injection. Single quotes can be escaped using ``'"'"'``.
303304

304305
So, client tools need to:
305306

306307
* Replace ``\`` by ``\\``
307-
* Replace ``'`` by ``'"'"'``
308+
* Replace ``'`` by ``'"'"'``, if it talks to readtags through a shell.
308309

309310
inside the expressions. If the expression also contains strings, ``"`` in the
310311
strings needs to be replaced by ``\"``.
311312

313+
Another thing to notice is that missing fields are represented by ``#f``, and
314+
applying string operators to them will produce an error. You should always
315+
check if a field is missing before applying string operators. See the
316+
"Filtering" section in readtags(1) to know how to do this. Run "readtags -H
317+
filter" to see which operators take string arguments.
318+
319+
Build Filter/Sorter Expressions using Lisp Languages
320+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
312321
Client tools written in Lisp could build the expression using lists. ``prin1``
313322
(in Common Lisp style Lisps) and ``write`` (in Scheme style Lisps) can
314323
translate the list into a string that can be directly used. For example, in
@@ -320,11 +329,13 @@ EmacsLisp:
320329
(prin1 `(eq? $name ,name)))
321330
=> "(eq\\? $name "hi")"
322331

323-
The "?" is escaped, and readtags can handle it. Scheme style Lisps should do
324-
proper escaping so the expression readtags gets is just the expression passed
325-
into ``write``. Common Lisp style Lisps may produce unrecognized escape
326-
sequences by readtags, like ``\#``. Readtags provides some aliases for these
327-
Lisps:
332+
The "?" is escaped, and readtags can handle it.
333+
334+
Escape sequences produced by ``write`` in Scheme style Lisps are exactly those
335+
supported by readtags, so any legal readtags expressions can be used. Common
336+
Lisp style Lisps may produce escape sequences that are unrecgonized by
337+
readtags, like ``\#``, so symbols that contain "#" can't be used. Readtags
338+
provides some aliases for these Lisps, so they should:
328339

329340
* Use ``true`` for ``#t``.
330341
* Use ``false`` for ``#f``.
@@ -333,14 +344,9 @@ Lisps:
333344
``(string->regexp "PATTERN" :case-fold true)`` for ``#/PATTERN/i``. Notice
334345
that ``string->regexp`` doesn't require escaping "/" in the pattern.
335346

336-
Notice that even when the client tool uses this method, ``'`` still needs to be
337-
replaced by ``'"'"'`` to prevent broken expressions and shell injection.
338-
339-
Another thing to notice is that missing fields are represented by ``#f``, and
340-
applying string operators to them will produce an error. You should always
341-
check if a field is missing before applying string operators. See the
342-
"Filtering" section in readtags(1) to know how to do this. Run "readtags -H
343-
filter" to see which operators take string arguments.
347+
Notice that if the client tool talks to readtags through a shell, then in the
348+
produced string, ``'`` still needs to be replaced by ``'"'"'`` to prevent
349+
broken expressions and shell injection.
344350

345351
Parse Readtags Output
346352
~~~~~~~~~~~~~~~~~~~~~

0 commit comments

Comments
 (0)