Filewatcher won't load simple ruby app.rb with require 'geokit' about filewatcher

[daBee]

Ah for some reason it's working now. And the same version, 2.3.3. Might as well close this.

[nbekirov]

Have you properly followed the INSTALL and QUICK START instructions?

[daBee]

Will look into it. My beef so far is that I'm expecting it to duplicate any shell that I open manually. More later, if I find anything. Cheers

[daBee]

Yes. Like I said, it's only Filewatcher that has the issue. Using ruby app.rb in the terminal works just fine. The very same instructions I've given Filewatcher. The issue is not with geokit. I'm using geokit just fine.

[AlexWayfer]

$ ruby -v
ruby 2.3.4p301 (2017-03-30 revision 58214) [x86_64-linux]

# app.rb

puts RUBY_VERSION
puts require 'geokit'

$ ruby app.rb
2.3.4
true

$ filewatcher 'app.rb' --exec
# Ctrl+S for app.rb
2.3.4
true
# Ctrl+S for app.rb
2.3.4
true
# Ctrl+S for app.rb
2.3.4
true

No problems for me.

Are you sure you are running a file for the test and from filewatcher under the same version of Ruby?

Try to add this code:

puts RUBY_VERSION

[daBee]

Happening again. IRB loads require 'linkedin' just fine. Calling ruby in the terminal to load the very same file, works fine. The only difference between these three methods is filewatcher.

Is there any place I can look? RUBY_VERSION returns 2.3.3, which is supporting the exit version as well:

	/Users/rich/app.rb:76:in `require': cannot load such file -- linkedin (LoadError)
		from /Users/rich/app.rb:76:in `<main>'
	^Z
	[5]+  Stopped                 filewatcher "/users/rich/app.rb" "clear; ruby ~/app.rb"
	HQ:~ rich$ ruby -v
	ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin15]
	HQ:~ rich$

[daBee]

That version was 2.3.3. 2.4.0 works fine.

[daBee]

I'm finding that filewatcher isn't loading my .bash_profile paths:

tpp PATH:         "/Users/rich/.rvm/gems/ruby-2.4.0/bin:/Users/rich/.rvm/gems/ruby-2.4.0@global/bin:/Users/rich/.rvm/rubies/ruby-2.4.0/bin:/usr/local/opt/postgresql-9.5/bin:/usr/local/sbin:/usr/sbin:/usr/X11/bin:/usr/local/bin:/usr/bin:/opt/local/bin:/opt/local/sbin:/users/rich/.rvm/rubies/default:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/git/bin:/Users/rich/.rvm/bin"

Both are initiated in my login shell, so I assumed they would both take the same paths. Vast difference in gem list. app has a short list, and tpp has the list I am expecting. So I found the path looking for gems is different.

Why would filewatcher not adopt the .bash_profile paths? rvm info is what gave me this information, as environment PATHs are indeed represented above. All else is the same, including GEM_HOME.

Any idea why the .bash_profile isn't sourced? Cheers

[AlexWayfer]

@daBee TL;DR: My sincere advice: try rbenv, please.

filewatcher uses Process class from Ruby core, and only. So, this isn't filewatcher's problem: or Process class from Ruby core, or rvm.

I think that Ruby core works good, and I did not have a single problem with filewatcher, although I use it very often and strongly, in a team of a several developers on several OS (except Windows, for now).

So, I think you should try to replace rvm with rbenv.

That's my variables from shell:

$ echo $PATH
/home/alex/.rbenv/shims /home/alex/go/bin /usr/local/sbin /usr/local/bin /usr/bin /usr/lib/jvm/default/bin /usr/bin/site_perl /usr/bin/vendor_perl /usr/bin/core_perl
$ echo $GEM_HOME

$ echo $GEM_PATH

That's my file with Ruby-code:

# env.rb 
puts 'Backticks:'
puts `echo $PATH`
puts
puts '%x:'
puts %x{echo $PATH}
puts
puts "ENV['PATH']"
puts ENV['PATH']

That's its output:

$ ruby env.rb 
Backticks:
/home/alex/.rbenv/versions/2.4.1/bin:/usr/lib/rbenv/libexec:/home/alex/.rbenv/plugins/ruby-build/bin:/home/alex/.rbenv/shims:/home/alex/go/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

%x:
/home/alex/.rbenv/versions/2.4.1/bin:/usr/lib/rbenv/libexec:/home/alex/.rbenv/plugins/ruby-build/bin:/home/alex/.rbenv/shims:/home/alex/go/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

ENV['PATH']
/home/alex/.rbenv/versions/2.4.1/bin:/usr/lib/rbenv/libexec:/home/alex/.rbenv/plugins/ruby-build/bin:/home/alex/.rbenv/shims:/home/alex/go/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

That's filewatcher run with --dontwait (new name is immediate) option:

$ filewatcher '**/*' 'ruby env.rb' -d
Backticks:
/home/alex/.rbenv/versions/2.4.1/bin:/usr/lib/rbenv/libexec:/home/alex/.rbenv/plugins/ruby-build/bin:/home/alex/.rbenv/shims:/home/alex/go/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

%x:
/home/alex/.rbenv/versions/2.4.1/bin:/usr/lib/rbenv/libexec:/home/alex/.rbenv/plugins/ruby-build/bin:/home/alex/.rbenv/shims:/home/alex/go/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

ENV['PATH']
/home/alex/.rbenv/versions/2.4.1/bin:/usr/lib/rbenv/libexec:/home/alex/.rbenv/plugins/ruby-build/bin:/home/alex/.rbenv/shims:/home/alex/go/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
^C

So, I see no problems for me or filewatcher with rbenv.

And, for record, I'm using fish-shell. And I'm sure that the .bash_profile itself is not a stumbling block. Here the problem with ENV variable, I think, which is already compiled taking into account content of the .bash_profile file, and which should be thrown to the code by rvm in your case.

---

Well, I thought more, and remembered something else: Ruby's require method looking in directories from $LOAD_PATH constant, which is defined by rvm in your case, again, I think. You can read more about this constant in the Internet.

New code:

# env.rb
puts '$LOAD_PATH:'
puts $LOAD_PATH

Output:

$ ruby env.rb
$LOAD_PATH:
/home/alex/.rbenv/rbenv.d/exec/gem-rehash
/home/alex/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/did_you_mean-1.1.0/lib
/home/alex/.rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0
/home/alex/.rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/x86_64-linux
/home/alex/.rbenv/versions/2.4.1/lib/ruby/site_ruby
/home/alex/.rbenv/versions/2.4.1/lib/ruby/vendor_ruby/2.4.0
/home/alex/.rbenv/versions/2.4.1/lib/ruby/vendor_ruby/2.4.0/x86_64-linux
/home/alex/.rbenv/versions/2.4.1/lib/ruby/vendor_ruby
/home/alex/.rbenv/versions/2.4.1/lib/ruby/2.4.0
/home/alex/.rbenv/versions/2.4.1/lib/ruby/2.4.0/x86_64-linux

Output from filewatcher:

$ filewatcher '**/*' 'ruby env.rb' -d
$LOAD_PATH:
/home/alex/.rbenv/rbenv.d/exec/gem-rehash
/home/alex/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/did_you_mean-1.1.0/lib
/home/alex/.rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0
/home/alex/.rbenv/versions/2.4.1/lib/ruby/site_ruby/2.4.0/x86_64-linux
/home/alex/.rbenv/versions/2.4.1/lib/ruby/site_ruby
/home/alex/.rbenv/versions/2.4.1/lib/ruby/vendor_ruby/2.4.0
/home/alex/.rbenv/versions/2.4.1/lib/ruby/vendor_ruby/2.4.0/x86_64-linux
/home/alex/.rbenv/versions/2.4.1/lib/ruby/vendor_ruby
/home/alex/.rbenv/versions/2.4.1/lib/ruby/2.4.0
/home/alex/.rbenv/versions/2.4.1/lib/ruby/2.4.0/x86_64-linux
^C

[AlexWayfer]

I'll leave this issue open for now, but I'm waiting for your feedback, please.

[daBee]

rbenv works great. Completely moved over to rbenv.