I understand that it is best to flow with the logic of the underlying OS and not too make too many platform-dependent assumptions about what files should be read.

Perhaps, it seems like the best way to go would be to have a setting in universe_wsgi.ini to specify a file to read additional environment settings from? For example, in my case, I would add a line like:
    source_environment_from = '/Users/galaxy/.profile'



On 16/02/11 05:58, Nate Coraor wrote:
Hi Florent, et. al.,

I've moved the discussion over to galaxy-dev since it pertains to local

Florent Angly wrote:
Indeed, this workaround works! Thank you.
I added these lines to the beginning of my run.sh:
     export $PATH

Now, Galaxy can find Grinder, Velvet, etc....

Could Galaxy detect and use ~/.profile automatically if it exists?
Alternatively, maybe there should be a place in the configuration
file universe_wsgi.ini to specify which file to read environment
variables from? Is it worth filing an enhancement request in the bug
Unfortunately, this is really more of an issue with the way shells are
designed.  Galaxy can't make too many assumptions about how you want the
environment to be set up, especially since it's run under a variety of
shells.  What's going to happen is dependent entirely upon how the
parent shell to Galaxy is started.

By default if invoked in non-login, non-interactive mode (which would
likely be the case for most managed startup methods like launchd, rc
scripts, etc.), bash will not read *any* startup files.  This behavior
can be changed by specifying the path to a file to be sourced in the
$BASH_ENV environment variable in the calling environment.

However, when bash is called as 'sh', even $BASH_ENV is not available.

For more details, see the "INVOCATION" section of the bash(1) man page.

Since the public site runs on Solaris, we solve this by setting $PATH
and any other relevant variables within SMF.  Similar methods should
work (setting the $PATH in an init script or in the LaunchDaemon plist)
for other startup methods.

Although modifying run.sh as mentioned does work, modifications could
conflict with future changes from the upstream source repository.


P.S. I'll add a plug for zsh - its invocation is much less confusing
      and ~/.zshenv is *always* read regardless of invocation.

Again, thanks for the help.


To manage your subscriptions to this and other Galaxy lists, please use the
interface at:


Reply via email to