Ah this is much more useful, for a minimal reproducible example, the reproducible part is more important than the minimal bit (although this is important too).
Part 1 - Shell Expansion
For a bit of background information, an asterisk on the command-line is actually a shell expansion. Having a look at WGLab/LongReadSum, this is why it asks for the pattern in quotes. If there are no quotes, then the arguments are ‘expanded’ prior to being parsed to the tool itself. If the files foo.fastq.gz and bar.fastq.gz were inside the directory ../data/input/, then the command line would be expanded to longreadsum -P ../data/input/foo.fastq.gz ../data/input/bar.fastq.gz. And the arguments provided to the tool would be
[
"-P",
"../data/input/foo.fastq.gz",
"../data/input/bar.fastq.gz"
]
Instead, by using double quotes, the tool then takes in ../data/input/*.fastq.gz as a single argument and I believe does it’s own shell expansion internally, (and so the arguments provided to the tool would be:
```json
[
"-P",
"../data/input/*.fastq.gz",
]
Therefore:
- Don’t use shellquote: false, you don’t actually want a shell expansion here, you just want the pattern for shell expansion
- Don’t quote in the input i.e
pattern_input: ../data/input/"*.fastq.gz" should just be pattern_input: ../data/input/*.fastq.gz. Even though CWL will wrap the arguments in single quotes, what is parsed to the tool is the same as it would be for double quotes. However if you have double quotes in the input variable then the literal " is parsed since it’s inside the single quotes, which is not what the tool wants. The tool readme just tells you to enclose the pattern in quotes since you don’t want to expand the command prior to running the tool. The readme also uses double quotes since single quotes won’t evaluate variables before parsing the arguments to the tool.
Part 2 - Containerisation
This is the more pressing bit
The pattern command is engaged as both as a string and a File[] or Directory type.
Given you’re running this in docker, neither of the following inputs will mount ../data/input into the container, so longreadsum won’t be able to see the files in ../data/input anyway
In summary the inputs below will not mount a directory
input_type: fq
pattern_input: ../data/input/"*.fastq.gz"
Adding in a directory will also not help
input_type: fq
pattern_input: ../data/input/"*.fastq.gz"
pattern_folder:
type: Directory
location: ../data/input/
will likely mount the files in …/data/input under something like /data/cwl/mounts/, not ../data/input so the pattern_input will not know where they are.
You have two options:
- Scrap pattern_inputs and pattern_directory and instead go with the
--inputs parameter, and use a list of files. You can use the itemSeparator key in inputBinding to separate each input by a comma as per the longreadsum readme. This would mean specifying each file which might be cumbersome but also means you can specify files that aren’t necessarily in the same folder. You can use the [] syntax to specify an array
inputs:
...
input_file_list:
label: List of input files
type: File[]
inputBinding:
prefix: "--inputs"
itemSeparator: ","
separate: False
- You could use the ‘arguments’ tab to combine the pattern_directory and pattern_inputs parameters, this would change the behaviour of the tool a little as the pattern_inputs would need to only use the suffix and one could stitch the two together.
i.e
arguments:
- prefix: -P
- valueFrom: |
${
if (inputs.pattern_directory != null && inputs.pattern != null) {
return inputs.pattern_directory.path + inputs.pattern;
} else {
return null
}
};
And then remove the input binding from the pattern_folder and pattern_input parameters.
The input form would then look something like this:
inputs:
...
pattern_folder:
type: Directory?
label: pattern directory
doc: Directory containing input
pattern_input:
type: string?
label: pattern input
doc: Use pattern matching (*) to specify multiple input files. Enclose the pattern in double quotes.
Personally I think the first one is cleaner and more flexible.