Update text after modifying bin documentation

Signed-off-by: Christopher Hakkaart <[email protected]>

Author: christopher-hakkaart

docs/module.md

@@ -260,7 +260,7 @@ To use this feature, the module binaries must be enabled in your pipeline script
 nextflow.enable.moduleBinaries = true
 ```
 
-Binary scripts must be placed in the module directory named `<module-dir>/resources/usr/bin` and granted execution permissions:
+Binary scripts must be placed in the module directory named `<module-dir>/resources/usr/bin` and granted execution permissions. For example:
 
 ```
 <module-dir>
@@ -276,6 +276,8 @@ Binary scripts must be placed in the module directory named `<module-dir>/resour
 Module binary scripts require a local or shared file system for the pipeline work directory, or {ref}`wave-page` when using cloud-based executors.
 :::
 
+Scripts can also be stored at the pipeline level using the `bin` directory. See {ref}`bin directory <bundling-executable>` for more information. 
+
 ## Sharing modules
 
 Modules are designed to be easy to share and re-use across different pipelines, which helps eliminate duplicate work and spread improvements throughout the community. While Nextflow does not provide an explicit mechanism for sharing modules, there are several ways to do it:

docs/process.md

@@ -178,7 +178,7 @@ workflow {
 
 By default, Nextflow looks for template scripts in the `templates` directory, located alongside the Nextflow script that defines the process. A template can be reused across multiple processes. An absolute path can be used to specify a different template location. However, this practice is discouraged because it hinders pipeline portability. 
 
-Templates can be tested independently of pipeline execution. Consider the following template script:
+Templates can be tested independently of pipeline execution. However, variables prefixed with the dollar character (`$`) are interpreted as Nextflow variables when the template script is executed by Nextflow and Bash variables when executed directly. Consider the following template script:
 
 ```bash
 #!/bin/bash
@@ -187,24 +187,18 @@ echo $STR
 echo "process completed"
 ```
 
-The above script can be executed from the command line by providing each input as an environment variable.
+The above script can be executed from the command line by providing each input as an environment variable:
 
 ```bash
 STR='foo' bash templates/my_script.sh
 ```
 
-Variables prefixed with the dollar character (`$`) are interpreted as Nextflow variables when the template script is executed by Nextflow and Bash variables when executed directly.
-
-The following caveats should be considered when using templates:
+Several caveats should be considered when using templates:
 
 - Template scripts are only recommended for Bash scripts.
-
 - Languages that do not prefix variables with `$` (e.g. Python and R) can't be executed directly as a template script from the command line.
-
 - Template variables escaped with `\$` will be interpreted as Bash variables when executed by Nextflow but not the command line.
-
 - Template variables are evaluated even if they are commented out in the template script.
-
 - The pipeline to fail if a template variable is missing, regardless of where it occurs in the template.
 
 :::{tip}

docs/sharing.md

@@ -97,23 +97,27 @@ For maximal reproducibility, make sure to define a specific version for each too
 
 #### The `bin` directory
 
-As for custom scripts, you can include executable scripts in the `bin` directory of your pipeline repository. When configured correctly, these scripts can be executed like a regular command from any process script (i.e. without modifying the `PATH` environment variable or using an absolute path), and changing the script will cause the task to be re-executed on a resumed run (i.e. just like changing the process script itself).
+Executable scripts can be included in the pipeline `bin` directory located at the root of your pipeline directory. This allows you to create and organize custom scripts that can be invoked like regular commands from any process in your pipeline without modifying the `PATH` environment variable or using an absolute path. For example:
 
-To configure a custom script:
+```
+├── bin
+│   └── custom_script.py
+└── main.nf
+```
 
-1. Save the script in the `bin` directory (relative to the pipeline repository root).
-2. Specify a portable shebang (see note below for details).
-3. Make the script executable. For example: `chmod a+x bin/my_script.py`
+Each script should include a shebang line to specify the interpreter for the script. To maximize portability, use `env` to dynamically resolve the interpreter's location instead of hard-coding the interpreter path.
 
-:::{tip}
-To maximize the portability of your bundled script, use `env` to dynamically resolve the location of the interpreter instead of hard-coding it in the shebang line.
+For example, the shebang definitions `#!/usr/bin/python` and `#!/usr/local/bin/python` hard-code specific paths to the Python interpreter. Use `#!/usr/bin/env python` instead.
 
-For example, shebang definitions `#!/usr/bin/python` and `#!/usr/local/bin/python` both hard-code specific paths to the Python interpreter. Instead, the following approach is more portable:
+Scripts placed in the `bin` directory must have executable permissions. Use the `chmod` command to grant the required permissions. For example:
 
-```bash
-#!/usr/bin/env python
 ```
-:::
+chmod a+x bin/custom_script.py
+```
+
+After setting the executable permission, the script can be run directly within your pipeline processes.
+
+Executable scripts can also be stored as scripts that are locally scoped to the processes defined by the tasks. See {ref}`module-binaries` for more information.
 
 #### The `lib` directory