I had Compass 0.12 (a ruby gem) installed on Ubuntu Oneiric with no problems I have updated to Precise formatting / and keeping /home, so I needed to reinstall ruby (1.9.3).
I get this error now when I compile a SCSS file:
compass watch --trace
Change detected at 12:45:09 to: style.scss overwrite css/style.css
Dear developers making use of FSSM in your projects, FSSM is essentially dead at this point. Further development will be taking place in the new shared guard/listen project. Please let us know if you need help transitioning! ^_^b - Travis Tilley
>>> Compass is polling for changes. Press Ctrl-C to Stop.
ArgumentError on line ["46"] of /usr/lib/ruby/1.9.1/pathname.rb: invalid byte sequence in US-ASCII
/usr/lib/ruby/1.9.1/pathname.rb:46:in `chop_basename'
/usr/lib/ruby/1.9.1/pathname.rb:102:in `cleanpath_aggressive'
/usr/lib/ruby/1.9.1/pathname.rb:90:in `cleanpath'
/usr/lib/ruby/1.9.1/pathname.rb:452:in `relative_path_from'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/path.rb:82:in `split_path'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/path.rb:70:in `run_callback'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/path.rb:56:in `callback_action'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/path.rb:36:in `update'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/state/directory.rb:39:in `block in modified'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/state/directory.rb:37:in `each'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/state/directory.rb:37:in `modified'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/state/directory.rb:18:in `refresh'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/backends/polling.rb:17:in `block (2 levels) in run'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/backends/polling.rb:17:in `each'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/backends/polling.rb:17:in `block in run'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/backends/polling.rb:15:in `loop'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/backends/polling.rb:15:in `run'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm/monitor.rb:26:in `run'
/var/lib/gems/1.9.1/gems/fssm-0.2.9/lib/fssm.rb:70:in `monitor'
/var/lib/gems/1.9.1/gems/compass-0.12.1/lib/compass/commands/watch_project.rb:89:in `perform'
/var/lib/gems/1.9.1/gems/compass-0.12.1/lib/compass/commands/base.rb:18:in `execute'
/var/lib/gems/1.9.1/gems/compass-0.12.1/lib/compass/commands/project_base.rb:19:in `execute'
/var/lib/gems/1.9.1/gems/compass-0.12.1/lib/compass/exec/sub_command_ui.rb:43:in `perform!'
/var/lib/gems/1.9.1/gems/compass-0.12.1/lib/compass/exec/sub_command_ui.rb:15:in `run!'
/var/lib/gems/1.9.1/gems/compass-0.12.1/bin/compass:29:in `block in <top (required)>'
/var/lib/gems/1.9.1/gems/compass-0.12.1/bin/compass:43:in `call'
/var/lib/gems/1.9.1/gems/compass-0.12.1/bin/compass:43:in `<top (required)>'
/usr/local/bin/compass:19:in `load'
/usr/local/bin/compass:19:in `<main>'
(The "Dear developers" message is part of the output).
This error doesn't appear the first time I make a change to the scss file, but the second.
In addition, compass "eats" one "s" in some files and, instead of compiling them as "style.css" (what it should be from the file's name) it does as "tyle.css".
I've spend 3 hours looking at similar problems here but I couldn't solve it. I tried including # encoding: utf-8 on the top of some files with no luck.
Please explain step by step what should I do, since I am a total noob with Ruby (I just use it because of SASS).
I think there is some problem with the pathname, maybe it contains an invalid non-ASCII sequence; probably the eaten "s" is the problem, maybe it is an invalid character, or maybe a character near to it; try to ensure path is ASCII.
Or maybe a bug in precise readline package? Try to install ruby 1.9.3 via RVM, RVM should use readline bundled with it (see the comments below for details)
From what I can see, the file in question pathname.rb contains this function that seems to be where the trouble is:
def chop_basename(path)
base = File.basename(path)
if /\A#{SEPARATOR_PAT}?\z/o =~ base
return nil
else
return path[0, path.rindex(base)], base
end
end
private :chop_basename
Here's a link to a similar question with the same issue:
Ruby on Rails application won’t start using Passenger when there are non-ASCII characters in the app path
So the fix is clearly to stick with us-ascii pathnames.
Here's a snippet from the doc on that class:
Pathname represents a pathname which locates a file in a filesystem. The pathname depends on OS: Unix, Windows, etc. Pathname library works with pathnames of local OS. However non-Unix pathnames are supported experimentally.
As to why it worked before and doesn't now, that's hard to say. It's possible that some other library on your system changed, or that the upgrade to ruby 1.9.3 caused a minor change that introduced the error.
Related
Smallest replication available: (note the ruby 3.1.2 / 3.0 difference, but this is a fresh rvm reinstall of ruby 3.1.2 on a system with no other installed rubies (I rvm uninstalled 3.0)
# irb
3.1.2 :001 > Kernel.fork
(irb):1:in `fork': fork() function is unimplemented on this machine (NotImplementedError)
from (irb):1:in `<main>'
from /Users/me/.rvm/rubies/ruby-3.1.2/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>'
from /Users/me/.rvm/rubies/ruby-3.1.2/bin/irb:25:in `load'
from /Users/me/.rvm/rubies/ruby-3.1.2/bin/irb:25:in `<main>'
from /Users/me/.rvm/gems/ruby-3.1.2/bin/ruby_executable_hooks:22:in `eval'
from /Users/me/.rvm/gems/ruby-3.1.2/bin/ruby_executable_hooks:22:in `<main>'
First encountered after upgrading ruby and switching from cuprite to selenium:
NotImplementedError:
fork() function is unimplemented on this machine
# /Users/me/.rvm/gems/ruby-3.1.2/gems/childprocess-4.1.0/lib/childprocess/unix/fork_exec_process.rb:20:in `fork'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/childprocess-4.1.0/lib/childprocess/unix/fork_exec_process.rb:20:in `launch_process'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/childprocess-4.1.0/lib/childprocess/abstract_process.rb:81:in `start'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.5.0/lib/selenium/webdriver/common/service_manager.rb:109:in `start_process'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.5.0/lib/selenium/webdriver/common/service_manager.rb:56:in `block in start'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.5.0/lib/selenium/webdriver/common/socket_lock.rb:41:in `locked'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.5.0/lib/selenium/webdriver/common/service_manager.rb:54:in `start'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.5.0/lib/selenium/webdriver/common/service.rb:84:in `launch'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.5.0/lib/selenium/webdriver/common/driver.rb:341:in `service_url'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.5.0/lib/selenium/webdriver/common/driver.rb:321:in `create_bridge'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.5.0/lib/selenium/webdriver/common/driver.rb:74:in `initialize'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.5.0/lib/selenium/webdriver/common/driver.rb:47:in `new'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.5.0/lib/selenium/webdriver/common/driver.rb:47:in `for'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/selenium-webdriver-4.5.0/lib/selenium/webdriver.rb:89:in `for'
# /Users/me/.rvm/gems/ruby-3.1.2/gems/capybara-3.36.0/lib/capybara/selenium/driver.rb:83:in `browser'
# ./spec/rails_helper.rb:143:in `block (2 levels) in <top (required)>'
Use Ruby 3.2.0-preview2 on Apple Silicon with Monterey or Ventura
As of this writing, there are currently a number of open issues on the Ruby issue tracker related to various compilation errors on Apple Silicon. While specific issues may have work-arounds, the "big hammer" right now is to just upgrade to Ruby 3.2.0 Preview 2 which appears to meet the Pareto principle in resolving a number of M1/M2 compilation issues.
VM or Container Alternatives
If you can't or won't upgrade, then you might want to use a non-arm64 VM or a 3.1.2 image from Docker Hub that's already compiled. However, the latter will not solve any compilation issues you have with gems built outside the container, assuming the container also has the necessary libraries and build tools. As a result, using a VM or upgrading your Ruby are really your best bets.
Also Consider RubyNext Gem
You might also consider using RubyNext if you need to keep compatibility between older Ruby versions and newer ones. Whether you even need it considering Preview 2 is just a beta of a minor version bump is something you'll have to figure out. Likewise, whether RubyNext refinements or transpilation are better options if you go that route (e.g. backporting or polyfills for older Ruby versions rather than just using 3.2.0-preview2 without any newer features) is something you'll need to evaluate yourself. YMMV.
I try to convert a sample ruby script to an executable file with the ocra gem.Here is my ruby script.
puts "Hello word"
Gives me the following error when running ocra test.rb
C:/Ruby31-x64/lib/ruby/gems/3.1.0/gems/ocra-1.3.11/bin/ocra:34:in `tr': invalid byte sequence in UTF-8 (ArgumentError)
from C:/Ruby31-x64/lib/ruby/gems/3.1.0/gems/ocra-1.3.11/bin/ocra:34:in `to_posix'
from C:/Ruby31-x64/lib/ruby/gems/3.1.0/gems/ocra-1.3.11/bin/ocra:57:in `subpath?'
from C:/Ruby31-x64/lib/ruby/gems/3.1.0/gems/ocra-1.3.11/bin/ocra:611:in `block (2 levels) in find_gem_files'
from C:/Ruby31-x64/lib/ruby/gems/3.1.0/gems/ocra-1.3.11/bin/ocra:609:in `each'
from C:/Ruby31-x64/lib/ruby/gems/3.1.0/gems/ocra-1.3.11/bin/ocra:609:in `block in find_gem_files'
from C:/Ruby31-x64/lib/ruby/gems/3.1.0/gems/ocra-1.3.11/bin/ocra:597:in `each'
from C:/Ruby31-x64/lib/ruby/gems/3.1.0/gems/ocra-1.3.11/bin/ocra:597:in `find_gem_files'
from C:/Ruby31-x64/lib/ruby/gems/3.1.0/gems/ocra-1.3.11/bin/ocra:755:in `build_exe'
from C:/Ruby31-x64/lib/ruby/gems/3.1.0/gems/ocra-1.3.11/bin/ocra:1231:in `block in <top (required)>'
My version of ruby
ruby -v
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x64-mingw-ucrt]
Is there a good way to convert a ruby script to an executable file ?
The issue was my Window username contained the character è. Like Casper mentioned, UFT-8 must be respected with ocra. I followed this link to solve my problem and then restarted ocra and the issue was fixed.
Change user name on windows 10
reviving and old codebase. installed it in new docker env. when i start the app, i get this error. i'm not a ruby guy, dunno what this <<~ nor &. means. i've already bundle installed from the Gemfile. this app is still running in another environment but I don't have shell access to that environment currently.
WARNING: If you plan to load any of ActiveSupport's core extensions to Hash, be
sure to do so *before* loading Sinatra::Application or Sinatra::Base. If not,
you may disregard this warning.
Set SINATRA_ACTIVESUPPORT_WARNING=false in the environment to hide this warning.
rake aborted!
SyntaxError: /usr/local/bundle/gems/database_cleaner-active_record-2.0.0/lib/database_cleaner/active_record/base.rb:22: syntax error, unexpected <<
<<~SQL
^
/usr/local/bundle/gems/database_cleaner-active_record-2.0.0/lib/database_cleaner/active_record/base.rb:62: syntax error, unexpected '.'
...veRecord::Base.configurations&.configs_for(name: db)&.config...
... ^
/usr/local/bundle/gems/database_cleaner-active_record-2.0.0/lib/database_cleaner/active_record/base.rb:62: syntax error, unexpected '.'
...ations&.configs_for(name: db)&.configuration_hash
... ^
/usr/local/bundle/gems/database_cleaner-active_record-2.0.0/lib/database_cleaner/active_record/transaction.rb:1:in `require'
/usr/local/bundle/gems/database_cleaner-active_record-2.0.0/lib/database_cleaner/active_record/transaction.rb:1:in `<top (required)>'
/usr/local/bundle/gems/database_cleaner-active_record-2.0.0/lib/database_cleaner/active_record.rb:3:in `require'
/usr/local/bundle/gems/database_cleaner-active_record-2.0.0/lib/database_cleaner/active_record.rb:3:in `<top (required)>'
/usr/local/bundle/gems/database_cleaner-2.0.1/lib/database_cleaner.rb:1:in `require'
/usr/local/bundle/gems/database_cleaner-2.0.1/lib/database_cleaner.rb:1:in `<top (required)>'
/app/config/environments/shared.rb:9:in `<top (required)>'
/app/tasks/db.rake:2:in `require_relative'
/app/tasks/db.rake:2:in `block in <top (required)>'
/usr/local/bundle/gems/rake-13.0.3/exe/rake:27:in `<top (required)>'
Tasks: TOP => dl:start:all => dl:start:job_queue => dl:start:queue => environment
(See full trace by running task with --trace)
As engineersmnky already pointed out in the comment, both operators – the squiggly heredocs (<<~) and the safe navigation operator (&.) – were introduced in Ruby version 2.3. This means your application needs at least Ruby 2.3 and does not support older versions.
At the same time, when updating your Ruby environment to the latest version, your application complains about Fixnum and Bignum missing. Both classes were deprecated in Ruby 2.4 and removed shortly after. That means your application doesn't support Ruby 2.4 or above.
That said: It looks like your application is only able to run against Ruby 2.3. I suggest installing the latest Ruby 2.3 version which is 2.3.8 and try again.
Please note that even the 2.3.8 version is already more than two and a half years old and that Ruby 2.3 reached end-of-life, is unmaintained, and will not get any bug fixes or security updates anymore. Even if your application worked with Ruby 2.3.8, I highly recommend updating it to Ruby 2.7.3 or – even better Ruby 3.0.1
I have a Rails server application that uses the openid_connect gem. When I attempt to run it on CentOS 6.6, I get:
uninitialized constant OpenSSL::PKey::EC
Here is the full stacktrace:
$ rails server
/home/foo/.rvm/gems/ruby-2.1.3/gems/json-jwt-1.5.1/lib/json/jwk/jwkizable.rb:69:in `<top (required)>': uninitialized constant OpenSSL::PKey::EC (NameError)
from /home/foo/.rvm/gems/ruby-2.1.3/gems/json-jwt-1.5.1/lib/json/jwt.rb:102:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object/id_token.rb:1:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object.rb:7:in `block in <top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object.rb:6:in `each'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object.rb:6:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/connect_object.rb:52:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect.rb:85:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:76:in `require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:76:in `block (2 levels) in require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:72:in `each'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:72:in `block in require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:61:in `each'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:61:in `require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler.rb:134:in `require'
from /home/foo/tmp/openid_connect_sample/config/application.rb:7:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:53:in `require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:53:in `block in <top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:50:in `tap'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:50:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'
What does this mean and how I can I get past it?
This problem stems from Red Hat's refusal to include (for fear-of-patent-litigation reasons) certain Elliptic Curve (EC) algorithms in CentOS' default build of OpenSSL.
Note: According to #Cal's answer, CentOS 6.7 does not have this issue.
The openid_connect gem is dependent on the json-jwt gem, which uses one of those not-included algorithms.
Therefore, you need to rebuild a new version of OpenSSL that includes the needed algorithms.
These are the steps I followed (adapted from here) to build a new OpenSSL on my machine:
cd /usr/src
wget https://www.openssl.org/source/openssl-1.0.1l.tar.gz
yum install autoconf automake (you probably already have these installed)
tar zxvf openssl-1.0.1l.tar.gz
cd openssl-1.0.1l
export CFLAGS="-fPIC"
./config --prefix=/opt/openssl shared enable-ec enable-ecdh enable-ecdsa
make all
make install
Now, your Ruby is probably still linked against the old OpenSSL library, so you'll need to rebuild it to link to the new one.
Are you using rvm? Then great! Any new Rubies you install will build against the new OpenSSL. rvm remove your Ruby and re-install it (or simply install a different ruby version).
Not using rvm? Then I guess you'll need to rebuild Ruby the traditional way. But you probably already know how to do that, right? If not, you'll need to look in a different tutorial, because we can't cover that here.
Now reinstall bunder and do a bundle install, and your rails server should now run successfully.
(If anyone has corrections or clarifications to offer, please leave a comment and I'll make edits as necessary.)
I ran into this same problem with CentOS 6.6. But I didn't want to recompile a custom openssl and ruby to fix this. I didn't take very good notes because I tried so many things, but it appears that an update to all of the latest & greatest packages to CentOS 6.7 solves the problem.
Here are a few relevant package versions I have:
openssl098e-0.9.8e-18.el6_5.2.x86_64
openssl-1.0.1e-42.el6.x86_64
openssl-1.0.1e-42.el6.i686
openssl-devel-1.0.1e-42.el6.x86_64
glibc-2.12-1.166.el6_7.3.x86_64
kernel-2.6.32-573.7.1.el6.x86_64
After updating these packages, rebooting, and reinstalling my bundle the json-jwt gem worked perfectly.
This was our production machines, and I believe the ruby standard libs were compiled from source, then created as a custom RPM.
Our build server uses RVM, and this ended up being more of a pain. The RVM installer kept pulling binaries for centos, and the same failure came back again.
Found remote file https://rvm.io/binaries/centos/6/x86_64/ruby-1.9.3-p484.tar.bz2
I forced a source recompile like this:
rvm reinstall --disable-binary ruby-1.9.3-p484
And I noticed a very wonderful looking message:
#applying patch .rvm/patches/ruby/ssl_no_ec2m.patch.
That patch file has some C macro conditions that appear to exclude some EC related code.
And that worked! I also noticed that ruby's openssl.so has a lot of EC related symbols in it. The previously packaged centos ruby did not have these:
$ cd ~/.rvm/rubies/ruby-1.9.3-p484/lib/ruby/1.9.1/x86_64-linux
$ strings openssl.so |grep _EC
PEM_write_bio_ECPKParameters
i2d_ECPKParameters
PEM_read_bio_ECPKParameters
d2i_ECPKParameters
PEM_write_bio_ECPrivateKey
i2d_ECPrivateKey_bio
i2d_EC_PUBKEY_bio
PEM_write_bio_EC_PUBKEY
PEM_read_bio_ECPrivateKey
PEM_read_bio_EC_PUBKEY
d2i_ECPrivateKey_bio
d2i_EC_PUBKEY_bio
OPENSSL_1.0.1_EC
EVP_PKEY_assign_EC_KEY
OP_SINGLE_ECDH_USE
If I had to guess, the recompile against my new openssl 1.0.1 package must have triggered some C macros that opened up some kind of alternative algorithm that isn't legally protected.
If you check your openssl.so for symbols and it doesn't have all of these _EC related stuff, that's probably an issue.
I'm using Ruby 2.1.5 and whenever I download code that uses require to include a file, I get errors. Changing require to require_relative fixes the problem. For example, if I use the example code from rspec, I get the following error output.
mario#crunchbang:~/projects/rspec_test$ rspec bowling_spec.rb
/home/mario/.rvm/rubies/ruby-2.1.5/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require': cannot load such file -- bowling (LoadError)
from /home/mario/.rvm/rubies/ruby-2.1.5/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /home/mario/projects/rspec_test/bowling_spec.rb:2:in `<top (required)>'
from /home/mario/.rvm/gems/ruby-2.1.5/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `load'
from /home/mario/.rvm/gems/ruby-2.1.5/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `block in load_spec_files'
from /home/mario/.rvm/gems/ruby-2.1.5/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `each'
from /home/mario/.rvm/gems/ruby-2.1.5/gems/rspec-core-3.1.7/lib/rspec/core/configuration.rb:1105:in `load_spec_files'
from /home/mario/.rvm/gems/ruby-2.1.5/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:96:in `setup'
from /home/mario/.rvm/gems/ruby-2.1.5/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:84:in `run'
from /home/mario/.rvm/gems/ruby-2.1.5/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:69:in `run'
from /home/mario/.rvm/gems/ruby-2.1.5/gems/rspec-core-3.1.7/lib/rspec/core/runner.rb:37:in `invoke'
from /home/mario/.rvm/gems/ruby-2.1.5/gems/rspec-core-3.1.7/exe/rspec:4:in `<top (required)>'
from /home/mario/.rvm/gems/ruby-2.1.5/bin/rspec:23:in `load'
from /home/mario/.rvm/gems/ruby-2.1.5/bin/rspec:23:in `<main>'
from /home/mario/.rvm/gems/ruby-2.1.5/bin/ruby_executable_hooks:15:in `eval'
from /home/mario/.rvm/gems/ruby-2.1.5/bin/ruby_executable_hooks:15:in `<main>'
Is there something wrong with my Ruby set up or can require no longer be used the way it was in earlier versions of Ruby?
require works exactly the same as it did before: it searches the $LOAD_PATH. What has changed is the default $LOAD_PATH: the current directory . was removed from it, for various maintenance and security reasons.
In almost all cases, you don't want to load a file relative to the current working directory anyway (after all, the CWD is controlled by the user, so you don't even know what it is, how could you then reliably load a file from there?), you want to load it relative to the current file … which is exactly what require_relative does.
By the way: this change was relased 7 years ago, made before that, and announced even before that, I don't know where you are getting that code from, but I would be highly suspicious of code that hasn't been maintained for such an extended period of time (almost 10 years).
Require only searches for files in Ruby's load path. Prior to 1.9, the current folder (.) was included in the load path. See Kernel#require
if you've been writing code with paths relative to the current directory it's normal that require doesn't work. You can either add . to the load path:
rspec -I . my_script.rb
Or as you have found, require_relative resolves the argument relative to the path to the file it is contained in. People also used to use __FILE__ to achieve this before require_relative was available.
You can also add the -I option to your .rspec file or setup your load paths in your spec_helper.rb
When you use require you need to pass the absolute path for the file.
require_relative is working as it depends on the relative path.
Edit the code part where you require the file to absolute file path and it should work well.