Fix: tolerate special bash characters in $NXF_TASK_WORKDIR

[TheLostLambda]

Prior to this commit, selecting a workDir with spaces or other special Bash characters in the pathname — like (, ), etc — would result in cd $NXF_TASK_WORKDIR failing. Now $NXF_TASK_WORKDIR is correctly quoted in the generated .output.run scripts.

I just got into Nextflow yesterday, and this is my first time touching Groovy code, so let me know if you'd like to see this fix implemented in some other way!

[netlify]

✅ Deploy Preview for nextflow-docs-staging canceled.

Name	Link
🔨 Latest commit	4609ee2
🔍 Latest deploy log	https://app.netlify.com/projects/nextflow-docs-staging/deploys/693bfbfacbca160008015ee8

[jorgee]

Is this PR linked to an issue? Or could you provide more info about the case that this PR fixes? I was trying to validate the changes with a failing case but I couldn't find it.

I run a pipeline with Singularity and a work dir with spaces and it is not failing with the latest releases. All the task outputs are correctly stored in the work dir.

NXF_VER=25.10.0 nextflow run nextflow-io/rnaseq-nf -profile singularity -w "Task,wd 2"
Nextflow 25.10.2 is available - Please consider updating your version to it

N E X T F L O W   ~  version 25.10.0

NOTE: Your local project version looks outdated - a different revision is available in the remote repository [ca20a6dfd2]
Launching `https://github.com/nextflow-io/rnaseq-nf` [evil_faraday] DSL2 - revision: 86165b8c81 [master]

  R N A S E Q - N F   P I P E L I N E
  ===================================
  transcriptome: /home/jorgee/.nextflow/assets/nextflow-io/rnaseq-nf/data/ggal/ggal_1_48850000_49020000.Ggal71.500bpflank.fa
  reads        : /home/jorgee/.nextflow/assets/nextflow-io/rnaseq-nf/data/ggal/ggal_gut_{1,2}.fq
  outdir       : results
  
executor >  local (4)
[49/2d256a] RNASEQ:INDEX (ggal_1_48850000_49020000) [100%] 1 of 1 ✔
[49/671146] RNASEQ:FASTQC (FASTQC on ggal_gut)      [100%] 1 of 1 ✔
[25/e741fb] RNASEQ:QUANT (ggal_gut)                 [100%] 1 of 1 ✔
[d4/e62042] MULTIQC                                 [100%] 1 of 1 ✔

[TheLostLambda]

Hi @jorgee !

I'll try to replicate this issue with the latest commit of Nextflow today! I don't believe it's tied to an issue — I think (at the time) a PR seemed like the fastest way to fix it!

[TheLostLambda]

For @jorgee , with spaces and containers, this issue seems to often be silent, with /bin/bash: line 1: cd: too many arguments appearing in .command.err, but it seems like parentheses blow things up properly:

I'll re-check that's still the case with the latest master and will check that my PR definitely still fixes that!

EDIT: I've confirmed that the issue still exists on 55f6ff5, but it's fixed by 8d3692a !

[jorgee]

I have replicated the problem with parentheses. I tested with local, docker and singularity. It is only failing with singularity and the PR fixes it

[jorgee]

Changes are fine to me. Just adding missing "" in the command and entrypoint definition for the singularity case. I have replicated the issue and checked the PR fixes it.