|
183 | 183 |
|
184 | 184 | The value of `position` is used to determine where parameter should |
185 | 185 | appear on the command line. Positions are relative to one another, not |
186 | | - abosolute. As a result, positions do not have to be sequential, three |
| 186 | + absolute. As a result, positions do not have to be sequential, three |
187 | 187 | parameters with positions `[1, 3, 5]` will result in the same command |
188 | 188 | line as `[1, 2, 3]`. More than one parameter can have the same position |
189 | 189 | (ties are broken using the parameter name), and the position field itself |
|
290 | 290 | - | |
291 | 291 | ## Parameter references |
292 | 292 |
|
293 | | - In a previous example, we used extracted a file using the "tar" program. |
294 | | - However, that example was very limited becuase it assumed that the file |
| 293 | + In a previous example, we extracted a file using the "tar" program. |
| 294 | + However, that example was very limited because it assumed that the file |
295 | 295 | we were interested in was called "hello.txt". In this example, you will |
296 | 296 | see how to reference the value of input parameters dynamically from other |
297 | 297 | fields. |
|
356 | 356 | containers are also purposefully isolated from the host system, so in |
357 | 357 | order to run a tool inside a Docker container there is additional work to |
358 | 358 | ensure that input files are available inside the container and output |
359 | | - files can be recovered from the contianer. CWL can perform this work |
| 359 | + files can be recovered from the container. CWL can perform this work |
360 | 360 | automatically, allowing you to use Docker to simplify your software |
361 | 361 | management while avoiding the complexity of invoking and managing Docker |
362 | 362 | containers. |
|
466 | 466 | tool is actually executed. The `$(runtime.outdir)` parameter is the path |
467 | 467 | to the designated output directory. Other parameters include |
468 | 468 | `$(runtime.tmpdir)`, `$(runtime.ram)`, `$(runtime.cores)`, |
469 | | - `$(runtime.ram)`, `$(runtime.outdirSize)`, and `$(runtime.tmpdirSize)`. See |
| 469 | + `$(runtime.outdirSize)`, and `$(runtime.tmpdirSize)`. See |
470 | 470 | the [Runtime Environment](CommandLineTool.html#Runtime_environment) |
471 | 471 | section of the CWL specification for details. |
472 | 472 |
|
|
522 | 522 | - | |
523 | 523 | ``` |
524 | 524 |
|
525 | | - *array-outpust-job.yml* |
| 525 | + *array-outputs-job.yml* |
526 | 526 | ``` |
527 | 527 | - $include: examples/array-outputs-job.yml |
528 | 528 | - | |
|
662 | 662 | - | |
663 | 663 | ``` |
664 | 664 |
|
| 665 | + As this tool does not require any `inputs` we can run it with an (almost) empty job file: |
| 666 | +
|
| 667 | + *empty.yml* |
| 668 | + ``` |
| 669 | + {} |
| 670 | + | |
| 671 | + ``` |
| 672 | +
|
| 673 | + We can then run `expression.cwl`: |
| 674 | +
|
665 | 675 | ``` |
666 | 676 | $ cwl-runner expression.cwl empty.yml |
667 | 677 | [job 140000594593168] /home/example$ echo -A 2 -B baz -C 10 9 8 7 6 5 4 3 2 1 |
|
796 | 806 | class: Workflow |
797 | 807 | ``` |
798 | 808 |
|
799 | | - The 'cwlVersion` field indicates the version of the CWL spec used by the |
| 809 | + The `cwlVersion` field indicates the version of the CWL spec used by the |
800 | 810 | document. The `class` field indicates this document describes a workflow. |
801 | 811 |
|
802 | 812 |
|
|
820 | 830 |
|
821 | 831 | The `outputs` section describes the outputs of the workflow. This is a |
822 | 832 | list of output parameters where each parameter consists of an identifier |
823 | | - and a data type. The `source` connects the output parameter `classfile` |
| 833 | + and a data type. The `outputSource` connects the output parameter `classfile` |
824 | 834 | of the `compile` step to the workflow output parameter `classout`. |
825 | 835 |
|
826 | 836 | ``` |
|
0 commit comments