You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using a directory path with "@" in a Ubuntu system causes an error. The "@" symbol within perl config file Cofig_heavy.pl is interpreted as a variable instead of a part of the directory name.
Long Description
For reasons out of my control, on our ubuntu system the user folders within the home directory are named according to the users email adress (e.g. "/home/[email protected]/") and therefore contain the symbol "@". When using bowtie2 in this environment, the perl config file Config_heavy.pl contains many directory paths that all start with "/home/[email protected]/". These paths are not correctly recognized as literal directory paths, but the contained "@" symbol seems to lead to the issue that "@zymoresearch" is recognized as a variable and not a string. Bowtie2 seems to use Config_heavy.pl in some way and this throws an error that does not occure when using other perl dependend programs (e.g. cpan). I first opened and issue at perl (link) but it seems to be an issue with bowtie2 and not with perl.
Please let me know if this is unclear still. I'll be happy to give futher details and to describe the workaround that i used to make things work for me
Expected behavior
The path should be recognized correctly, and no error should occur.
Steps to Reproduce
# install conda
# create new conda environment within directory that contains "@"
(base) bioinformatics@zymo-hilde01:/home$ conda create -n perl_bug
# activate environment
(base) bioinformatics@zymo-hilde01:/home$ conda activate perl_bug
# install perl
(perl_bug) bioinformatics@zymo-hilde01:/home$ conda install perl
# install bowtie2
(perl_bug) bioinformatics@zymo-hilde01:/home$ conda install bowtie2
# testing bowtie2 results in error message regarding Config_heavy.pl
(perl_bug) bioinformatics@zymo-hilde01:/home$ bowtie2 --help
Possible unintended interpolation of @zymoresearch in string at /home/[email protected]/miniconda3/envs/perl_bug/lib/perl5/5.32/core_perl/Config_heavy.pl line 246.
[...]
Global symbol "@zymoresearch" requires explicit package name (did you forget to declare "my @zymoresearch"?) at /home/[email protected]/miniconda3/envs/perl_bug/lib/perl5/5.32/core_perl/Config_heavy.pl line 246.
The text was updated successfully, but these errors were encountered:
ZRE-Services
changed the title
"@" symbol in directory path results in syntax error in Config_heavy.pl
"@" symbol in directory path results in error connected to Config_heavy.pl
Jul 31, 2024
Sorry to say, but I do not think this is an issue with bowtie2 issue. Here is a thread of someone having the exact issue -- galaxyproject/galaxy#12133. From the thread, it seems like the issue is with conda not quoting paths correctly.
Using a directory path with "@" in a Ubuntu system causes an error. The "@" symbol within perl config file Cofig_heavy.pl is interpreted as a variable instead of a part of the directory name.
For reasons out of my control, on our ubuntu system the user folders within the home directory are named according to the users email adress (e.g. "/home/[email protected]/") and therefore contain the symbol "@". When using bowtie2 in this environment, the perl config file Config_heavy.pl contains many directory paths that all start with "/home/[email protected]/". These paths are not correctly recognized as literal directory paths, but the contained "@" symbol seems to lead to the issue that "@zymoresearch" is recognized as a variable and not a string. Bowtie2 seems to use Config_heavy.pl in some way and this throws an error that does not occure when using other perl dependend programs (e.g. cpan). I first opened and issue at perl (link) but it seems to be an issue with bowtie2 and not with perl.
Please let me know if this is unclear still. I'll be happy to give futher details and to describe the workaround that i used to make things work for me
The path should be recognized correctly, and no error should occur.
The text was updated successfully, but these errors were encountered: