How to "source" a file?

I have a bash file ~/.myenv that contains environmental variables like:

export EDITOR=vi
export FOO=bar

How do I source this file from within a ruby script that starts like?

#!/usr/bin/ruby

I could source the file in bash before running the ruby script, but I
prefer that the script do it, in case the user forgets.

Thx.

-Ken

Ken Feng wrote:

I have a bash file ~/.myenv that contains environmental variables like:

export EDITOR=vi
export FOO=bar

How do I source this file from within a ruby script that starts like?

#!/usr/bin/ruby

I could source the file in bash before running the ruby script, but I
prefer that the script do it, in case the user forgets.

Thx.

-Ken

source ~/.myenv

at work… NOT TESTED… guess

ilan

On Aug 7, 2009, at 11:00 AM, Ilan B. wrote:

#!/usr/bin/ruby
at work… NOT TESTED… guess

ilan

Nope! That will set those variables in the child process and any of
its children, but they’ll go away and have no effect on your ruby
process.

Your best bet is to warn the user if you are using defaults and tell
him/her/yourself to fix it.

unless ENV[‘EDITOR’]
ENV[‘EDITOR’] = ‘vi’
puts “Environment has no EDITOR using ‘#{ENV[‘EDITOR’]}’”
puts “Did you mean to?: source ~/.myenv”
end

You could also exit without doing anything if the value has no
acceptable default.

-Rob

Rob B. http://agileconsultingllc.com
[email protected]

At 2009-08-07 10:48AM, “Ken Feng” wrote:

I have a bash file ~/.myenv that contains environmental variables like:

export EDITOR=vi
export FOO=bar

Since Ruby is not Bash, you have to parse the file:

File.foreach("myenv") do |line|
  line.chomp.scan(/^export (.+?)=(.*)$/) do |name, val|
    ENV[name] = val
  end
end

p ENV['FOO']  # => "bar"

On Friday 07 August 2009 02:55:11 pm Glenn J. wrote:

Since Ruby is not Bash, you have to parse the file:

File.foreach("myenv") do |line|
  line.chomp.scan(/^export (.+?)=(.*)$/) do |name, val|
    ENV[name] = val
  end
end

p ENV['FOO']  # => "bar"

That’s pretty fragile – it would severely limit what you can put in the
file.

There are a few ways of doing this, depending on your goal. One would be
to
run a bash (or better yet, sh) script as a wrapper around your Ruby
script –
that is, if your command is installed as /usr/local/bin/foo, have it be
a
shell script which does this:

#!/bin/sh
. ~/.myenv
exec /usr/lib/foo/foo.rb $@

Another hack I’ve used, when I wasn’t sure whether or not I’d need those
variables, is to have bash execute the file, and then tell me. If you
only need
one variable, this is easy:

ENV[‘FOO’] = source ~/.myenv && echo -n $FOO

If you wanted all of the variables, here’s one (clumsy) way to do it
without
having to (really) parse anything:

require ‘yaml’
s = source ~/.myenv && ruby -e 'require "yaml"; print ENV.to_hash.to_yaml
Yaml.load(s).each_pair{|k,v| ENV[k]=v}

I realize I could’ve made that less ugly, but I’m not sure there’s a
good way
to make it pretty. It’s essentially the same as extracting a single
variable,
except that it invokes another Ruby interpreter to dump the entire
environment
as a yaml stream. I did this because it’s a lot easier to just throw the
yaml
parser at the problem than try to parse the output of something like
‘env’ –
I couldn’t even figure out which environment variables existed,
otherwise.

About the only way I could “improve” it is by streaming that Yaml
generation/parsing, but if anyone has an environment big enough for it
to
matter, they’ve already got problems.

One final way would be to add a ‘source ~/.myfile’ to any other programs
you try
to run – since you mentioned EDITOR, I’m assuming that’s why.

Den 10 Aug 2009 16:57:42 GMT skrev Glenn J.:

p ENV['FOO']  # => "bar"

But it’s not going to get tripped up by any line that doesn’t match the
pattern. It won’t run off and execute any of the other commands in this
bash file.

I’m not personally offended by your comments, I’m curious to learn more.

A couple of lines from my .profile:

export PATH=${HOME}/bin:${PATH}
source ${HOME}/.bashrc
if [ -z “$COLORTERM” ]
then
export EDITOR=vi
fi

/Kent

At 2009-08-07 06:53PM, “David M.” wrote:

That’s pretty fragile – it would severely limit what you can put in
the file.

I don’t understand this comment. How is it “severely limiting”?

Granted, it won’t properly parse
export a=b c=d e=f foo bar
and I didn’t account for extra whitespace. The OP didn’t specify any
such requirements though.

But it’s not going to get tripped up by any line that doesn’t match the
pattern. It won’t run off and execute any of the other commands in this
bash file.

I’m not personally offended by your comments, I’m curious to learn more.