command interpreter not using interpreter in my $PATH
Dear all, Sorry if I missed it, I looked in the list archives and couldn't find any mention of the topic. I am developing tools for Galaxy and thus running a Galaxy server from my within my home directory under my username. I have my own Perl installed in my home directory and this is in my $PATH, I don't use the system Perl, but when I run a Galaxy tool with <command interpreter="perl"> it is using the system Perl, as if my $PATH is not used at all. Since the Galaxy server and tool runner is running under my username and it looks like it just forks off a call to "perl ...." when it forks why doesn't it use my Perl? best, Leandro
Leandro Hermida wrote:
Dear all,
Sorry if I missed it, I looked in the list archives and couldn't find any mention of the topic.
I am developing tools for Galaxy and thus running a Galaxy server from my within my home directory under my username. I have my own Perl installed in my home directory and this is in my $PATH, I don't use the system Perl, but when I run a Galaxy tool with <command interpreter="perl"> it is using the system Perl, as if my $PATH is not used at all. Since the Galaxy server and tool runner is running under my username and it looks like it just forks off a call to "perl ...." when it forks why doesn't it use my Perl?
Hi Leandro, When running locally, the shell invoked by Galaxy should inherit $PATH from its parent. Can you create a basic script and run it as a tool that echos $PATH and see if it's what you expect? --nate
best, Leandro
------------------------------------------------------------------------
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Hi Nate, Thank you for the suggestion, I tried it out and it doesn't seem to inherit any environment from the system user running Galaxy. I made a test tool: <tool name="Test" id="omics_data_miner_check_test" version="1.0.0"> <command>echo \$PATH > $output1</command> <inputs> <param name="input1" type="text" size="10"/> </inputs> <outputs> <data format="txt" name="output1"/> </outputs> </tool> And the result shown in Galaxy /sbin:/usr/sbin:/bin:/usr/bin which is not my $PATH. On Tue, Jul 13, 2010 at 6:53 PM, Nate Coraor <nate@bx.psu.edu> wrote:
Leandro Hermida wrote:
Dear all,
Sorry if I missed it, I looked in the list archives and couldn't find any mention of the topic.
I am developing tools for Galaxy and thus running a Galaxy server from my within my home directory under my username. I have my own Perl installed in my home directory and this is in my $PATH, I don't use the system Perl, but when I run a Galaxy tool with <command interpreter="perl"> it is using the system Perl, as if my $PATH is not used at all. Since the Galaxy server and tool runner is running under my username and it looks like it just forks off a call to "perl ...." when it forks why doesn't it use my Perl?
Hi Leandro,
When running locally, the shell invoked by Galaxy should inherit $PATH from its parent. Can you create a basic script and run it as a tool that echos $PATH and see if it's what you expect?
--nate
best, Leandro
------------------------------------------------------------------------
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Leandro Hermida wrote:
Hi Nate,
Thank you for the suggestion, I tried it out and it doesn't seem to inherit any environment from the system user running Galaxy.
I made a test tool:
<tool name="Test" id="omics_data_miner_check_test" version="1.0.0"> <command>echo \$PATH > $output1</command> <inputs> <param name="input1" type="text" size="10"/> </inputs> <outputs> <data format="txt" name="output1"/> </outputs> </tool>
And the result shown in Galaxy
/sbin:/usr/sbin:/bin:/usr/bin
Hi Leandro, You may get different results if you put the echo in a shell script. Are you sure your $PATH variable is exported? --nate
which is not my $PATH.
On Tue, Jul 13, 2010 at 6:53 PM, Nate Coraor <nate@bx.psu.edu <mailto:nate@bx.psu.edu>> wrote:
Leandro Hermida wrote:
Dear all,
Sorry if I missed it, I looked in the list archives and couldn't find any mention of the topic.
I am developing tools for Galaxy and thus running a Galaxy server from my within my home directory under my username. I have my own Perl installed in my home directory and this is in my $PATH, I don't use the system Perl, but when I run a Galaxy tool with <command interpreter="perl"> it is using the system Perl, as if my $PATH is not used at all. Since the Galaxy server and tool runner is running under my username and it looks like it just forks off a call to "perl ...." when it forks why doesn't it use my Perl?
Hi Leandro,
When running locally, the shell invoked by Galaxy should inherit $PATH from its parent. Can you create a basic script and run it as a tool that echos $PATH and see if it's what you expect?
--nate
best, Leandro
------------------------------------------------------------------------
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu <mailto:galaxy-dev@lists.bx.psu.edu> http://lists.bx.psu.edu/listinfo/galaxy-dev
Hello, Yes $PATH is definitely exported in my .bash_profile. I also tried a different test where I used <command>env > $output1</command> and you wouldn't believe all my other environment variables are there perfectly except that $PATH is this incorrect one, it's like the tool runner purposely chose to reset $PATH. Could it be because my $PATH is quite long? -L On Tue, Jul 13, 2010 at 7:23 PM, Nate Coraor <nate@bx.psu.edu> wrote:
Leandro Hermida wrote:
Hi Nate,
Thank you for the suggestion, I tried it out and it doesn't seem to inherit any environment from the system user running Galaxy.
I made a test tool:
<tool name="Test" id="omics_data_miner_check_test" version="1.0.0"> <command>echo \$PATH > $output1</command> <inputs> <param name="input1" type="text" size="10"/> </inputs> <outputs> <data format="txt" name="output1"/> </outputs> </tool>
And the result shown in Galaxy
/sbin:/usr/sbin:/bin:/usr/bin
Hi Leandro,
You may get different results if you put the echo in a shell script. Are you sure your $PATH variable is exported?
--nate
which is not my $PATH.
On Tue, Jul 13, 2010 at 6:53 PM, Nate Coraor <nate@bx.psu.edu <mailto: nate@bx.psu.edu>> wrote:
Leandro Hermida wrote:
Dear all,
Sorry if I missed it, I looked in the list archives and couldn't find any mention of the topic.
I am developing tools for Galaxy and thus running a Galaxy server from my within my home directory under my username. I have my own Perl installed in my home directory and this is in my $PATH, I don't use the system Perl, but when I run a Galaxy tool with <command interpreter="perl"> it is using the system Perl, as if my $PATH is not used at all. Since the Galaxy server and tool runner is running under my username and it looks like it just forks off a call to "perl ...." when it forks why doesn't it use my Perl?
Hi Leandro,
When running locally, the shell invoked by Galaxy should inherit $PATH from its parent. Can you create a basic script and run it as a tool that echos $PATH and see if it's what you expect?
--nate
best, Leandro
------------------------------------------------------------------------
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu <mailto:galaxy-dev@lists.bx.psu.edu>
Hi Leandro, A lot of tools that are perl or python scripts will have the shebang line hardcoded to the system version, e.g.: #!/usr/bin/perl If you change that to: #!/usr/bin/env perl it'll pick up the version in your path. For example, we had to do this with tophat (python). However, that only applies to scripts that are run directly -- I'm not sure how Galaxy tool configs and the interpreter parameter work. Best, John On Tue, 13 Jul 2010, Leandro Hermida wrote:
Dear all,
Sorry if I missed it, I looked in the list archives and couldn't find any mention of the topic.
I am developing tools for Galaxy and thus running a Galaxy server from my within my home directory under my username. I have my own Perl installed in my home directory and this is in my $PATH, I don't use the system Perl, but when I run a Galaxy tool with <command interpreter="perl"> it is using the system Perl, as if my $PATH is not used at all. Since the Galaxy server and tool runner is running under my username and it looks like it just forks off a call to "perl ...." when it forks why doesn't it use my Perl?
best, Leandro
Hi there, I always use #!/usr/bin/env perl in my scripts, though in the case of using interpreter="..." it wouldn't look at the shebang since the command is specified at the command line. I even tried without interpreter="..." just using <command>./my_script.pl...</command> so that it would invoke shebang and I get this error: /bin/sh: ./my_script.pl: No such file or directory On Tue, Jul 13, 2010 at 7:06 PM, John Brunelle <john_brunelle@harvard.edu>wrote:
Hi Leandro,
A lot of tools that are perl or python scripts will have the shebang line hardcoded to the system version, e.g.:
#!/usr/bin/perl
If you change that to:
#!/usr/bin/env perl
it'll pick up the version in your path. For example, we had to do this with tophat (python).
However, that only applies to scripts that are run directly -- I'm not sure how Galaxy tool configs and the interpreter parameter work.
Best,
John
On Tue, 13 Jul 2010, Leandro Hermida wrote:
Dear all,
Sorry if I missed it, I looked in the list archives and couldn't find any mention of the topic.
I am developing tools for Galaxy and thus running a Galaxy server from my within my home directory under my username. I have my own Perl installed in my home directory and this is in my $PATH, I don't use the system Perl, but when I run a Galaxy tool with <command interpreter="perl"> it is using the system Perl, as if my $PATH is not used at all. Since the Galaxy server and tool runner is running under my username and it looks like it just forks off a call to "perl ...." when it forks why doesn't it use my Perl?
best, Leandro
Leandro Hermida wrote:
Hi there,
I always use #!/usr/bin/env perl in my scripts, though in the case of using interpreter="..." it wouldn't look at the shebang since the command is specified at the command line.
I even tried without interpreter="..." just using <command>./my_script.pl <http://my_script.pl> ...</command> so that it would invoke shebang and I get this error:
/bin/sh: ./my_script.pl <http://my_script.pl>: No such file or directory
Hi Leandro, In that case, you wouldn't want to include the './'. The full path to the script is always prepended when executing the command. When using 'interpreter', the value within is prepended to the the full path to the script. --nate
On Tue, Jul 13, 2010 at 7:06 PM, John Brunelle <john_brunelle@harvard.edu <mailto:john_brunelle@harvard.edu>> wrote:
Hi Leandro,
A lot of tools that are perl or python scripts will have the shebang line hardcoded to the system version, e.g.:
#!/usr/bin/perl
If you change that to:
#!/usr/bin/env perl
it'll pick up the version in your path. For example, we had to do this with tophat (python).
However, that only applies to scripts that are run directly -- I'm not sure how Galaxy tool configs and the interpreter parameter work.
Best,
John
On Tue, 13 Jul 2010, Leandro Hermida wrote:
Dear all,
Sorry if I missed it, I looked in the list archives and couldn't find any mention of the topic.
I am developing tools for Galaxy and thus running a Galaxy server from my within my home directory under my username. I have my own Perl installed in my home directory and this is in my $PATH, I don't use the system Perl, but when I run a Galaxy tool with <command interpreter="perl"> it is using the system Perl, as if my $PATH is not used at all. Since the Galaxy server and tool runner is running under my username and it looks like it just forks off a call to "perl ...." when it forks why doesn't it use my Perl?
best, Leandro
------------------------------------------------------------------------
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Hi everyone, I've figure out the source of the problem... it's when you run Galaxy in daemon mode (sh run.sh --daemon) it does not inherit and erases the $PATH of the system user running the process. When I run Galaxy in a terminal (sh run.sh) I have no problems. Is there a way to tell Galaxy in daemon mode to keep the $PATH of the user running the process? best, Leandro On Tue, Jul 13, 2010 at 7:34 PM, Nate Coraor <nate@bx.psu.edu> wrote:
Leandro Hermida wrote:
Hi there,
I always use #!/usr/bin/env perl in my scripts, though in the case of using interpreter="..." it wouldn't look at the shebang since the command is specified at the command line. I even tried without interpreter="..." just using <command>./my_script.pl< http://my_script.pl> ...</command> so that it would invoke shebang and I get this error:
/bin/sh: ./my_script.pl <http://my_script.pl>: No such file or directory
Hi Leandro,
In that case, you wouldn't want to include the './'. The full path to the script is always prepended when executing the command. When using 'interpreter', the value within is prepended to the the full path to the script.
--nate
On Tue, Jul 13, 2010 at 7:06 PM, John Brunelle <john_brunelle@harvard.edu<mailto: john_brunelle@harvard.edu>> wrote:
Hi Leandro,
A lot of tools that are perl or python scripts will have the shebang line hardcoded to the system version, e.g.:
#!/usr/bin/perl
If you change that to:
#!/usr/bin/env perl
it'll pick up the version in your path. For example, we had to do this with tophat (python).
However, that only applies to scripts that are run directly -- I'm not sure how Galaxy tool configs and the interpreter parameter work.
Best,
John
On Tue, 13 Jul 2010, Leandro Hermida wrote:
Dear all,
Sorry if I missed it, I looked in the list archives and couldn't find any mention of the topic.
I am developing tools for Galaxy and thus running a Galaxy server from my within my home directory under my username. I have my own Perl installed in my home directory and this is in my $PATH, I don't use the system Perl, but when I run a Galaxy tool with <command interpreter="perl"> it is using the system Perl, as if my $PATH is not used at all. Since the Galaxy server and tool runner is running under my username and it looks like it just forks off a call to "perl ...." when it forks why doesn't it use my Perl?
best, Leandro
------------------------------------------------------------------------
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
On Sun, Jul 18, 2010 at 10:00:51PM +0200, Leandro Hermida wrote:
Is there a way to tell Galaxy in daemon mode to keep the $PATH of the user running the process?
It's inelegant, but I just put the desired path at the top of run.sh. Unless you have multiple users running it in daemon mode that should work out fine. -- Ry4an Brase 612-626-6575 University of Minnesota Supercomputing Institute for Advanced Computational Research http://www.msi.umn.edu
Hi everyone, I figured it out, in the end has nothing to do with the --daemon mode it had to do with my Galaxy init script! I was accidentally sourcing the function library at the top of my init script: # Source function library. . /etc/rc.d/init.d/functions This resets PATH to only essential dirs, oops. Dont' do this... Now it works fine in --daemon mode thanks everyone for trying to help me out, Leandro On Mon, Jul 19, 2010 at 1:51 AM, Ry4an Brase <ry4an+galaxy@msi.umn.edu<ry4an%2Bgalaxy@msi.umn.edu>
wrote:
On Sun, Jul 18, 2010 at 10:00:51PM +0200, Leandro Hermida wrote:
Is there a way to tell Galaxy in daemon mode to keep the $PATH of the user running the process?
It's inelegant, but I just put the desired path at the top of run.sh. Unless you have multiple users running it in daemon mode that should work out fine.
-- Ry4an Brase 612-626-6575 University of Minnesota Supercomputing Institute for Advanced Computational Research http://www.msi.umn.edu
participants (4)
-
John Brunelle -
Leandro Hermida -
Nate Coraor -
Ry4an Brase