Relative paths in e.g. set_targets.sh

38 views
Skip to first unread message

Fredrik Boulund

unread,
Nov 24, 2016, 9:20:30 AM11/24/16
to CLARK Users
Hi!

I'm wondering if I'm misunderstanding anything regarding the installation of CLARK. I followed the instructions in the README file, and everything appears to work just fine. Symlinking the produced binaries to my bin-directory works fine etc. 
However, for all the shell scripts (e.g. set_targets.sh etc) it's a mess. They contain paths to some of the other scripts using paths relative to my current directory (e.g. on line 91 in set_targets.sh it references ./make_metadata.sh), which is really annoying. This makes it impossible to simply symlink the scripts to my bindir as well, and be happy with it, instead I have to either symlink all scripts and executables to my current workdir (which is obviously messy), or modify all the scripts to assume that all the scripts are available in my PATH (which they currently are, so this is the solution I opted for).

I wanted to ask if I'm the only one annoyed by this? Why did you design it like this, am I missing something?

Best regards,
Fredrk

Rachid

unread,
Nov 28, 2016, 8:38:57 PM11/28/16
to CLARK Users
Dear Fredrik,

Thank you for your interest! I understand you are interested in Symlinking the scripts, however may you explain why exactly you would like to do it for all scripts in the first place?

First, you can observe that setting the database and running the classification are two distinct and very different operations by nature but also by usage (In general, you set your database once and then run CLARK for many samples or cases). For a given set of reference sequences, the database is always set for a limited number of cases, while you can run CLARK as many times as you like. Given the general situation, it does not seem to you need to Symlink set_targets.sh. Maybe you do but it is always important to take a step back to understand what are your needs and then to decide the best approach.

Second, if you need to Symlinking all scripts then please let us know how we can help. It seems your concern is about the relative path, have you tried to replace them ? What is the outcome? Have you detected other dependencies or issues?

Third, if you have any suggestions or thought to improve the source code in the scripts, then please share them in this forum: feel free to post the source code for each script to modify. What I can do is to take a look, do the necessary corrections/modifications to integrate/publish in a new release. Would this sound good to you?

Sincerely,
Rachid

Fredrik Boulund

unread,
Nov 29, 2016, 4:05:20 AM11/29/16
to CLARK Users
Hi Rachid,

Thanks for you reply!

I'm just a bit confused as to how you intend these script to be used? 

If i download and install CLARK according to the documentation, I cannot use the helper scripts to prepare the database for CLARK as the scripts contain relative paths to their dependencies. I'm not sure if I'm making sense here... 

I expected to download and install CLARK somewhere (as an example, let's assume I install CLARK into ~/CLARK/), then be able to navigate to a directory of my choice, let's say ~/my_databases/, to prepare a database in here by running some command (e.g. set_targets.sh). This is not possible as the scripts are constructed now, not even if I call the script from my installation directory. For example, if I navigate to ~/my_databases/ and run ~/CLARK/set_targets.sh clark_bacteria_viruses_species_db bacteria viruses --species, it will fail as it cannot find all of the scripts that are referred to inside set_targets.sh using relative paths. 

As I'm writing this I'm starting to realize you probably intended people to run all of these scripts from their install directory, giving long absolute paths to whatever database directory you want to use. Is that correct? It just feels like your design is very unusual and not like most other Linux tools I've used. 

My expectation when installing any software in Linux is to 1) download and extract the source code; 2) sometimes compile some source code; 3) symlink binaries and executables to a directory on my path (normally ~/bin); 4) then run the program from whatever working directory I want. 

All the best,
Fredrik

Rachid

unread,
Dec 2, 2016, 12:58:01 AM12/2/16
to CLARK Users
I would not call this directory the "installation" directory because it does not reflect what this directory is about. 
From this directory (i.e., "~/CLARK" in your example), the user can install, yes, by calling "set_targets.sh" but also, and most importantly, run the classification but also all the other analysis commands described in the README/website that are provided. 
Thus, I would call it the "workspace" directory.
Hope it helps, 

Cheers,
Rachid

Fredrik Boulund

unread,
Dec 2, 2016, 2:30:43 AM12/2/16
to CLARK Users
Hi Rachid,

Thanks for your reply. I understand how you intended CLARK to be used now. I still think it's kind of unclear from the documentation, and very different to most other Linux tools I've used, but at least I got everything to work. Thank you so much for your help! 

Cheers,
Fredrik
Reply all
Reply to author
Forward
0 new messages