Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to deal with Regex comparisons #49

Open
VasLem opened this issue Oct 31, 2024 · 5 comments · May be fixed by #51
Open

How to deal with Regex comparisons #49

VasLem opened this issue Oct 31, 2024 · 5 comments · May be fixed by #51

Comments

@VasLem
Copy link

VasLem commented Oct 31, 2024

So I have this regex written in Groovy, that gets all the FASTA files from a directory:

output = file(sample_dir).listFiles().findAll{ it.getName() =~ /${sample_name}.*\.f(?:ast)?[qa](?:\.gz)?/ }

Nextflow server complains about the slashy part, probably that is not supported, as described here . How am I supposed to write this Regex in a non slashy way?

@bentsherman
Copy link
Member

Looking at the rules for slashy strings in Groovy, you might be able to simply replace the slashes with double quotes, but I'm not sure. If other things need to be escaped it could get quite ugly.

Can you try with double quotes and let me know if it works? Meanwhile I will do some testing. I might be able to preserve support for this kind of slashy string, especially if it is more convenient than the double-quoted string

@pditommaso
Copy link
Member

What's the rationale to not supporting slashy string with variable interpolation?

@bentsherman
Copy link
Member

I think early on I was concerned that it would be too complicated to support, but on further review I don't think that should be an issue

However I would like to review the exact advantages it provides over a double-quoted string. I'm concerned about having too many different kinds of strings and confusing people

@pditommaso
Copy link
Member

Slashy strings are useful because there is no need to escape backslashes when writing regex and patterns. If we remove shell: it may be useful to keep slashy strings

@bentsherman bentsherman linked a pull request Nov 4, 2024 that will close this issue
1 task
@bentsherman bentsherman added this to the v1.0.2 milestone Nov 15, 2024
@bentsherman
Copy link
Member

@VasLem to replace the slashy string with double quotes, I think you only need to escape the backslashes. Here is a minimal example that you can test:

sample_id = 'SRA001'
files = [
    'SRA001.fastq'      : true,
    'SRA001.fastq.gz'   : true,
    'SRA001.fq'         : true,
    'SRA001.fq.gz'      : true,
    'SRA001.fasta'      : true,
    'SRA001.fasta.gz'   : true,
    'SRA001.fa'         : true,
    'SRA001.fa.gz'      : true,
    'SRA002.fa.gz'      : false,
]

files.each { file, result ->
    assert result == !!(file =~ /${sample_id}.*\.f(?:ast)?[qa](?:\.gz)?/)
    assert result == !!(file =~ "${sample_id}.*\\.f(?:ast)?[qa](?:\\.gz)?")
}

So that should solve your immediate problem with the language server.

I am testing support for dynamic slashy strings in #51 but it is not working yet. If the only advantage of slashy string is not escaping backslashes, I'm not sure it's worth supporting. Also I don't see how it's related to the shell block

@bentsherman bentsherman removed this from the v1.0.2 milestone Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants