Re: Usearch not found when in fact in path

[Chris Miller]

I may change the regular expression to search for other binary names in the future.  However, a simple workaround is to create a symlink to your binary of choice, called "usearch," and place it somewhere in the path.  

This brings up another point:  Compared to version 5, the new version 6 of usearch may not work with EMIRGE.  According to http://drive5.com/usearch/manual/quick_usearch5.html:

The command line has been redesigned. It is not backwards compatible with v5.  

I'll try and look into this shortly and ensure that EMIRGE works with this new version of usearch; please let me know if you've run into trouble or had success.

Thanks,

Chris 

On Tuesday, July 31, 2012 2:58:36 PM UTC-6, (unknown) wrote:

Hello,

I had a problem with usearch (version v6.0.152) not showing up in the dependency check of the emirge.py script.

The problem was due to the regex expression restricting to "usearch" and not "usearch_i86linux32" as seen in the output of usearch --version.

Below is a the fix.

match = re.search(r'usearch_i86linux32 v([0-9]*)\.([0-9]*)\.([0-9]*)', Popen("usearch --version", shell=True, stdout=PIPE).stdout.read())

Thanks

[QT]

Dear Chris,

Symlink does not mitigate the problem because the regex is matching the output of "usearch --version" and not the usearch filename.  The usearch that we have is indeed a symlink to the actual binary blob.

Best,
Quyen

--
You received this message because you are subscribed to the Google
Groups "EMIRGE users" group.
To post to this group, send email to emirge...@googlegroups.com
To unsubscribe from this group, send email to
emirge-users...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/emirge-users?hl=en?hl=en
 
EMIRGE code:
https://github.com/csmiller/EMIRGE

[Chris Miller]

Quyen,

You are correct; thanks for pointing that out.  Sorry, I had read the original message too fast and had forgotten how I did the dependency check.  The github code has been updated to correct this.  However, I still haven't checked whether usearch version 6 is compatible.  I'll try and do that soon.

Thanks,

Chris

On Wednesday, August 1, 2012 4:38:28 PM UTC-6, QT wrote:

Dear Chris,

Symlink does not mitigate the problem because the regex is matching the output of "usearch --version" and not the usearch filename.  The usearch that we have is indeed a symlink to the actual binary blob.

Best,
Quyen

On Wed, Aug 1, 2012 at 11:17 AM, Chris Miller wrote:

I may change the regular expression to search for other binary names in the future.  However, a simple workaround is to create a symlink to your binary of choice, called "usearch," and place it somewhere in the path.  

This brings up another point:  Compared to version 5, the new version 6 of usearch may not work with EMIRGE.  According to http://drive5.com/usearch/manual/quick_usearch5.html:

The command line has been redesigned. It is not backwards compatible with v5.  

I'll try and look into this shortly and ensure that EMIRGE works with this new version of usearch; please let me know if you've run into trouble or had success.

Thanks,

Chris 

On Tuesday, July 31, 2012 2:58:36 PM UTC-6, (unknown) wrote:

Hello,

I had a problem with usearch (version v6.0.152) not showing up in the dependency check of the emirge.py script.

The problem was due to the regex expression restricting to "usearch" and not "usearch_i86linux32" as seen in the output of usearch --version.

Below is a the fix.

match = re.search(r'usearch_i86linux32 v([0-9]*)\.([0-9]*)\.([0-9]*)', Popen("usearch --version", shell=True, stdout=PIPE).stdout.read())

Thanks

--
You received this message because you are subscribed to the Google
Groups "EMIRGE users" group.
To post to this group, send email to emirge...@googlegroups.com
To unsubscribe from this group, send email to

emirge-users+unsubscribe@googlegroups.com

[QT]

Regarding the usearch performance, it did not run successfully.  Below is the error.

subprocess.CalledProcessError: Command 'usearch --sort /home/shivamd/Victoria-emirge/hot/iter.00/iter.00.cons.fasta --output /home/shivamd/Victoria-emirge/hot/iter.00/iter.00.cons.fasta.sorted.tmp.fasta' returned non-zero exit status 1

--

You received this message because you are subscribed to the Google
Groups "EMIRGE users" group.
To post to this group, send email to emirge...@googlegroups.com
To unsubscribe from this group, send email to

emirge-users...@googlegroups.com

[Chris Miller]

Thanks, Quyen, for verifying.

I'll look into the command line changes in usearch 6 and get emirge fixed up as soon as possible.  In the meantime, emirge will still work with usearch version 5.

Chris

On Wednesday, August 1, 2012 4:53:40 PM UTC-6, QT wrote:

Regarding the usearch performance, it did not run successfully.  Below is the error.

subprocess.CalledProcessError: Command 'usearch --sort /home/shivamd/Victoria-emirge/hot/iter.00/iter.00.cons.fasta --output /home/shivamd/Victoria-emirge/hot/iter.00/iter.00.cons.fasta.sorted.tmp.fasta' returned non-zero exit status 1

On Wed, Aug 1, 2012 at 11:17 AM, Chris Miller wrote:

I may change the regular expression to search for other binary names in the future.  However, a simple workaround is to create a symlink to your binary of choice, called "usearch," and place it somewhere in the path.  

This brings up another point:  Compared to version 5, the new version 6 of usearch may not work with EMIRGE.  According to http://drive5.com/usearch/manual/quick_usearch5.html:

The command line has been redesigned. It is not backwards compatible with v5.  

I'll try and look into this shortly and ensure that EMIRGE works with this new version of usearch; please let me know if you've run into trouble or had success.

Thanks,

Chris 

On Tuesday, July 31, 2012 2:58:36 PM UTC-6, (unknown) wrote:

Hello,

I had a problem with usearch (version v6.0.152) not showing up in the dependency check of the emirge.py script.

The problem was due to the regex expression restricting to "usearch" and not "usearch_i86linux32" as seen in the output of usearch --version.

Below is a the fix.

match = re.search(r'usearch_i86linux32 v([0-9]*)\.([0-9]*)\.([0-9]*)', Popen("usearch --version", shell=True, stdout=PIPE).stdout.read())

Thanks

--
You received this message because you are subscribed to the Google
Groups "EMIRGE users" group.
To post to this group, send email to emirge...@googlegroups.com
To unsubscribe from this group, send email to

emirge-users+unsubscribe@googlegroups.com

[Chris Miller]

The latest version of EMIRGE on github now supports usearch version 6.  Please also see this posting.

Thanks,

Chris

[naze...@googlemail.com]

Hello,
Im getting a similar error and can't figure out how to solve it, being relatively new to linux. I wondered if anyone might offer some help on solving this.
For the record, here is the error message I get.

dave@dave-Inspiron-3420[dave] emirge.py --help                        [11:03AM]
/bin/sh: 1: usearch: not found
FATAL: usearch not found in path!

Thanks for any help
Dave

On Sunday, 10 February 2013 00:50:16 UTC, enu...@gmail.com wrote:

Problem resolved.  After a lot of trial and error, the resolution was to specify the full path to Python.  Now emirge.py can correctly locate things in my path.

Erin

On Friday, February 8, 2013 4:52:23 PM UTC-8, enu...@gmail.com wrote:

Hi Chris,

We are trying to use EMIRGE on a Linux server, and just ran into the same problem where EMIRGE says usearch is not in the path, when in fact it is in the path.

We downloaded EMIRGE a couple of weeks ago, so I would assume it would be the most updated version.  Our usearch version is 6.0.203.  Any clue what is wrong?

Thanks,

Erin

emirge-users...@googlegroups.com

[sker...@gmail.com]

Hello:

I seem to have a similar issue to a previous post about not being able to find usearch, although it is in my path.

-bash-4.1$ ./emirge.py --help

/bin/sh: usearch: command not found

FATAL: usearch not found in path!

Is this the fix?  

match = re.search(r'usearch_i86linux32 v([0-9]*)\.([0-9]*)\.([0-9]*)', Popen("usearch --version", shell=True, stdout=PIPE).stdout.read())

On my system I have both usearch9 and usearch64, so when I run usearch the full name is either:

-bash-4.1$ usearch64

usearch v8.1.1756_i86linux64, 1046Gb RAM, 64 cores

-bash-4.1$ usearch9

usearch v9.0.2132_i86linux64, 1046Gb RAM, 64 cores

Thanks for your help.

Best,

Jeff