https://nf-co.re logo
Join Slack
Powered by
Get ready for TWO potentially annoying/sticky ques...
# team-maintainers
j
Get ready for TWO potentially annoying/sticky questions for the hive mind.... I'll start with the first one: A user of #C031QH57DSS has the following setup: • Windows computer running WSL2 • Storage is a NAS, mounted via CIFS • Work directory must go on NAS When they get to the bowtie2 step, the process crashes, because the common 
find
command pattern we have for picking up index files (
find -L ./ -name "*.rev.1.bt2" | sed "s/\.rev.1.bt2$//"
), fails, because apparently 
find
cannot follow symlinks to the CIFS mounted NAS. The very kindly did some upfront experimentation, and found out if they replace the pattern to use 
ls
, it makes the process happy, in the sense that 
ls
doesn't have an issue picking up the path (I guess as it takes the found file at face value).
Copy code
INDEX=\$(ls -1 bowtie2/*.rev.1.bt2 2>/dev/null | sed 's/\\.rev\\.1\\.bt2\$//')
So question: does anyone see any drawback to switching the pattern to help support a WSL2/CIFS/NAS user? And if so, should we replace all the pattern across the at least 33 tools using it: https://github.com/search?q=repo%3Anf-core%2Fmodules%20%60find%20-L&type=code
m
Is the Groovy way an alternative, e.g. using the 
bowtie2_dir.listFiles()
?
party this 1
j
Also an option!
j
I like the idea of doing it Groovily, but we should be careful to write it in a way that handles both providing the index as a directory, or as a direct list of index files
j
I think that's maybe the tricky bit, yes
(wuthout it getting too convoluted, which is I believe why we went with the bash solution originally)
j
And we should also check that Groovy can traverse this file system properly 🫢
this 1
j
Could do, my assumption was groovy would also take whatever is at the top level
(like 
ls
)
m
> I like the idea of doing it Groovily, but we should be careful to write it in a way that handles both providing the index as a directory, or as a direct list of index files I'm not quite clear what this means. A pipeline developer would either supply a folder path, or a list of files right. Only one of those would be expected as the input. And depending on what's input, the solution would reflect that. What am I missing?
j
The way the e.g. bwamem2/align module is written, you could pass both 
[meta, /path/to/index/dir]
or 
[meta, [index1.ext, index1.ext2]]
into the module, and both should work because the 
find
command just searches for a file with the correct extension - the module itself doesn't enforce any specific requirements on what you pass in as an index. While our bwamem2/index outputs a directory containing an index, there's no guarantee a pipeline will follow that schema (maybe there's another module, for example, that outputs a list of files, or they're read in from user input), and the module is currently flexible enough to handle both. So we either need to enforce one input type, or handle both input types with Groovy?
m
Ah, ok. Now I understand. I didn't realise there were modules that could take both.
j
Could we use 
task.workDir
? 🤔
INDEX=${task.workDir.listFiles().findAll{it.name.endsWith(".rev.1.bt2")}.first().toString() - ".rev.1.bt2"}
?
Although at this point the 
ls -1
method is much more concnise
What is the donwside of using 
ls
though here?
j
does 
.listFiles()
follow links? Would you not just want to check the index channel in any case?
Copy code
index_files = reference.isDirectory() ? reference.listFiles() : reference
index_input = index_files.findAll { ... }... blah
What is the donwside of using 
ls
though here?
Relies on the predictability of UNIX systems working as expected, e.g. that someone doesn't have some strange version of ls installed
👍 1
j
Copy code
$ ll
total 84K
drwxrwxr-x  4 james james 4.0K Oct  9 11:35 ./
drwxr-xr-x 18 james james  36K Oct  9 11:33 ../
-rw-rw-r--  1 james james    0 Oct  9 11:33 one.pdf
-rw-rw-r--  1 james james    0 Oct  9 11:33 one.rev.1.bt2
lrwxrwxrwx  1 james james   16 Oct  9 11:34 two.rev.2.bt2 -> ../two.rev.2.bt2
If I have that
And run
Copy code
index=file("/home/james/Downloads/test")

index.listFiles()
I get
Copy code
Result: [/home/james/Downloads/test/.nextflow.pid, /home/james/Downloads/test/.nextflow-console.log, /home/james/Downloads/test/one.pdf, /home/james/Downloads/test/one.rev.1.bt2, /home/james/Downloads/test/.nextflow, /home/james/Downloads/test/two.rev.2.bt2, /home/james/Downloads/test/work]
Copy code
index=file("/home/james/Downloads/test")

index.listFiles().findAll{it.name.endsWith(".rev.1.bt2")}.first().toString() - ".rev.1.bt2"
Copy code
Result: '/home/james/Downloads/test/one'
So I guess yes?
j
Looking good... one thought - use 
find
instead of 
findAll
? Then you just get the first result and can drop the 
.first()
(if there are two results you have other problems)
Copy code
index.listFiles().find { it.name.endsWith(".rev.1.bt2") }.toString() - ".rev.1.bt2"
j
Copy code
index.listFiles().find{it.name.endsWith(".rev.2.bt2")}.toString() - ".rev.2.bt2"
Copy code
Result: '/home/james/Downloads/test/two'
Ok that works!
I'll ask the guy to try it out...
ah no wait, but that still doesn't fix the issue of getting teh root directory
j
What do you mean?
j
Like yuo usaid 
index
is assuming you are given a specific directory
j
j
But to properly replace 
find
we need to have it execute the searcho n the entire work directory
Yeahhhh but that's a lot of extra ugly stuff
😬
j
It's two lines!
j
I'm looking for a oneliner
😉
j
You can have an ugly one-liner:
Copy code
index = index.isDirectory() ? index.listFiles().find{it.name.endsWith(".rev.2.bt2")}.toString() - ".rev.2.bt2" : index.find{it.name.endsWith(".rev.2.bt2")}.toString() - ".rev.2.bt2"
j
What is the downside of the just searching the entire directory though?
(other than speed)
At the moment for example, I'm testing:
Copy code
INDEX=${task.workDir.listFiles().find { it.name.endsWith(".rev.1.bt2") }.toString() - ".rev.1.bt2"}
    [ -z "\$INDEX" ] && INDEX=${task.workDir.listFiles().find { it.name.endsWith(".rev.1.bt2l") }.toString() - ".rev.1.bt2l"}
    [ -z "\$INDEX" ] && echo "Bowtie2 index files not found" 1>&2 && exit 1
But you might be right..
9it just means more work for me to replace all of the modules
j
I dunno, it jsut seems less clean to me I guess there's some small chance that yuo somehow encounter a link to another index, because something got misspecified?
j
😪
j
Do it above the script block?
j
yeah
j
Copy code
def index = findy stuff
j
I'm wondering why we went for the bash method in the first place now tho ngl
Well Whelp neither are working
My way it doesn't pick up 
task.workDir
And your way gives me:
Copy code
java.nio.file.ProviderMismatchException -- Check script '/home/james/git/nf-core/modules/modules/nf-core/bowtie2/align/main.nf' at line: 55
Whatever that means
m
Could we use 
task.workDir
Is only set in 
exec:
native processes
👌 1
j
I will have to try next week instead
m
Jim's idea rewritten.
Copy code
tool_index = (index.isDirectory() ? index.listFiles() : index)
        .find { it.name.endsWith(".rev.2.bt2") }
        .toString() - ".rev.2.bt2"
Or would there be several levels of nesting expected too? ( and left out the null safe because we want to error if nothing is found )
j
Yeah, that’s much nicer. I think if we have to recurse deeper there are other problems, so a single level is fine?
j
Still doesn't like it, same error as before
I'm not sure why
m
In your test, is the input a directory? Seqera's AI suggests something to do with mixed filesystems resulting in the 
ProviderMismatchException
, but I'm confused as to why that might be the case here now. Is 
process.scratch
enabled?
SAI (Seqera AI) suggests doing 
file(index.toString())
before the rest. Does that help?
j
It is a directory yes
Unless I messed something up:
Copy code
def index_prefix = (file(index.toString()).isDirectory() ? file(index.toString()).listFiles() : file(index)).find { it.name.endsWith(".rev.2.bt2") }.toString() - ".rev.2.bt2"
Is resulting in 
null
directory
m
Try 
toUriString()
?
j
(meeting now)
👍🏽 1
Copy code
def index_prefix = (file(index.toUriString()).isDirectory() ? file(index.toString()).listFiles() : file(index)).find { it.name.endsWith(".rev.2.bt2") }.toString() - ".rev.2.bt2"
gave me
Copy code
java.lang.NullPointerException: Cannot invoke method getAt() on null object
m
That's strange. There's no indexing there. It's a bit crazy this is turning out to be a difficult problem.
💯 1
Are the symlinks relative or absolute paths when linked into the working directory? If relative, can they be made absolute?
j
I don't know if I'm doing something stipud either to bf
Ok even if I try to just print 
index
in the bowtie2 align module, basically only 
println(index)
works. Anything else I attach to it has different errors: either proderMismatch (
listFiles
), 
toString
(
null
), 
file(index).listFiles()
cannot invokle getAt() on null object...)
So I jave no idea
m
But with out all that, and just using the old find method, are the symlinks it's trying to follow, relative or absolute (trying to approach from another angle instead of Groovy)?
j
Copy code
$ ll
total 72K
drwxrwxr-x 2 james james 4.0K Oct 13 09:33 ./
drwxrwxr-x 3 james james 4.0K Oct 13 09:33 ../
lrwxrwxrwx 1 james james  126 Oct 13 09:33 bowtie2 -> /home/james/git/nf-core/modules/.nf-test/tests/6efa8cd7f5a46a16a3241dcd8a20baf0/work/1f/b85cf476a31ba3d95ed1fd635da252/bowtie2/
-rw-rw-r-- 1 james james    0 Oct 13 09:33 .command.begin
-rw-rw-r-- 1 james james  192 Oct 13 09:33 .command.err
-rw-rw-r-- 1 james james  192 Oct 13 09:33 .command.log
-rw-rw-r-- 1 james james    0 Oct 13 09:33 .command.out
-rw-rw-r-- 1 james james  11K Oct 13 09:33 .command.run
-rw-rw-r-- 1 james james  915 Oct 13 09:33 .command.sh
-rw-r--r-- 1 james james  247 Oct 13 09:33 .command.trace
-rw-rw-r-- 1 james james    1 Oct 13 09:33 .exitcode
lrwxrwxrwx 1 james james  174 Oct 13 09:33 genome.fasta -> /home/james/git/nf-core/modules/.nf-test/tests/6efa8cd7f5a46a16a3241dcd8a20baf0/work/stage-3dec7adb-aeb6-4eb5-be19-64cc5ab020cb/ef/c9975362cd189f751b5e040df94213/genome.fasta
lrwxrwxrwx 1 james james  177 Oct 13 09:33 test_1.fastq.gz -> /home/james/git/nf-core/modules/.nf-test/tests/6efa8cd7f5a46a16a3241dcd8a20baf0/work/stage-3dec7adb-aeb6-4eb5-be19-64cc5ab020cb/99/726fdba56636dcf6836dc475e6cc68/test_1.fastq.gz
-rw-r--r-- 1 james james 9.9K Oct 13 09:33 test.bam
-rw-r--r-- 1 james james  192 Oct 13 09:33 test.bowtie2.log
-rw-r--r-- 1 james james   70 Oct 13 09:33 versions.yml
Absolute by the looks of it
(
bowtie
is the directory)
That's from a nf-test run at least
m
Gemini is suggesting the WSL user use 
mfsylinks
Copy code
sudo mount -t cifs -o vers=3.0,mfsymlinks,username=user,password=pass //nas_server/share_name /mnt/nas_mount_point
so one can use 
find
and ensure 
cifs-utils
is up to date.
s
Hi everyone! I'm the WSL user and I do have these options included in my CIFS mount, see: https://github.com/nf-core/taxprofiler/issues/652#issuecomment-3396405610. So, if 
find
isn't working, it's not because of that. Thanks to everyone for all the effort in "finding" an alternative!
🤔 1
👋 1
j
Honestly I'm becoming more convinced the easiest route (even if unsatisfying) would be to just run 
ls -1
instead of 
find
or the groovy method. The 
ls -1
is straightforward in that it takes things at 'face value', in that it'll just list what we know is definitely present in the working directory - and it's up to the filesystem/nextflow to follow the link... I know it's unsatisfying in that we don't know why groovy is not able to read the 
index
channel as input, but I personally don't have time to deep dive into that 😕 What do you think @Jim Downie @Mahesh Binzer-Panchal? I know @Jim Downie said
Relies on the predictability of UNIX systems working as expected, e.g. that someone doesn't have some strange version of ls installed
But ls should just 'list' whatever is present, it's one of the simplest unix commands (arguably)... and given we are working in containers in (most cases) we should be able to pick it up if it doesn't work in tests... as in, I think a 'strange' version of 
ls
is very unlikely
👍 1
(and is probablymore battle tested that groovy/nextflow)
j
Not opposed, but we should try and figure out a better way to do this down the line
Either modifying the outputs of the indexing module, or figuring out how Groovy grooves
👍 2
m
Not opposed, but we should try and figure out a better way to do this down the line
This
j
FWIW this works for me:
Copy code
~/D/test 11.2s ❱ tree files/
files/
├── hello.a
├── hello.b
└── hello.c
Copy code
process test {

    input:
    path dir
    
    output:
    val var
    
    shell:
    var = file(dir).listFiles().find { file(it).extension == "c" }
    """
    echo $var
    """
}

workflow {
    test(file("./files"))
    test.out.view()
}
Copy code
[de/cf07a0] Submitted process > test
/Users/jd42/Downloads/test/files/hello.c

> cat work/de/cf07a0b2734d52f16b9d15e1612879/.command.out
/Users/jd42/Downloads/test/files/hello.c
j
Still doesn't work in bowtie2_align
Copy code
def index_prefix = file(index).listFiles().find { it.name.endsWith(".rev.2.bt2") }

    """
    INDEX=${index_prefix}
But what you mentioned indeed tracks what I did in the nf-console too
Copy code
java.lang.NullPointerException: Cannot invoke method getAt() on null object
Is the error
When I try to print just `
Copy code
def index_prefix = index.listFiles()
    println(index_prefix)
Then I get the providerMisMatch error 
file(index).listFiles()
just results in the Cannot invoke getAt() So wtf the is 
index
in the module then!?!?
m
You can use 
.getProperties()
to print out information on the object
👍 1
j
```
Copy code
> [target:/home/james/git/nf-core/modules/.nf-test/tests/6efa8cd7f5a46a16a3241dcd8a20baf0/work/57/115e8d49d959446ec7def40c75f1c8/bowtie2, alias:bowtie2, absolute:false, baseName:bowtie2, class:class nextflow.processor.TaskPath, extension:, fileName:bowtie2, fileSystem:sun.nio.fs.LinuxFileSystem@cb796ab, hidden:false, link:true, name:bowtie2, nameCount:1, parent:null, permissions:rwxr-xr-x, root:null, simpleName:bowtie2, uri:file:///home/james/git/nf-core/modules/.nf-test/tests/6efa8cd7f5a46a16a3241dcd8a20baf0/bowtie2]
Looks normal to me
From what I can see, it's still a link..
m
It's an internal class though to Nextflow, so perhaps this is something then the devs should fix
Normally this nextflow.processor.TaskPath isn't exposed to us, so I wonder if it's supposed to have the same methods as Path
j
Should we ping Ben do you think 😅
m
I'd make an issue
j
So something like, Nextflow process input 
path
class cannot be used with 
listFiles()
or something/
m
Yes, but also give the other details about windows, or is this more general?
j
I have no clue... I'll put both in and can split it after if necessary
j
So something like, Nextflow process input 
path
class cannot be used with 
listFiles()
or something/
It works in my example above...
j
Does it have the same propoerties?
j
It's not working with the bwa-mem2 outputs...
Copy code
[JLA:java.lang.System$2@7f41bfc, fs:sun.nio.fs.MacOSXFileSystem@268eba5c, path:[47, 85, 115, 101, 114, 115, 47, 106, 100, 52, 50, 47, 68, 111, 119, 110, 108, 111, 97, 100, 115, 47, 116, 101, 115, 116, 47, 98, 119, 97, 109, 101, 109, 50], stringValue:null, hash:0, offsets:[1, 7, 12, 22, 27], absolute:true, class:class sun.nio.fs.UnixPath, fileName:bwamem2, fileSystem:sun.nio.fs.MacOSXFileSystem@268eba5c, nameCount:5, parent:/Users/jd42/Downloads/test, root:/]
So it seems to work if you pass the dir in as a direct file, but not as a process output? The following fails:
Copy code
process BWAMEM2_INDEX {
    tag "$fasta"

    conda "bioconda::bwa-mem2=2.3"

    input:
    tuple val(meta), path(fasta)

    output:
    tuple val(meta), path("bwamem2"), emit: index
    path "versions.yml"             , emit: versions

    when:
    task.ext.when == null || task.ext.when

    script:
    def prefix = task.ext.prefix ?: "${fasta}"
    def args = task.ext.args ?: ''
    """
    mkdir bwamem2
    bwa-mem2 \\
        index \\
        $args \\
        -p bwamem2/${prefix} \\
        $fasta

    cat <<-END_VERSIONS > versions.yml
    "${task.process}":
        bwamem2: \$(echo \$(bwa-mem2 version 2>&1) | sed 's/.* //')
    END_VERSIONS
    """

}

process test {

	input:
	tuple val(meta), path(index)
	
	output:
	val var, emit: var
	val props, emit: props
	
	script:
    var = file(index).listFiles().find { file(it).extension == "amb" }
	props = file(index).getProperties()
    """
    echo $var
    """
}

workflow {
    BWAMEM2_INDEX([[id: "test"], file("./fasta.fasta")])
	
	test(BWAMEM2_INDEX.out.index)
	
    test.out.var.view()
    //test.out.props.view()
}
p
Somewhat late to the party here it seems. As a temporary fix I don't mind using ls, but generally, ls in scripts are wrong and should really either be a glob or a find. I also wonder what the structure looks like and if that instruction to follow links (
-L
) isn't part of the problem.
j
@Samuel G. Huete could you make a separate Nextflow issue on the Nextflow repo saying NXF doesn't seem to support your particular WSL/CIFS case, and could you test what Pontus says above (i.e., removing the 
-L
)?
s
Hello, I am quite busy the following weeks but will try to see if I can squeeze trying without the 
-L
. But why would the issue on NXF be necessary? It seems to me it is about the behaviour of the 
bowtie2
module, the rest of the pipeline appears working fine for me
j
It's just an experiment to see if we can further identify the issue I think. It's not actually the bowtie2 module itself we think, it's related to how Nextflow is handling the mounting/tracking the files and your very particular CIFS set up - 
find
is working for everyone else in many other computational contexts, and also in other modules (the 
find
pattern is used in bwa, minimap, and a bunch of others).
👍 1
For example in taxprofiler:
I suspect that you will have the same issue if were to e.g. skip the host removal, and run centrifuge, or ganon
m
-L
is necessary for 
find
to look inside the index directory, because the directory is staged as a symbolic link
this 2
j
Ah right
I thought it was just a different variatn of 
-l
So back to suggestion 1: make the issue on nextflow about WSL/CIFS and find
s
Okay! Should I cite your issue then? This one: https://github.com/nextflow-io/nextflow/issues/6488
j
But surely the issue with WSL/CIFS + find is not a problem with Nextflow, but a problem with whatever version of 
find
is in the container (GNU find?) and WSL/CIFS?
j
I don't know 😬
But either @Samuel G. Huete needs to find another set up, or we replace every single container with a different version of 
find
But it is not helping that we can't even test this with groovy
p
I lost track, could this be triggered by someone else?
j
There are two issues @pontus which is probably why: 1. Samuel's WSL+CIFS+NAS setup doesn't work with the bowite2/align module, as the 
find
command doesn't pick up something inside the linked input folder 2. When we tried to switch to a groovy based system of finding the required file inside the input folder, this also didn't work
p
(And looking back, I missed the depth there, but still, it seems the same to me with 
find
without 
-L
and what 
ls
would give, but I agree it seems a bother having to put paths in those commands.)
j
@Samuel G. Huete something to test would be whether running some other version of find (Busybox?) works instead of GNU find inside the work directory
p
Thanks, for 1, was there someone else that managed to replicate that? I wonder what it looks like and why the 
find
doesn't work (where my first guess would be filenames but that might be wrong).
j
p
It's often good to test thing but I can't make a coherent model where the find version should matter.
j
Using a 
ls -1
based system worked, which was my inital suggestion and then @Mahesh Binzer-Panchal and @Jim Downie sent me down a deep rabbit hole (🐰 shakefist )
s
I'm sorry guys, you know way more than me about coding. I am just a regular user. But why the 
ls
-based option is not okay? It worked perfectly fine for me
j
Because I guess @Jim Downie is rightly pointing out, that if someone has a wierd version of 
ls
in a container, we will have the opposite problem 😅
👍 1
s
j
One point is that the 
ls
option is less flexible. You need to know that the index directory is called 
bowtie2
(it might not be), or that the index is a directory (it could be a list of files). You could hypothetically recurse and ignore the name of the index dir, but 
ls -R
spits out something harder to parse.
👍 1
So find is better from that perspective, it just gives line-by-line output from the search.
👍 1
@Samuel G. Huete What result do you get if you run the specific find command in question inside the work directory?
p
Also, https://github.com/koalaman/shellcheck/wiki/SC2012. If memory serves, there can be a few other gotchas.
👍 2
s
I did try to run 
find
inside the work directory to troubleshoot a bit the problem before submitting the issue. If I run the following commands within my work directory (
/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9
) I got: 
user@host:/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9$ find -L ./ -name "*.rev.1.bt2"
(empty) 
user@host:/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9$ find ./ -name "*.rev.1.bt2"
(empty) 
user@host:/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9$ find bowtie2 -name "*.rev.1.bt2"
(empty) 
user@host:/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9$ ls -ld bowtie2
lrwxrwxrwx 1 user user 143 Sep 22 21:00 bowtie2 -> /mnt/NAS/work_03092025/17/b59594abb9ed2812b4da2225acf49d/bowtie2
user@host:/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9$ readlink -f bowtie2
/mnt/NAS/work_03092025/17/b59594abb9ed2812b4da2225acf49d/bowtie2
user@host:/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9$ find ./ -follow -name "*.rev.1.bt2"
(empty)
I hope that clarifies a bit the issue
p
Not really :) Can you show a 
find -L . | grep bowtie2
? And the find without 
-L
would need the place to start looking with a final slash to start there rather than just showing the link (so 
find bowtie2/
or similar).
s
Yes, sorry, that's it: 
user@host:/mnt/NAS/work_03092025/17/b59594abb9ed2812b4da2225acf49d$ find -L . | grep bowtie2
./bowtie2
./bowtie2/hs1.4.bt2
./bowtie2/hs1.1.bt2
./bowtie2/hs1.2.bt2
./bowtie2/hs1.rev.1.bt2
./bowtie2/hs1.rev.2.bt2
./bowtie2/hs1.3.bt2
p
(but we already know that the expression as in the module doesn't work, I'm hoping to see enough to understand why that's the case).
Thanks.
s
This worked: 
user@host:/mnt/NAS/work_03092025/17/b59594abb9ed2812b4da2225acf49d$ find bowtie2/ -name "*.rev.1.bt2"
bowtie2/hs1.rev.1.bt2
p
Okay, now I have something to think about.
s
Wait, at the time I run the troubleshoot bowtie2 was a symlink but now it isn't anymore (perhaps because the computation was finished?), see now the output of this: 
user@host:/mnt/NAS/work_03092025/17/b59594abb9ed2812b4da2225acf49d$ ls -ld bowtie2/
drwxrwxrwx 2 user user 0 Sep 19 13:34 bowtie2/
That's probably why the previous commands worked
p
Maybe, but not at all certain. Could you rerun those commands from the task directory where the symlink was (
/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9
). For clarity: it's not turtles all the way down, here you seem to have the task directory for whatever process created the 
bowtie2
directory.
s
Sure, my bad, I used the wrong directory
First command (ls): 
user@host:/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9$ ll
total 84
drwxrwxrwx 2 user user     0 Sep 22 21:00 ./
drwxrwxrwx 2 user user     0 Sep 28 03:54 ../
-rwxrwxrwx 1 user user     0 Sep 22 21:00 .command.begin*
-rwxrwxrwx 1 user user    30 Sep 22 21:00 .command.err*
-rwxrwxrwx 1 user user    30 Sep 22 21:00 .command.log*
-rwxrwxrwx 1 user user     0 Sep 22 21:00 .command.out*
-rwxrwxrwx 1 user user 11435 Sep 22 21:00 .command.run*
-rwxrwxrwx 1 user user  1400 Sep 22 21:00 .command.sh*
-rwxrwxrwx 1 user user     0 Sep 22 21:00 .command.trace*
-rwxrwxrwx 1 user user     1 Sep 22 21:00 .exitcode*
lrwxrwxrwx 1 user user   193 Sep 22 21:00 TB007_TB007_EKDN250015205-1A_22VGFWLT4_L6.merged.fastq.gz -> /mnt/NAS/work_03092025/e1/1e28bef4a0a90b176fb0ea1fa93a8a/TB007_TB007_EKDN250015205-1A_22VGFWLT4_L6.merged.fastq.gz*
lrwxrwxrwx 1 user user   143 Sep 22 21:00 bowtie2 -> /mnt/NAS/work_03092025/17/b59594abb9ed2812b4da2225acf49d/bowtie2/
lrwxrwxrwx 1 user user    52 Sep 22 21:00 hs1.fa -> /mnt/NAS/bioinfo_resources/T2T-CHM13_v2.0/hs1.fa*
Second & third commands (finds): 
user@host:/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9$ find -L ./ -name "*.rev.1.bt2"
(empty) 
user@host:/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9$ find -L . | grep bowtie2
./bowtie2
j
What is the straight-up output of 
find -L .
in that directory?
s
user@host:/mnt/NAS/work_03092025/cf/266a7cc6486141a9978677e32eaed9$ find -L .
.
./.command.run
./.command.sh
./.command.log
./.command.begin
./hs1.fa
./TB007_TB007_EKDN250015205-1A_22VGFWLT4_L6.merged.fastq.gz
./bowtie2
./.command.err
./.command.out
./.command.trace
./.exitcode
Open in Slack
PreviousNext
Powered by