2019-03-31 09:05:09 +00:00
.. _cmd-string:
2018-12-17 01:39:33 +00:00
string - manipulate strings
2019-01-03 04:10:47 +00:00
===========================
2018-12-17 01:39:33 +00:00
2018-12-18 01:58:24 +00:00
Synopsis
--------
2018-12-16 21:08:41 +00:00
docs synopsis: add HTML highlighing and automate manpage markup
Recent synopsis changes move from literal code blocks to
[RST line blocks]. This does not translate well to HTML: it's not
rendered in monospace, so aligment is lost. Additionally, we don't
get syntax highlighting in HTML, which adds differences to our code
samples which are highlighted.
We hard-wrap synopsis lines (like code blocks). To align continuation
lines in manpages we need [backslashes in weird places]. Combined with
the **, *, and `` markup, it's a bit hard to get the alignment right.
Fix these by moving synopsis sources back to code blocks and compute
HTML syntax highlighting and manpage markup with a custom Sphinx
extension.
The new Pygments lexer can tokenize a synopsis and assign the various
highlighting roles, which closely matches fish's syntax highlighing:
- command/keyword (dark blue)
- parameter (light blue)
- operator like and/or/not/&&/|| (cyan)
- grammar metacharacter (black)
For manpage output, we don't project the fish syntax highlighting
but follow the markup convention in GNU's man(1):
bold text type exactly as shown.
italic text replace with appropriate argument.
To make it easy to separate these two automatically, formalize that
(italic) placeholders must be uppercase; while all lowercase text is
interpreted literally (so rendered bold).
This makes manpages more consistent, see string-join(1) and and(1).
Implementation notes:
Since we want manpage formatting but Sphinx's Pygments highlighing
plugin does not support manpage output, add our custom "synopsis"
directive. This directive parses differently when manpage output is
specified. This means that the HTML and manpage build processes must
not share a cache, because the parsed doctrees are cached. Work around
this by using separate cache locations for build targets "sphinx-docs"
(which creates HTML) and "sphinx-manpages". A better solution would
be to only override Sphinx's ManualPageBuilder but that would take a
bit more code (ideally we could override ManualPageWriter but Sphinx
4.3.2 doesn't really support that).
---
Alternative solution: stick with line blocks but use roles like
:command: or :option: (or custom ones). While this would make it
possible to produce HTML that is consistent with code blocks (by adding
a bit of CSS), the source would look uglier and is harder to maintain.
(Let's say we want to add custom formatting to the [|] metacharacters
in HTML. This is much easier with the proposed patch.)
---
[RST line blocks]: https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#line-blocks
[backslashes in weird places]: https://github.com/fish-shell/fish-shell/pull/8626#discussion_r782837750
2022-01-09 14:09:46 +00:00
.. synopsis ::
2022-05-03 10:30:59 +00:00
string collect [-a | --allow-empty] [-N | --no-trim-newlines] [STRING ...]
docs synopsis: add HTML highlighing and automate manpage markup
Recent synopsis changes move from literal code blocks to
[RST line blocks]. This does not translate well to HTML: it's not
rendered in monospace, so aligment is lost. Additionally, we don't
get syntax highlighting in HTML, which adds differences to our code
samples which are highlighted.
We hard-wrap synopsis lines (like code blocks). To align continuation
lines in manpages we need [backslashes in weird places]. Combined with
the **, *, and `` markup, it's a bit hard to get the alignment right.
Fix these by moving synopsis sources back to code blocks and compute
HTML syntax highlighting and manpage markup with a custom Sphinx
extension.
The new Pygments lexer can tokenize a synopsis and assign the various
highlighting roles, which closely matches fish's syntax highlighing:
- command/keyword (dark blue)
- parameter (light blue)
- operator like and/or/not/&&/|| (cyan)
- grammar metacharacter (black)
For manpage output, we don't project the fish syntax highlighting
but follow the markup convention in GNU's man(1):
bold text type exactly as shown.
italic text replace with appropriate argument.
To make it easy to separate these two automatically, formalize that
(italic) placeholders must be uppercase; while all lowercase text is
interpreted literally (so rendered bold).
This makes manpages more consistent, see string-join(1) and and(1).
Implementation notes:
Since we want manpage formatting but Sphinx's Pygments highlighing
plugin does not support manpage output, add our custom "synopsis"
directive. This directive parses differently when manpage output is
specified. This means that the HTML and manpage build processes must
not share a cache, because the parsed doctrees are cached. Work around
this by using separate cache locations for build targets "sphinx-docs"
(which creates HTML) and "sphinx-manpages". A better solution would
be to only override Sphinx's ManualPageBuilder but that would take a
bit more code (ideally we could override ManualPageWriter but Sphinx
4.3.2 doesn't really support that).
---
Alternative solution: stick with line blocks but use roles like
:command: or :option: (or custom ones). While this would make it
possible to produce HTML that is consistent with code blocks (by adding
a bit of CSS), the source would look uglier and is harder to maintain.
(Let's say we want to add custom formatting to the [|] metacharacters
in HTML. This is much easier with the proposed patch.)
---
[RST line blocks]: https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#line-blocks
[backslashes in weird places]: https://github.com/fish-shell/fish-shell/pull/8626#discussion_r782837750
2022-01-09 14:09:46 +00:00
string escape [-n | --no-quoted] [--style=] [STRING ...]
2022-03-13 10:47:33 +00:00
string join [-q | --quiet] [-n | --no-empty] SEP [STRING ...]
docs synopsis: add HTML highlighing and automate manpage markup
Recent synopsis changes move from literal code blocks to
[RST line blocks]. This does not translate well to HTML: it's not
rendered in monospace, so aligment is lost. Additionally, we don't
get syntax highlighting in HTML, which adds differences to our code
samples which are highlighted.
We hard-wrap synopsis lines (like code blocks). To align continuation
lines in manpages we need [backslashes in weird places]. Combined with
the **, *, and `` markup, it's a bit hard to get the alignment right.
Fix these by moving synopsis sources back to code blocks and compute
HTML syntax highlighting and manpage markup with a custom Sphinx
extension.
The new Pygments lexer can tokenize a synopsis and assign the various
highlighting roles, which closely matches fish's syntax highlighing:
- command/keyword (dark blue)
- parameter (light blue)
- operator like and/or/not/&&/|| (cyan)
- grammar metacharacter (black)
For manpage output, we don't project the fish syntax highlighting
but follow the markup convention in GNU's man(1):
bold text type exactly as shown.
italic text replace with appropriate argument.
To make it easy to separate these two automatically, formalize that
(italic) placeholders must be uppercase; while all lowercase text is
interpreted literally (so rendered bold).
This makes manpages more consistent, see string-join(1) and and(1).
Implementation notes:
Since we want manpage formatting but Sphinx's Pygments highlighing
plugin does not support manpage output, add our custom "synopsis"
directive. This directive parses differently when manpage output is
specified. This means that the HTML and manpage build processes must
not share a cache, because the parsed doctrees are cached. Work around
this by using separate cache locations for build targets "sphinx-docs"
(which creates HTML) and "sphinx-manpages". A better solution would
be to only override Sphinx's ManualPageBuilder but that would take a
bit more code (ideally we could override ManualPageWriter but Sphinx
4.3.2 doesn't really support that).
---
Alternative solution: stick with line blocks but use roles like
:command: or :option: (or custom ones). While this would make it
possible to produce HTML that is consistent with code blocks (by adding
a bit of CSS), the source would look uglier and is harder to maintain.
(Let's say we want to add custom formatting to the [|] metacharacters
in HTML. This is much easier with the proposed patch.)
---
[RST line blocks]: https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#line-blocks
[backslashes in weird places]: https://github.com/fish-shell/fish-shell/pull/8626#discussion_r782837750
2022-01-09 14:09:46 +00:00
string join0 [-q | --quiet] [STRING ...]
string length [-q | --quiet] [STRING ...]
string lower [-q | --quiet] [STRING ...]
string match [-a | --all] [-e | --entire] [-i | --ignore-case]
2022-05-03 10:30:59 +00:00
[-g | --groups-only] [-r | --regex] [-n | --index]
[-q | --quiet] [-v | --invert]
docs synopsis: add HTML highlighing and automate manpage markup
Recent synopsis changes move from literal code blocks to
[RST line blocks]. This does not translate well to HTML: it's not
rendered in monospace, so aligment is lost. Additionally, we don't
get syntax highlighting in HTML, which adds differences to our code
samples which are highlighted.
We hard-wrap synopsis lines (like code blocks). To align continuation
lines in manpages we need [backslashes in weird places]. Combined with
the **, *, and `` markup, it's a bit hard to get the alignment right.
Fix these by moving synopsis sources back to code blocks and compute
HTML syntax highlighting and manpage markup with a custom Sphinx
extension.
The new Pygments lexer can tokenize a synopsis and assign the various
highlighting roles, which closely matches fish's syntax highlighing:
- command/keyword (dark blue)
- parameter (light blue)
- operator like and/or/not/&&/|| (cyan)
- grammar metacharacter (black)
For manpage output, we don't project the fish syntax highlighting
but follow the markup convention in GNU's man(1):
bold text type exactly as shown.
italic text replace with appropriate argument.
To make it easy to separate these two automatically, formalize that
(italic) placeholders must be uppercase; while all lowercase text is
interpreted literally (so rendered bold).
This makes manpages more consistent, see string-join(1) and and(1).
Implementation notes:
Since we want manpage formatting but Sphinx's Pygments highlighing
plugin does not support manpage output, add our custom "synopsis"
directive. This directive parses differently when manpage output is
specified. This means that the HTML and manpage build processes must
not share a cache, because the parsed doctrees are cached. Work around
this by using separate cache locations for build targets "sphinx-docs"
(which creates HTML) and "sphinx-manpages". A better solution would
be to only override Sphinx's ManualPageBuilder but that would take a
bit more code (ideally we could override ManualPageWriter but Sphinx
4.3.2 doesn't really support that).
---
Alternative solution: stick with line blocks but use roles like
:command: or :option: (or custom ones). While this would make it
possible to produce HTML that is consistent with code blocks (by adding
a bit of CSS), the source would look uglier and is harder to maintain.
(Let's say we want to add custom formatting to the [|] metacharacters
in HTML. This is much easier with the proposed patch.)
---
[RST line blocks]: https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#line-blocks
[backslashes in weird places]: https://github.com/fish-shell/fish-shell/pull/8626#discussion_r782837750
2022-01-09 14:09:46 +00:00
PATTERN [STRING ...]
2022-05-03 23:39:04 +00:00
string pad [-r | --right] [(-c | --char) CHAR] [(-w | --width) INTEGER]
docs synopsis: add HTML highlighing and automate manpage markup
Recent synopsis changes move from literal code blocks to
[RST line blocks]. This does not translate well to HTML: it's not
rendered in monospace, so aligment is lost. Additionally, we don't
get syntax highlighting in HTML, which adds differences to our code
samples which are highlighted.
We hard-wrap synopsis lines (like code blocks). To align continuation
lines in manpages we need [backslashes in weird places]. Combined with
the **, *, and `` markup, it's a bit hard to get the alignment right.
Fix these by moving synopsis sources back to code blocks and compute
HTML syntax highlighting and manpage markup with a custom Sphinx
extension.
The new Pygments lexer can tokenize a synopsis and assign the various
highlighting roles, which closely matches fish's syntax highlighing:
- command/keyword (dark blue)
- parameter (light blue)
- operator like and/or/not/&&/|| (cyan)
- grammar metacharacter (black)
For manpage output, we don't project the fish syntax highlighting
but follow the markup convention in GNU's man(1):
bold text type exactly as shown.
italic text replace with appropriate argument.
To make it easy to separate these two automatically, formalize that
(italic) placeholders must be uppercase; while all lowercase text is
interpreted literally (so rendered bold).
This makes manpages more consistent, see string-join(1) and and(1).
Implementation notes:
Since we want manpage formatting but Sphinx's Pygments highlighing
plugin does not support manpage output, add our custom "synopsis"
directive. This directive parses differently when manpage output is
specified. This means that the HTML and manpage build processes must
not share a cache, because the parsed doctrees are cached. Work around
this by using separate cache locations for build targets "sphinx-docs"
(which creates HTML) and "sphinx-manpages". A better solution would
be to only override Sphinx's ManualPageBuilder but that would take a
bit more code (ideally we could override ManualPageWriter but Sphinx
4.3.2 doesn't really support that).
---
Alternative solution: stick with line blocks but use roles like
:command: or :option: (or custom ones). While this would make it
possible to produce HTML that is consistent with code blocks (by adding
a bit of CSS), the source would look uglier and is harder to maintain.
(Let's say we want to add custom formatting to the [|] metacharacters
in HTML. This is much easier with the proposed patch.)
---
[RST line blocks]: https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#line-blocks
[backslashes in weird places]: https://github.com/fish-shell/fish-shell/pull/8626#discussion_r782837750
2022-01-09 14:09:46 +00:00
[STRING ...]
string repeat [(-n | --count) COUNT] [(-m | --max) MAX] [-N | --no-newline]
[-q | --quiet] [STRING ...]
2024-02-11 11:43:13 +00:00
string repeat [-N | --no-newline] [-q | --quiet] COUNT [STRING ...]
docs synopsis: add HTML highlighing and automate manpage markup
Recent synopsis changes move from literal code blocks to
[RST line blocks]. This does not translate well to HTML: it's not
rendered in monospace, so aligment is lost. Additionally, we don't
get syntax highlighting in HTML, which adds differences to our code
samples which are highlighted.
We hard-wrap synopsis lines (like code blocks). To align continuation
lines in manpages we need [backslashes in weird places]. Combined with
the **, *, and `` markup, it's a bit hard to get the alignment right.
Fix these by moving synopsis sources back to code blocks and compute
HTML syntax highlighting and manpage markup with a custom Sphinx
extension.
The new Pygments lexer can tokenize a synopsis and assign the various
highlighting roles, which closely matches fish's syntax highlighing:
- command/keyword (dark blue)
- parameter (light blue)
- operator like and/or/not/&&/|| (cyan)
- grammar metacharacter (black)
For manpage output, we don't project the fish syntax highlighting
but follow the markup convention in GNU's man(1):
bold text type exactly as shown.
italic text replace with appropriate argument.
To make it easy to separate these two automatically, formalize that
(italic) placeholders must be uppercase; while all lowercase text is
interpreted literally (so rendered bold).
This makes manpages more consistent, see string-join(1) and and(1).
Implementation notes:
Since we want manpage formatting but Sphinx's Pygments highlighing
plugin does not support manpage output, add our custom "synopsis"
directive. This directive parses differently when manpage output is
specified. This means that the HTML and manpage build processes must
not share a cache, because the parsed doctrees are cached. Work around
this by using separate cache locations for build targets "sphinx-docs"
(which creates HTML) and "sphinx-manpages". A better solution would
be to only override Sphinx's ManualPageBuilder but that would take a
bit more code (ideally we could override ManualPageWriter but Sphinx
4.3.2 doesn't really support that).
---
Alternative solution: stick with line blocks but use roles like
:command: or :option: (or custom ones). While this would make it
possible to produce HTML that is consistent with code blocks (by adding
a bit of CSS), the source would look uglier and is harder to maintain.
(Let's say we want to add custom formatting to the [|] metacharacters
in HTML. This is much easier with the proposed patch.)
---
[RST line blocks]: https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#line-blocks
[backslashes in weird places]: https://github.com/fish-shell/fish-shell/pull/8626#discussion_r782837750
2022-01-09 14:09:46 +00:00
string replace [-a | --all] [-f | --filter] [-i | --ignore-case]
[-r | --regex] [-q | --quiet] PATTERN REPLACE [STRING ...]
2022-10-06 19:30:01 +00:00
string shorten [(-c | --char) CHARS] [(-m | --max) INTEGER]
[-N | --no-newline] [-l | --left] [-q | --quiet] [STRING ...]
2022-05-03 23:39:04 +00:00
string split [(-f | --fields) FIELDS] [(-m | --max) MAX] [-n | --no-empty]
2022-05-02 15:19:37 +00:00
[-q | --quiet] [-r | --right] SEP [STRING ...]
2022-05-03 23:39:04 +00:00
string split0 [(-f | --fields) FIELDS] [(-m | --max) MAX] [-n | --no-empty]
2022-05-02 15:19:37 +00:00
[-q | --quiet] [-r | --right] [STRING ...]
2022-05-03 10:30:59 +00:00
string sub [(-s | --start) START] [(-e | --end) END] [(-l | --length) LENGTH]
docs synopsis: add HTML highlighing and automate manpage markup
Recent synopsis changes move from literal code blocks to
[RST line blocks]. This does not translate well to HTML: it's not
rendered in monospace, so aligment is lost. Additionally, we don't
get syntax highlighting in HTML, which adds differences to our code
samples which are highlighted.
We hard-wrap synopsis lines (like code blocks). To align continuation
lines in manpages we need [backslashes in weird places]. Combined with
the **, *, and `` markup, it's a bit hard to get the alignment right.
Fix these by moving synopsis sources back to code blocks and compute
HTML syntax highlighting and manpage markup with a custom Sphinx
extension.
The new Pygments lexer can tokenize a synopsis and assign the various
highlighting roles, which closely matches fish's syntax highlighing:
- command/keyword (dark blue)
- parameter (light blue)
- operator like and/or/not/&&/|| (cyan)
- grammar metacharacter (black)
For manpage output, we don't project the fish syntax highlighting
but follow the markup convention in GNU's man(1):
bold text type exactly as shown.
italic text replace with appropriate argument.
To make it easy to separate these two automatically, formalize that
(italic) placeholders must be uppercase; while all lowercase text is
interpreted literally (so rendered bold).
This makes manpages more consistent, see string-join(1) and and(1).
Implementation notes:
Since we want manpage formatting but Sphinx's Pygments highlighing
plugin does not support manpage output, add our custom "synopsis"
directive. This directive parses differently when manpage output is
specified. This means that the HTML and manpage build processes must
not share a cache, because the parsed doctrees are cached. Work around
this by using separate cache locations for build targets "sphinx-docs"
(which creates HTML) and "sphinx-manpages". A better solution would
be to only override Sphinx's ManualPageBuilder but that would take a
bit more code (ideally we could override ManualPageWriter but Sphinx
4.3.2 doesn't really support that).
---
Alternative solution: stick with line blocks but use roles like
:command: or :option: (or custom ones). While this would make it
possible to produce HTML that is consistent with code blocks (by adding
a bit of CSS), the source would look uglier and is harder to maintain.
(Let's say we want to add custom formatting to the [|] metacharacters
in HTML. This is much easier with the proposed patch.)
---
[RST line blocks]: https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#line-blocks
[backslashes in weird places]: https://github.com/fish-shell/fish-shell/pull/8626#discussion_r782837750
2022-01-09 14:09:46 +00:00
[-q | --quiet] [STRING ...]
string trim [-l | --left] [-r | --right] [(-c | --chars) CHARS]
[-q | --quiet] [STRING ...]
string unescape [--style=] [STRING ...]
string upper [-q | --quiet] [STRING ...]
2018-12-16 21:08:41 +00:00
2018-12-19 02:44:30 +00:00
Description
2019-01-03 04:10:47 +00:00
-----------
2018-12-16 21:08:41 +00:00
2018-12-19 20:02:45 +00:00
`` string `` performs operations on strings.
2018-12-16 21:08:41 +00:00
2022-03-12 14:22:00 +00:00
*STRING* arguments are taken from the command line unless standard input is connected to a pipe or a file, in which case they are read from standard input, one *STRING* per line. It is an error to supply *STRING* arguments on the command line and on standard input.
2018-12-16 21:08:41 +00:00
2018-12-19 20:02:45 +00:00
Arguments beginning with `` - `` are normally interpreted as switches; `` -- `` causes the following arguments not to be treated as switches even if they begin with `` - `` . Switches and required arguments are recognized only on the command line.
2018-12-16 21:08:41 +00:00
2022-03-12 14:22:00 +00:00
Most subcommands accept a **-q** or **--quiet** switch, which suppresses the usual output but exits with the documented status. In this case these commands will quit early, without reading all of the available input.
2018-12-16 21:08:41 +00:00
The following subcommands are available.
2020-06-07 18:00:01 +00:00
.. _cmd-string-collect:
2019-06-16 05:30:31 +00:00
"collect" subcommand
--------------------
2019-10-27 09:56:24 +00:00
.. include :: string-collect.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
2019-06-16 05:30:31 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-collect.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
2019-06-16 05:30:31 +00:00
2019-10-27 09:56:24 +00:00
Examples
^^^^^^^^
2019-06-16 05:30:31 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-collect.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2019-06-16 05:30:31 +00:00
2019-03-29 19:05:42 +00:00
"escape" and "unescape" subcommands
-----------------------------------
2019-10-27 09:56:24 +00:00
.. include :: string-escape.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-escape.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
Examples
^^^^^^^^
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-escape.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
"join" and "join0" subcommands
------------------------------
2019-03-29 19:05:42 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-join.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-join.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
Examples
^^^^^^^^
2019-03-29 19:05:42 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-join.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2018-12-16 21:08:41 +00:00
2018-12-19 02:44:30 +00:00
"length" subcommand
2019-01-03 04:10:47 +00:00
-------------------
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-length.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-length.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
Examples
^^^^^^^^
2019-03-29 19:05:42 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-length.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
"lower" subcommand
2019-01-03 04:10:47 +00:00
------------------
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-lower.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
2019-03-29 19:05:42 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-lower.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-lower.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
"match" subcommand
------------------
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-match.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-match.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-match.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2018-12-16 21:08:41 +00:00
2023-04-20 20:17:08 +00:00
"pad" subcommand
----------------
2020-09-27 17:12:42 +00:00
.. include :: string-pad.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
.. include :: string-pad.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
2023-04-20 20:17:08 +00:00
Examples
^^^^^^^^
2020-09-27 17:12:42 +00:00
.. include :: string-pad.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2023-04-20 20:17:08 +00:00
See also
^^^^^^^^
.. include :: string-pad.rst
:start-after: BEGIN SEEALSO
"shorten" subcommand
--------------------
Add string shorten
This is essentially the inverse of `string pad`.
Where that adds characters to get up to the specified width,
this adds an ellipsis to a string if it goes over a specific maximum width.
The char can be given, but defaults to our ellipsis string.
("…" if the locale can handle it and "..." otherwise)
If the ellipsis string is empty, it just truncates.
For arguments given via argv, it goes line-by-line,
because otherwise length makes no sense.
If "--no-newline" is given, it adds an ellipsis instead and removes all subsequent lines.
Like pad and `length --visible`, it goes by visible width,
skipping recognized escape sequences, as those have no influence on width.
The default target width is the shortest of the given widths that is non-zero.
If the ellipsis is already wider than the target width,
we truncate instead. This is safer overall, so we don't e.g. move into a new line.
This is especially important given our default ellipsis might be width 3.
2022-08-16 15:57:19 +00:00
.. include :: string-shorten.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
.. include :: string-shorten.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
2023-04-20 20:17:08 +00:00
Examples
^^^^^^^^
Add string shorten
This is essentially the inverse of `string pad`.
Where that adds characters to get up to the specified width,
this adds an ellipsis to a string if it goes over a specific maximum width.
The char can be given, but defaults to our ellipsis string.
("…" if the locale can handle it and "..." otherwise)
If the ellipsis string is empty, it just truncates.
For arguments given via argv, it goes line-by-line,
because otherwise length makes no sense.
If "--no-newline" is given, it adds an ellipsis instead and removes all subsequent lines.
Like pad and `length --visible`, it goes by visible width,
skipping recognized escape sequences, as those have no influence on width.
The default target width is the shortest of the given widths that is non-zero.
If the ellipsis is already wider than the target width,
we truncate instead. This is safer overall, so we don't e.g. move into a new line.
This is especially important given our default ellipsis might be width 3.
2022-08-16 15:57:19 +00:00
.. include :: string-shorten.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2023-04-20 20:17:08 +00:00
See also
^^^^^^^^
.. include :: string-shorten.rst
:start-after: BEGIN SEEALSO
2018-12-19 02:44:30 +00:00
"repeat" subcommand
2019-01-03 04:10:47 +00:00
-------------------
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-repeat.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
2019-09-17 08:50:52 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-repeat.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
Examples
^^^^^^^^
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-repeat.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2019-03-29 19:05:42 +00:00
2019-10-27 09:56:24 +00:00
"replace" subcommand
--------------------
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-replace.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-replace.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-replace.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2018-12-16 21:08:41 +00:00
2019-05-19 17:40:48 +00:00
.. _cmd-string-split:
.. _cmd-string-split0:
2019-10-27 09:56:24 +00:00
"split" and "split0" subcommands
--------------------------------
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-split.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
2019-09-17 08:50:52 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-split.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
Examples
^^^^^^^^
.. include :: string-split.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2018-12-16 21:08:41 +00:00
2018-12-19 02:44:30 +00:00
"sub" subcommand
2019-01-03 04:10:47 +00:00
----------------
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-sub.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
.. include :: string-sub.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
Examples
^^^^^^^^
2019-09-17 08:50:52 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-sub.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2018-12-16 21:08:41 +00:00
2018-12-19 02:44:30 +00:00
"trim" subcommand
2019-01-03 04:10:47 +00:00
-----------------
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-trim.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
.. include :: string-trim.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
Examples
^^^^^^^^
2019-09-17 08:50:52 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-trim.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2018-12-16 21:08:41 +00:00
2018-12-19 02:44:30 +00:00
"upper" subcommand
2019-01-03 04:10:47 +00:00
------------------
2018-12-16 21:08:41 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-upper.rst
:start-after: BEGIN SYNOPSIS
:end-before: END SYNOPSIS
2019-03-29 19:05:42 +00:00
2019-10-27 09:56:24 +00:00
.. include :: string-upper.rst
:start-after: BEGIN DESCRIPTION
:end-before: END DESCRIPTION
.. include :: string-upper.rst
:start-after: BEGIN EXAMPLES
:end-before: END EXAMPLES
2018-12-16 21:08:41 +00:00
2018-12-19 02:44:30 +00:00
Regular Expressions
2019-01-03 04:10:47 +00:00
-------------------
2018-12-16 21:08:41 +00:00
2022-03-12 14:22:00 +00:00
Both the `` match `` and `` replace `` subcommand support regular expressions when used with the **-r** or **--regex** option. The dialect is that of PCRE2.
2018-12-16 21:08:41 +00:00
2018-12-19 20:02:45 +00:00
In general, special characters are special by default, so `` a+ `` matches one or more "a"s, while `` a\+ `` matches an "a" and then a "+". `` (a+) `` matches one or more "a"s in a capturing group (`` (?:XXXX) `` denotes a non-capturing group). For the replacement parameter of `` replace `` , `` $n `` refers to the n-th group of the match. In the match parameter, `` \n `` (e.g. `` \1 `` ) refers back to groups.
2018-12-16 21:08:41 +00:00
Some features include repetitions:
2019-03-29 19:12:28 +00:00
2018-12-19 20:02:45 +00:00
- `` * `` refers to 0 or more repetitions of the previous expression
- `` + `` 1 or more
- `` ? `` 0 or 1.
- `` {n} `` to exactly n (where n is a number)
- `` {n,m} `` at least n, no more than m.
- `` {n,} `` n or more
2018-12-16 21:08:41 +00:00
Character classes, some of the more important:
2019-03-29 19:12:28 +00:00
2018-12-19 20:02:45 +00:00
- `` . `` any character except newline
- `` \d `` a decimal digit and `` \D `` , not a decimal digit
- `` \s `` whitespace and `` \S `` , not whitespace
- `` \w `` a "word" character and `` \W `` , a "non-word" character
- `` [...] `` (where "..." is some characters) is a character set
- `` [^...] `` is the inverse of the given character set
- `` [x-y] `` is the range of characters from x-y
- `` [[:xxx:]] `` is a named character set
- `` [[:^xxx:]] `` is the inverse of a named character set
- `` [[:alnum:]] `` : "alphanumeric"
- `` [[:alpha:]] `` : "alphabetic"
- `` [[:ascii:]] `` : "0-127"
- `` [[:blank:]] `` : "space or tab"
- `` [[:cntrl:]] `` : "control character"
- `` [[:digit:]] `` : "decimal digit"
- `` [[:graph:]] `` : "printing, excluding space"
- `` [[:lower:]] `` : "lower case letter"
- `` [[:print:]] `` : "printing, including space"
- `` [[:punct:]] `` : "printing, excluding alphanumeric"
- `` [[:space:]] `` : "white space"
- `` [[:upper:]] `` : "upper case letter"
- `` [[:word:]] `` : "same as \w"
- `` [[:xdigit:]] `` : "hexadecimal digit"
2018-12-16 21:08:41 +00:00
Groups:
2019-03-29 19:12:28 +00:00
2018-12-19 20:02:45 +00:00
- `` (...) `` is a capturing group
- `` (?:...) `` is a non-capturing group
- `` \n `` is a backreference (where n is the number of the group, starting with 1)
- `` $n `` is a reference from the replacement expression to a group in the match expression.
2018-12-16 21:08:41 +00:00
And some other things:
2019-03-29 19:12:28 +00:00
2018-12-19 20:02:45 +00:00
- `` \b `` denotes a word boundary, `` \B `` is not a word boundary.
- `` ^ `` is the start of the string or line, `` $ `` the end.
- `` | `` is "alternation", i.e. the "or".
2018-12-16 21:08:41 +00:00
2019-04-02 10:46:23 +00:00
Comparison to other tools
-------------------------
Most operations `` string `` supports can also be done by external tools. Some of these include `` grep `` , `` sed `` and `` cut `` .
If you are familiar with these, it is useful to know how `` string `` differs from them.
In contrast to these classics, `` string `` reads input either from stdin or as arguments. `` string `` also does not deal with files, so it requires redirections to be used with them.
2022-03-12 14:22:00 +00:00
In contrast to `` grep `` , `` string `` 's `` match `` defaults to glob-mode, while `` replace `` defaults to literal matching. If set to regex-mode, they use PCRE regular expressions, which is comparable to `` grep `` 's `` -P `` option. `` match `` defaults to printing just the match, which is like `` grep `` with `` -o `` (use **--entire** to enable grep-like behavior).
2019-04-02 10:46:23 +00:00
2020-10-26 18:19:05 +00:00
Like `` sed `` 's `` s/old/new/ `` command, `` string replace `` still prints strings that don't match. `` sed `` 's `` -n `` in combination with a `` /p `` modifier or command is like `` string replace -f `` .
2019-04-02 10:46:23 +00:00
2020-08-26 16:29:03 +00:00
`` string split somedelimiter `` is a replacement for `` tr somedelimiter \n `` .
