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.