While investigating an issue with irb on my Mac (OS X 10.11.5) I noticed /etc/irbrc. The first few lines follow:
# Some default enhancements/settings for IRB, based on
# http://wiki.rubygarden.org/Ruby/page/show/Irb/TipsAndTricks
unless defined? ETC_IRBRC_LOADED
# Require RubyGems by default.
require 'rubygems'
# Activate auto-completion.
require 'irb/completion'
# continued ...
It seems to be out of date (rubygarden.org is gone, rubygems is in the standard library these days) and does things that I always thought I had to do in my own ~/.irbrc (set up completion, history, etc.).
It is dated 31 Jan 2016. I might or might not have run an Apple system update or upgraded something else on that date; I don't recall. I've definitely upgraded OS X by a major version or two since then.
I don't think I have any Rubies installed on this computer other than that from OS X and a Ruby 2.3.1 installed with rbenv (in my own account, not as root). That is, I don't think this file could have come from anything other than OS X.
Unix shell convention would lead me to expect that a file named /etc/irbrc would be executed when any user ran irb, before their ~/.irbrc if they had one. However, the irb installed by OS X doesn't appear to read this file: I put puts 1 at the top and don't see the result when I run irb. (I normally use rbenv, but disabled it while investigating this file.) /etc/irbrc doesn't appear to run whether or not I have an ~/.irbrc. Also, I see no mentions of this file in /usr/bin/irb or /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/irb.
My guess is that this file
is installed by OS X
is not read by irb as is (despite its misleading name and location), but is intended to be copied to ~/.irbrc.
Does anyone know for sure, or know any different?
I don't need or want it; I'm happy to maintain my own ~/.irbrc. I just want to be sure that it isn't affecting irb when I run it (in particular, the irb in the rbenv-installed Ruby that I normally use), and that future OS X upgrades won't change irb behavior.
Per Mark Setchell's and Jared Beck's comments, /etc/irbrc is installed with current (10.13) OS X and has been for at least a few major releases.
I copied /etc/irbrc to ~/.irbrc, ran irb, exited and got an error: undefined method 'nitems' for ["exit"]:Array (NoMethodError). This method existed in Ruby 1.8 but was removed from Ruby 1.9. I don't normally see this error, so I conclude that /etc/irbrc isn't executed at all.
Overall, I conclude that I can ignore /etc/irbrc when debugging issues with my ~/.irbrc, which was the origin of my question.
Related
I'm trying to use RbConfig::CONFIG['host'] to get information about the current version of OS X. On a machine using Ruby that was compiled on Yosemite (Darwin 14) but subsequently upgraded to El Capitan (Darwin 15), RbConfig::CONFIG still reports a version of Darwin 14.
I can switch to parsing the return value of uname -a, but I'd rather use a Ruby-native solution. Is there a way to update RbConfig::CONFIG without recompiling and reinstalling Ruby?
UPDATE
I found all the keys in RbConfig::CONFIG listed out in Ruby's configure script. It appears that each of the values is assigned inside configure. I can't see yet how that list of key-value pairs is serialized into the CONFIG constant.
It depends on your ruby installation.
You use the Ruby.Framework provided by Apple.
You have nothing to do.
I checked on both an iMac (early 2013) and a MBP (early 2015):
$ rbenv local system
$ rbenv rehash
$ irb
> RbConfig::CONFIG['host']
=> "x86_64-apple-darwin15"
Actually there is rbconfig.rb file which contains these settings :
grep "darwin15" /System/Library/Frameworks/Ruby.framework/Versions/Current/usr/lib/ruby/2.0.0/universal-darwin15/rbconfig.rb
TOPDIR = File.dirname(__FILE__).chomp!("/lib/ruby/2.0.0/universal-darwin15")
CONFIG["arch"] = "universal-darwin15"
CONFIG["target_os"] = "darwin15"
CONFIG["target"] = "universal-apple-darwin15"
CONFIG["host_os"] = "darwin15"
CONFIG["host"] = "x86_64-apple-darwin15"
CONFIG["build_os"] = "darwin15"
CONFIG["build"] = "x86_64-apple-darwin15"
You can't modify it because of System Intregrity Protection which is good.
You use a downloaded and compiled ruby version obtained from rvm,rbenv,whatever.
I can't provide a generic solution but here is what I did (I use rbenv).
$ rbenv local 2.2.3
$ rbenv rehash
# What is the config?
$ ruby -e 'p RbConfig::CONFIG["host"]'
"x86_64-apple-darwin14.5.0"
# Where is this?
$ grep -nir "x86_64-apple-darwin14.5.0" ~/.rbenv/versions/2.2.3/lib/ruby
~/.rbenv/versions/2.2.3/lib/ruby/2.2.0/x86_64-darwin14/rbconfig.rb:191: CONFIG["host"] = "x86_64-apple-darwin14.5.0"
~/.rbenv/versions/2.2.3/lib/ruby/2.2.0/x86_64-darwin14/rbconfig.rb:198: CONFIG["build"] = "x86_64-apple-darwin14.5.0"
# Change the CONFIG values according to your needs
$ vi ~/.rbenv/versions/2.2.3/lib/ruby/2.2.0/x86_64-darwin14/rbconfig.rb
$ ruby -e 'p RbConfig::CONFIG["host"]'
"x86_64-apple-darwin42"
Hope it helps.
Well that is what the RbConfig::CONFIG['host'] is supposed to return AFAIC: the OS version where ruby was built upon, not the current OS version. If you think it over it makes sense: there might be libraries or some internal components that need to make sure that your current ruby version was linked against certain library versions so say that something is not currently supported at built time if you use v15 but it was (and is) on version v14 so the fact that you already built it on an earlier version will make it work regardless of the OS upgrade, of course this is just a possible scenario, not saying it is actually true for this particular case. If you change that and force ruby to report that it was built on your current OS (or with some other library versions linked to it for that matter) which was not the case then you may break things for sure.
Why not make a simple function that does it, like you said, using uname -r? That would work just fine, I know is not the exact answer you were asking for but I exposed my reasoning above already:
require "open3"
def detect_os
cmd = "uname -r"
Open3.popen3 cmd do |stdin, stdout, stderr, wait_thr|
error = stderr.read
raise StandardError.new("Error while detecting OS: '#{error}'") unless error.empty?
stdout.read
end
end
puts detect_os
I've installed Ruby 2.1.1 via source.
I've seen suggestions to type ruby -v, which I assume would show that the binary isn't corrupted, but are there more comprehensive ways to ensure that it's working as expect? Unit-tests, benchmarks, etc to validate it's functional?
Run make test after compiling in the directory you’ve compiled in. (This might actually happen by default, I can’t remember. There’s also make test-all, among others.)
ruby -v will show you the current version of ruby installed on your machine.
If you want, just create a hello.rb with puts "hello" and run it using ruby hello.rb to check if it is interpreting the ruby code correctly. So you know that its functional.
I've installed ruby with rvm on a centos 6.3 VM and when I attempt to run ruby with no parameters (or erb for that matter) I get no response back, it just sits there.
Running 'ruby' just drops the cursor to the next line like it's waiting for more input or something else to happen. Typing any ruby commands during this time does nothing AFAIK. I do not get any errors, but I'm not exactly sure where to look. I have to control-c to break out of it.
Few interesting things:
(I'm fairly new to linux, so be gentle)
running the command ruby -v
gets me:
ruby 1.9.3p374 (2013-01-15 revision 38858) [x86_64-linux]
so it seems like it's installed
running:
echo "puts 'hello'" |ruby
gets me:
hello
I've created a different user and then logged in with that user and the behavior is the same.
I've installed rails and then created a rails app and I can do rails c use the rails console
Other notes that may or may not be relevant:
I've recently installed KDE. I did have ruby working before installing KDE but I can't say it was the installation of KDE that messed it up.
I've already uninstalled ruby using rvm and reinstalled, same thing.
Uninstalled rvm and reinstalled.
I've no idea where to go with this or what information would be useful.
Run irb to get an interactive session. This is a REPL, a Read-Eval-Print Loop.
To see Ruby do something in response to running the interpreter and feeding it standard input interactively, try something like:
$ ruby
p :hello
^D
If you just type ruby, I'm not sure anything will happen until it reads the entire input file ... i.e., sees a Control/D indicating standard input end-of-file.
I believe your looking for irb - the interactive Ruby interpreter.
erb is an interpreter that expects a file argument.
$ erb hello-world.rb
I've been trying to get ruby-prof working for memory usage on Mac OS X w/ Ruby 1.8.7 and so far I'm not having much luck.
I understand from the documentation that RubyProf::MEMORY mode requires a patched version of Ruby. I've tried installing the GC-patched version (which I found referenced in the Rails documentation) through RVM:
rvm reinstall 1.8.7 --patch ruby187gc
Based on the output of this command, everything looks good. I clearly see "Applying patch 'ruby187gc'" in the console output.
The problem seems to come when trying to use an RVM gemset. I wrote the following script to test this:
require "ruby-prof"
RubyProf.measure_mode = RubyProf::MEMORY
results = RubyProf.profile do
# code to measure
end
File.open(File.join(File.dirname(__FILE__), "profile-graph.html"), "w") do |file|
RubyProf::GraphHtmlPrinter.new(results).print(file)
end
When I preceed this script with rvm use 1.8.7 --patch ruby187gc, it creates the file "profile-graph.html" showing memory usage of all the different method calls in the script, as I'd expect. However, when I try something like rvm use 1.8.7#gemset_name --patch ruby187gc, the output file contains all "nan" values.
What gives? Is there some special trick to using a patched version of Ruby along with an RVM gemset? Does the problem lie elsewhere? I'm crossing my fingers and hoping that someone has run into a very similar problem and figured this out before.
Ah, I was overcomplicating things. Turns out I just needed to uninstall and reinstall the ruby-prof gem (after patching Ruby).
I used the instructions at http://bparanj.blogspot.com/2010/06/installing-ruby-191-on-snow-leopard.html to install Ruby version 1.92 on my Mac running Snow Leopard. The only deviation is in step 3, which calls for .bash_profile to be updated. I have .profile, but not .bash_profile, in my home directory, so I added the export command to the last line of .profile. The installation completed successfully (with the same two warning messages as mentioned, which I too disregarded), as Ruby -v in a terminal prints
ruby 1.9.2dev (2010-07-02 revision 28524) [x86_64-darwin10.4.0].
When I run Textmate, however, cntrl-R invokes Ruby version 1.8.7, as it did before the 1.9.2 installation. In Textmate's Preferences-Advanced-Shell Variables, TM_RUBY is set to /usr/bin/ruby. The (binary alias) file 'ruby' has not been updated. What is the easiest way for me to instruct Textmate to use the newer version of Ruby? Please note my understanding of OS X is relatively limited.
What is the easiest way for me to
instruct Ruby to use the newer version
of Ruby?
I believe you mean "What is the easiest way for me to instruct Textmate to use the newer version of Ruby?"
Assuming that is the case, have you tried to edit the TM_RUBY shell variable to point to your newly installed version? According to the docs you referenced, it should be somewhere under /usr/local (most likely /usr/local/bin/ruby).
You can find out the location of your ruby installation by typing the following in your terminal window:
$ which ruby
/usr/local/bin/ruby
then perform the following to verify the version
$ ruby -v
Once you have the proper ruby path, in Textmate, double-click the 'value' of the TM_RUBY shell variable & type in the path to your 1.9.2 install.
Why not just create a .bash_profile file in your home directory?