Replace foo/bar with better names in docs (#6156)

Signed-off-by: Ben Sherman <bentshermann@gmail.com>

Author: bentsherman

docs/cache-and-resume.md

@@ -144,19 +144,19 @@ Sometimes a process needs to merge inputs from different sources. Consider the f
 
 ```nextflow
 workflow {
-    ch_foo = channel.of( ['1', '1.foo'], ['2', '2.foo'] )
-    ch_bar = channel.of( ['2', '2.bar'], ['1', '1.bar'] )
-    gather(ch_foo, ch_bar)
+    ch_bam = channel.of( ['1', '1.bam'], ['2', '2.bam'] )
+    ch_bai = channel.of( ['2', '2.bai'], ['1', '1.bai'] )
+    check_bam_bai(ch_bam, ch_bai)
 }
 
-process gather {
+process check_bam_bai {
     input:
-    tuple val(id), file(foo)
-    tuple val(id), file(bar)
+    tuple val(id), file(bam)
+    tuple val(id), file(bai)
 
     script:
     """
-    merge_command $foo $bar
+    check_bam_bai $bam $bai
     """
 }
 ```
@@ -167,18 +167,18 @@ The solution is to explicitly join the two channels before the process invocatio
 
 ```nextflow
 workflow {
-    ch_foo = channel.of( ['1', '1.foo'], ['2', '2.foo'] )
-    ch_bar = channel.of( ['2', '2.bar'], ['1', '1.bar'] )
-    gather(ch_foo.join(ch_bar))
+    ch_bam = channel.of( ['1', '1.bam'], ['2', '2.bam'] )
+    ch_bai = channel.of( ['2', '2.bai'], ['1', '1.bai'] )
+    check_bam_bai(ch_bam.join(ch_bai))
 }
 
-process gather {
+process check_bam_bai {
     input:
-    tuple val(id), file(foo), file(bar)
+    tuple val(id), file(bam), file(bai)
 
     script:
     """
-    merge_command $foo $bar
+    check_bam_bai $bam $bai
     """
 }
 ```

docs/channel.md

@@ -38,7 +38,7 @@ channels if it is invoked with all value channels, including simple values which
 For example:
 
 ```nextflow
-process foo {
+process echo {
   input:
   val x
 
@@ -52,12 +52,12 @@ process foo {
 }
 
 workflow {
-  result = foo(1)
+  result = echo(1)
   result.view { file -> "Result: ${file}" }
 }
 ```
 
-In the above example, since the `foo` process is invoked with a simple value instead of a channel, the input is implicitly
+In the above example, since the `echo` process is invoked with a simple value instead of a channel, the input is implicitly
 wrapped in a value channel, and the output is also emitted as a value channel.
 
 See also: {ref}`process-multiple-input-channels`.

docs/cli.md

@@ -7,7 +7,7 @@ Nextflow provides a robust command line interface (CLI) for the management and e
 Simply run `nextflow` with no options or `nextflow -h` to see the list of available top-level options and commands. See {ref}`cli-reference` for the full list of subcommands with examples.
 
 :::{note}
-Nextflow options use a single dash prefix, e.g. `-foo`. Do not confuse with double dash notation, e.g. `--foo`, which is instead used for {ref}`Pipeline parameters <cli-params>`.
+Nextflow options use a single dash prefix, e.g. `-resume`. Do not confuse with double dash notation, e.g. `--resume`, which is instead used for {ref}`Pipeline parameters <cli-params>`.
 :::
 
 ## Basic usage
@@ -166,22 +166,22 @@ The `-v` option prints out information about Nextflow, such as the version and b
 
 ## Running pipelines
 
-The main purpose of the Nextflow CLI is to run Nextflow pipelines with the `run` command. Nextflow can execute a local script (e.g. `./main.nf`) or a remote project (e.g. `github.com/foo/bar`).
+The main purpose of the Nextflow CLI is to run Nextflow pipelines with the `run` command. Nextflow can execute a local script (e.g. `./main.nf`) or a remote project (e.g. `github.com/nextflow-io/hello`).
 
 ### Launching a remote project
 
 To launch the execution of a pipeline project, hosted in a remote code repository, you simply need to specify its qualified name or the repository URL after the `run` command. The qualified name is formed by two parts: the `owner` name and the `repository` name separated by a `/` character.
 
-In other words if a Nextflow project is hosted, for example, in a GitHub repository at the address `http://github.com/foo/bar`, it can be executed by entering the following command in your shell terminal:
+If a Nextflow project is hosted on GitHub, for example `http://github.com/nextflow-io/hello`, it can be executed by entering the following command in your shell terminal:
 
 ```bash
-nextflow run foo/bar
+nextflow run nextflow-io/hello
 ```
 
 or using the project URL:
 
 ```bash
-nextflow run http://github.com/foo/bar
+nextflow run http://github.com/nextflow-io/hello
 ```
 
 If the project is found, it will be automatically downloaded to the Nextflow home directory (`$HOME/.nextflow` by default) and cached for subsequent runs.
@@ -190,14 +190,6 @@ If the project is found, it will be automatically downloaded to the Nextflow hom
 You must use the `-hub` option to specify the hosting service if your project is hosted on a service other than GitHub, e.g. `-hub bitbucket`. However, the `-hub` option is not required if you use the project URL.
 :::
 
-Try this feature by running the following command:
-
-```bash
-nextflow run nextflow-io/hello
-```
-
-It will download a trivial example from the repository published at [http://github.com/nextflow-io/hello](http://github.com/nextflow-io/hello) and execute it on your computer.
-
 If the `owner` is omitted, Nextflow will search your cached pipelines for a pipeline that matches the name specified. If no pipeline is found, Nextflow will try to download it using the `organization` name defined by the `NXF_ORG` environment variable (`nextflow-io` by default).
 
 :::{tip}
@@ -255,7 +247,7 @@ Parameters that are specified on the command line without a value are set to `tr
 :::
 
 :::{note}
-Parameters that are specified on the command line in kebab case (e.g., `--foo-bar`) are automatically converted to camel case (e.g., `--fooBar`). Because of this, a parameter defined as `fooBar` in the pipeline script can be specified on the command line as `--fooBar` or `--foo-bar`.
+Parameters that are specified on the command line in kebab case (e.g., `--alpha-beta`) are automatically converted to camel case (e.g., `--alphaBeta`). Because of this, a parameter defined as `alphaBeta` in the pipeline script can be specified on the command line as `--alphaBeta` or `--alpha-beta`.
 :::
 
 :::{warning}
@@ -275,22 +267,22 @@ $ nextflow run main.nf -params-file pipeline_params.yml
 The `-params-file` option loads parameters for your Nextflow pipeline from a JSON or YAML file. Parameters defined in the file are equivalent to specifying them directly on the command line. For example, instead of specifying parameters on the command line:
 
 ```console
-$ nextflow run main.nf --alpha 1 --beta foo
+$ nextflow run main.nf --alpha 1 --beta two
 ```
 
 Parameters can be represented in YAML format:
 
 ```yaml
 alpha: 1
-beta: 'foo'
+beta: 'two'
 ```
 
 Or in JSON format:
 
 ```json
 {
   "alpha": 1,
-  "beta": "foo"
+  "beta": "two"
 }
 ```
 

docs/conda.md

@@ -46,7 +46,7 @@ Alternatively, it can be specified by setting the variable `NXF_CONDA_ENABLED=tr
 Conda package names can specified using the `conda` directive. Multiple package names can be specified by separating them with a blank space. For example:
 
 ```nextflow
-process foo {
+process hello {
   conda 'bwa samtools multiqc'
 
   script:
@@ -82,7 +82,7 @@ Read the Conda documentation for more details about how to create [environment f
 The path of an environment file can be specified using the `conda` directive:
 
 ```nextflow
-process foo {
+process hello {
   conda '/some/path/my-env.yaml'
 
   script:
@@ -174,7 +174,7 @@ Conda lock files must be a text file with the `.txt` extension.
 If you already have a local Conda environment, you can use it in your workflow specifying the installation directory of such environment by using the `conda` directive:
 
 ```nextflow
-process foo {
+process hello {
   conda '/path/to/an/existing/env/directory'
 
   script:

docs/config.md

@@ -84,7 +84,7 @@ process.executor = 'sge'
 process.queue = 'long'
 process.memory = '10G'
 
-includeConfig 'path/foo.config'
+includeConfig 'path/extra.config'
 ```
 
 Relative paths are resolved against the location of the including file.
@@ -185,7 +185,7 @@ process {
 
 The `withName` selector applies both to processes defined with the same name and processes included under the same alias. For example, `withName: hello` will apply to any process originally defined as `hello`, as well as any process included under the alias `hello`.
 
-Furthermore, selectors for the alias of an included process take priority over selectors for the original name of the process. For example, given a process defined as `foo` and included as `bar`, the selectors `withName: foo` and `withName: bar` will both be applied to the process, with the second selector taking priority over the first.
+Furthermore, selectors for the alias of an included process take priority over selectors for the original name of the process. For example, given a process defined as `hello` and included as `sayHello`, the selectors `withName: hello` and `withName: sayHello` will both be applied to the process, with the second selector taking priority over the first.
 
 :::{tip}
 Label and process names do not need to be enclosed with quotes, provided the name does not include special characters (`-`, `!`, etc) and is not a keyword or a built-in type identifier. When in doubt, you can enclose the label name or process name with single or double quotes.
@@ -199,26 +199,26 @@ Both label and process name selectors allow the use of a regular expression in o
 
 ```groovy
 process {
-    withLabel: 'foo|bar' {
+    withLabel: 'hello|bye' {
         cpus = 2
         memory = 4.GB
     }
 }
 ```
 
-The above configuration snippet requests 2 cpus and 4 GB of memory for processes labeled as `foo` or `bar`.
+The above configuration snippet requests 2 cpus and 4 GB of memory for processes labeled as `hello` or `bye`.
 
 A process selector can be negated prefixing it with the special character `!`. For example:
 
 ```groovy
 process {
-    withLabel: 'foo' { cpus = 2 }
-    withLabel: '!foo' { cpus = 4 }
+    withLabel: 'hello' { cpus = 2 }
+    withLabel: '!hello' { cpus = 4 }
     withName: '!align.*' { queue = 'long' }
 }
 ```
 
-The above configuration snippet sets 2 cpus for the processes annotated with the `foo` label and 4 cpus to all processes *not* annotated with that label. Finally it sets the use of `long` queue to all process whose name does *not* start with `align`.
+The above configuration snippet sets 2 cpus for every process labeled as `hello` and 4 cpus to every process *not* label as `hello`. It also specifies the `long` queue for every process whose name does *not* start with `align`.
 
 (config-selector-priority)=
 
@@ -238,17 +238,17 @@ For example:
 ```groovy
 process {
     cpus = 4
-    withLabel: foo { cpus = 8 }
-    withName: bar { cpus = 16 }
-    withName: 'baz:bar' { cpus = 32 }
+    withLabel: hello { cpus = 8 }
+    withName: bye { cpus = 16 }
+    withName: 'mysub:bye' { cpus = 32 }
 }
 ```
 
 With the above configuration:
 - All processes will use 4 cpus (unless otherwise specified in their process definition).
-- Processes annotated with the `foo` label will use 8 cpus.
-- Any process named `bar` (or imported as `bar`) will use 16 cpus.
-- Any process named `bar` (or imported as `bar`) invoked by a workflow named `baz` with use 32 cpus.
+- Processes annotated with the `hello` label will use 8 cpus.
+- Any process named `bye` (or imported as `bye`) will use 16 cpus.
+- Any process named `bye` (or imported as `bye`) invoked by a workflow named `mysub` with use 32 cpus.
 
 (config-profiles)=
 
@@ -297,7 +297,7 @@ When defining a profile in the config file, avoid using both the dot and block s
 
 ```groovy
 profiles {
-    foo {
+    cluster {
         process.memory = '2 GB'
         process {
             cpus = 2
@@ -309,7 +309,7 @@ profiles {
 Due to a limitation of the legacy config parser, the first setting will be overwritten by the second:
 
 ```console
-$ nextflow config -profile foo
+$ nextflow config -profile cluster
 process {
    cpus = 2
 }