summaryrefslogtreecommitdiff
path: root/docs/MANPAGE_SYNTAX.md
diff options
context:
space:
mode:
authorOpenShift Merge Robot <openshift-merge-robot@users.noreply.github.com>2021-06-07 21:09:51 +0200
committerGitHub <noreply@github.com>2021-06-07 21:09:51 +0200
commit4f81bc2bc8f672bd27c73f336a0ab77424cc08fe (patch)
tree56f7a512ab68a80966087d68e2c57f6e385e3376 /docs/MANPAGE_SYNTAX.md
parent763abaea36ad289a887a0b61d52dcc8d3bea84d8 (diff)
parentab7e7f651e71556d879421cb3680f9762b0a77d2 (diff)
downloadpodman-4f81bc2bc8f672bd27c73f336a0ab77424cc08fe.tar.gz
podman-4f81bc2bc8f672bd27c73f336a0ab77424cc08fe.tar.bz2
podman-4f81bc2bc8f672bd27c73f336a0ab77424cc08fe.zip
Merge pull request #10526 from Procyhon/31052021_manpage
[CI:DOCS] UPDATE MANPAGE_SYNTAX (commit,attach,auto-update)
Diffstat (limited to 'docs/MANPAGE_SYNTAX.md')
-rw-r--r--docs/MANPAGE_SYNTAX.md59
1 files changed, 38 insertions, 21 deletions
diff --git a/docs/MANPAGE_SYNTAX.md b/docs/MANPAGE_SYNTAX.md
index 436ec5e8d..c9b677688 100644
--- a/docs/MANPAGE_SYNTAX.md
+++ b/docs/MANPAGE_SYNTAX.md
@@ -10,7 +10,7 @@ podman\-command - short description
**podman subcommand command** [*optional*] *mandatory value*
-(If there is the possibility to chose between 2 (two) or more mandatory command values. There should also always be a space before and after a vertical bar to ensure better readability.)
+(If there is the possibility to chose between two or more mandatory command values. There should also always be a space before and after a vertical bar to ensure better readability.)
**podman command** [*optional*] *value1* | *value2*
@@ -29,51 +29,68 @@ podman\-command - short description
**podman subcommand command** [*optional*] *value* [*value* ...]
## DESCRIPTION
-**podman command** is always the beginning of the DESCRIPTION section. Putting the command as the first part of the DESCRIPTION ensures uniformity. All commands mentioned in a text retain their appearance and form.\
-Example sentence: The command **podman command** is an example command.\
-It should also be specified if the command can only be run as root. In addition, it should be described when a command or OPTION cannot be executed with the remote client. For a command, this should be done in the DESCRIPTION part. For the OPTIONS, it should be done in the DESCRIPTION of the specified OPTION. Do not use pronouns in the man pages, especially the word `you`.
+**podman command** is always the beginning of the DESCRIPTION section. Putting the command as the first part of the DESCRIPTION ensures uniformity. All commands mentioned in the text retain their appearance and form.\
+Example sentence: The command **podman command** is an example command.
+
+Commands or files that are quoted from other podman manpages or podman repositories have to be linked to those. Non-podman commands are not to be linked.\
+Example sentence: You can use **[podman-run](podman-run.1.md)** or **[containers.conf(5)](https://github.com/containers/common/blob/master/docs/containers.conf.5.md)** for the problem.
+
+It should also be specified if the command can only be run as root. In addition, it should be described when a command, OPTION, or other content cannot be executed with the remote client or in combination with other commands, OPTIONS, or content. In this case, the following sentence is put at the end of a command, OPTION, or content: *IMPORTANT: This option/command/other is not available with the command/OPTION/content/remote Podman client*. For a command, this should be done in the DESCRIPTION section. For the OPTIONS, it should be done in the DESCRIPTION of the specified OPTION. Do not use pronouns in the man pages, especially the word `you`.
## OPTIONS
-All flags are referred to as OPTIONS. The term flags should not be used. All OPTIONS are listed in this section. OPTIONS that appear in descriptions of other OPTIONS and sections retain their appearance, for example: **--exit**. Each OPTION should be explained to the fullest extend below the OPTION itself. Each OPTION is behind an H4-header (`####`).
+All flags are referred to as OPTIONS. The term flags should not be used. All OPTIONS are listed in this section. OPTIONS that appear in descriptions of other OPTIONS and sections retain their appearance, for example: **--exit**.
+
+OPTIONS that are quoted from other podman manpages or podman repositories have to be linked to those.\
+Example sentence: You can use **[podman-generate-systemd --new](podman-generate-systemd.1.md#--new)** for the problem.
+
+ Each OPTION should be explained to the fullest extent below the OPTION itself. Each OPTION is behind an H4-header (`####`). If the OPTION has a default argument, it has to be explained in the description of the OPTION. If the OPTION is also not available with the remote client, the sentence about the default argument should the second to last sentence.
+
-#### **--option**, **-o**
+#### **--version**, **-v**
-OPTIONS can be put after the command in two different ways. Eather the long version with **--option** or as the short version **-o**. If there are two ways to write an OPTION they are separated by a comma. If there are 2 (two) versions of one command the long version is always shown in front.
+OPTIONS can be put after the command in two different ways. Eather the long version with **--option** or as the short version **-o**. If there are two ways to write an OPTION they are separated by a comma. If there are two versions of one command the long version is always shown in front.\
+Example: The default is **false**. *IMPORTANT: This option is not available with the remote Podman client*.
#### **--exit**
An example of an OPTION that has only one possible structure. Thus, it cannot be executed by the extension **-e**.
-#### **--answer**=, **-a**=**_active_** | *disable*
+#### **--answer**=, **-a**=**active** | *disable*
-OPTIONS that accept 2 possible arguments as inputs are shown above. If there is a default argument that is selected when no special input is made, it is shown in **_bold italics_**. It must always be ensured that the standard argument is in the first place after the OPTION. In this example, there are 2 (two) different versions to execute the command. Both versions of the OPTION have to be shown with the arguments behind them.
+The "answer" option above is an example of an OPTION that accepts two possible arguments as inputs. If there is a default argument that is selected when the OPTION is not used in the command, it is shown in **bold**. If the OPTION is used it must include an argument afterwards. It must always be ensured that the standard argument is in the first position after the OPTION. In this example, there are two different ways to execute the command. Both possible OPTIONS have to be shown with the arguments following them. The default value is shown as **active**.
#### **--status**=**good** | *better* | *best*
-This is an example for 3 (three) arguments behind an OPTION. If the number of arguments is higher than 3 (three), the arguments are **not** listed after the equal sign. The arguments have to be explained in a table like in **--test**=**_test_** regardless of the number of arguments.
+This is an example of three arguments following an OPTION. If the number of arguments is greater than three, the arguments are **not** listed after the equal sign. The arguments have to be shown in a table like in **--test**=**_test_**, regardless of the number of arguments. The default value is shown as **good**.
-#### **--test**=**_test_**
+#### **--test**=**test**
-OPTIONS that are followed by an equal sign include an argument after the equal sign in *italic*. If there is a default argument, that is used if the OPTION is not specified in the **command**, the argument after the eqaul sign is displayed in **bold**. All arguments must be listed and explained in the text below the OPTION.
+OPTIONS that are followed by an equal sign include an argument after the equal sign in **bold**. If there is a default argument, that is used if the OPTION is not specified in the command, the argument after the eqaul sign is displayed in **bold**. All arguments must be listed and explained in the text below the OPTION.
| Argument | Description |
-| - | - |
-| **_example one_** | This argument is the standard argument if the OPTION is not specified. |
+| ------------------ | --------------------------------------------------------------------------- |
+| **example one** | This argument is the default argument if the OPTION is not specified. |
| *example two* | If one refers to a command, one should use **bold** marks. |
-| *example three* | Example: In combination with **podman command** highly effective. |
+| *example three* | Example: In combination with **podman command** highly effective. |
| *example four* | Example: Can be combined with **--exit**. |
| *example five* | The fifth description |
-The table shows an example for a listing of arguments. The contents in the table should be aligned left. If the content in the table conflicts with this, it can be aligned in a way that supports the understanding of the content. If there is a standard argument, it **must** listed as the first entry in the table.
+The table shows an example for a listing of arguments. The contents in the table should be aligned left. If the content in the table conflicts with this, it can be aligned in a way that supports the understanding of the content. If there is a default argument, it **must** listed as the first entry in the table. The default value is shown as **example one**.
-If the number of arguments is smaller than 4 (four) they have to be listed behind the OPTION as seen in the OPTION **--status**.
+
+If the number of arguments is smaller than four they have to be listed behind the OPTION as seen in the OPTION **--status**.
+
+#### **--problem**=*problem*
+
+OPTIONS that are followed by an equal sign that is then followed by an unspecified argument, have no default argument. If this OPTION is written with an equal sign and the argument is left empty, there will be no error, but the OPTION will be ignored. The meaning of the argument is described preferably in `one` word after the equal sign in *italic* format.
## SUBCHAPTER
For chapters that are made specifically as an individual SUBCHAPTER in a man page, the previous conditions regarding formatting apply.
There are no restrictions for the use of paragraphs and tables. Within these paragraphs and tables the previous conditions regarding formatting apply.
-Strings of characters or numbers can be highlighted with `backticks`. Paths of any kind **must** be highlighted.\
+Strings of characters or numbers can be highlighted with `backticks`. Paths of any kind **must** be highlighted.
+
IMPORTANT: Only characters that are **not** part of categories mentioned before can be highlighted. This includes headers. For example it is not advised to highlight an OPTION or a **command**.
SUBHEADINGS are displayed as follows:
@@ -81,9 +98,9 @@ SUBHEADINGS are displayed as follows:
Text for SUBHEADINGS.
## EXAMPLES
-All EXAMPLES are listed in this section. This section should be at the end of each man page. Each EXAMPLE is always in one box. The box starts and ends with the last written line, **not** with a blank line. The `$` in front of the commands indicates that it can be run as a normal user, while the commands starting with `#` can only be run as root.
+All EXAMPLES are listed in this section. This section should be at the end of each man page. Each EXAMPLE is always in one box. The box starts and ends with the last written line, **not** with a blank line. The `$` in front of the commands indicates that it can be run as a normal user, while the commands starting with `#` can only be run as root. If there is the need for a comment in a box the comment should have `###` in front of it.
-### Description of the EXAMPLE
+Description of the EXAMPLE
```
$ podman command
@@ -92,7 +109,7 @@ $ podman command -o
$ cat $HOME/Dockerfile | podman command --option
```
-### Description of the EXAMPLE 2
+Description of the EXAMPLE two
```
$ podman command --redhat