What's the easiest way to cause a segfault intentionally in MRI Ruby 1.8.7?
You might check out segfault4r (it was last updated in 2007). You have to download and install the gem manually, as it's not available through RubyGems.
You could write a bad C module that de-references a NULL pointer.
Depending on your needs (and environment) you could get it running, find the interpreter's process ID and do:
$ kill -s SIGSEGV $pid
I just tried this on OSX with bash and it worked on an ed(1) (the one true text editor) process.
You could also run Ruby in a debugger and manually set a pointer or two to zero. One of the pointers inside a variable would do nicely. Of course, you'd probably need to have an interpreter built with debug symbols and you'd need to know a thing or two about the interpreter's internals.
If you're doing this against a specific patchlevel, look at Ruby's bug tracker for bugs that were reported after that patchlevel was created that cause a segmentation fault. As you're looking at 1.8.7, you'll probably want to look at those categorized as Ruby 1.8 .
For example, for the version of Ruby (1.9) I have on my Windows machine, Thread.kill(nil) is sufficient to cause a segfault, and I think it applies to Ruby 1.8 as well.
Related
I'm trying to figure out a way to determine the ABI compatibility level (i.e. the minor version) of the Ruby installation on any given machine.
I know that I can determine the full version number by running "RUBY_VERSION" in irb - for example, on my machine, it would currently return "2.6.5". But I'm looking for a solution that will tell me just the minor version - so for both 2.6.5 or 2.6.6, I'd simply want "2.6.0" as the output.
Is there a straightforward way to get this info, short of simply trimming the full version and appending a .0?
There is no way I know of to get the ABI compatibility level programmatically.
However, given your comments, it seems that you are not actually caring about the ABI compatibility level but about the RubyGems Gem installation path. Since this path can be configured by the user in a configuration file, environment variable or command line argument, I think it would make much more sense to ask RubyGems for the Gem installation path using the Gem::dir method instead of asking Ruby for the ABI compatibility level:
Gem.dir
#=> "/usr/local/lib/ruby/gems/2.7.0"
I'm creating a gem that utilizes SGR codes. There are discrepancies between terminals that I've found myself. E.g. \e[2m makes faint text in Ubuntu's gnome terminal, but \e[2m does nothing in Windows 8.1's Command Prompt With Ruby. So my ruby program needs to know what terminal it is running in and from there, utilize (or not utilize) certain sgr codes.
Is there a magic bullet, in pure ruby or hopefully with a gem, for finding out what terminal we're running in? And I mean any terminal, no matter how exotic. I'd love be able to do this, depending on the terminal we're running my gem in (This is pseudo-code, MagicBullet is a class belonging to the gem I'm hoping you'll refer me to):
MagicBullet.identify #=> ['gnome-terminal', '6.3.2']
Or:
MagicBullet.identify #=> ['konsole', '4.5']
Or:
MagicBullet.identify #=> ['command-prompt', '13.37']
Or:
MagicBullet.identify #=> ['NeWT', '15.2']
Is there a a sure-fire way to find out regardless of OS...this information feels so readily available...maybe a gem that looks for a range of OS signals/processes that belong to a list of known terminals, something like that. I've tried ENV['TERM'], and while that returns :xterm in a gnome-terminal, I'd prefer it to return :gnome-terminal. In Command Prompt With Ruby it returns nil, which isn't very helpful considering all non-linux (I think) terminals will return nil. Of course, I could run if !ENV['TERM'] and then utilize a different set of logic to find the terminal's name, but that doesn't feel "sure fire" to me. It'll probably fail with other "exotic" terminals.
So I'd like, as an answer, either:
A gem that gives a sure-fire way to identify what terminal and what version we're running
A pure ruby way to give a sure-fire way to identify what terminal and what version we're running
An algorithm that gives me a pretty good shot at identifying what terminal and version we're running, and I'm talking all flavors of Linux, Sun Microsystems stuff, Apple's operating systems (Terminal and the third-party iTerm are two terminals for Apple's operating systems for example). Anything that MRI can be installed on.
As you may tell from the screenshot I have included. I'm trying to get rbenv ruby 2.1.2 to replace the system ruby on Raspberry pi and there's no earthly reason it should still be pointed at 1.9.3!
Thanks to a lot of help from #dteoh, I was finally able to ascertain how this happened.
As it turns out, when I was doing my rbenv install 2.1.2 the process was taking so long I went to bed. I didn't put it together until the ~/.rbenv/shims was empty, but one of my digital clocks was blinking. Apparently that night I lost power in the night, which put it in some strange state.
The fix was blowing away the Ruby version and doing another (long) but successful Ruby build.
Thank you for your patience in this RARE but troublesome situation.
run rbenv version, you may find that a env var named RBENV_VERSION was set, after unsetting the env var using export RBENV_VERSION=, you will have the correct ruby version
My question is, why does rubygems on Ubuntu not add /var/lib/gems/1.8/bin to $PATH ?
I see in the
https://help.ubuntu.com/community/RubyOnRails#Installing%20RubyGems
page that it says you have to add it yourself, but I don't understand why there is an extra step.
Testing it on a Debian system, rubygems does does not make the modification to $PATH automatically.
I'm wondering if this is a bug, or if I'm misunderstanding something - I know Ubuntu and Debian have many differences, perhaps this is just one of them.
I posted the question to answers.launchpad.net but have not yet gotten any response.
RubyGems never adds anything to the $PATH, whether on Ubuntu or otherwise. Nor does APT (or any other packaging system I know).
The $PATH variable is clearly in the user's domain. No program should ever mess with it.
See https://bugs.launchpad.net/ubuntu/+source/gems/+bug/145267. Basically, the Ubuntu team has known about this problem for years, but a bunch of infighting has prevented any progress from being made.
so I made a program in ruby (using FXRuby as well if that changes anything) and I was wondering how I would compile it so that another person could download and use the program? Thanks
You don't need to compile it you can just run it as a ruby script,
start your file with #!/path/to/your/ruby/interpreter/bin
after changing it to the appropriate file and it should just launch from the command line
$ chmod +x ./my_ruby_script
$ ./my_ruby_script
However if you are devloping a full fledged application in ruby for the mac then consider using MacRuby which provides ruby-cocoa bridge. It can be found here
Ruby is interpreted, not compiled. The code itself will be what runs on another person's computer, provided they have a Ruby interpreter.
A quick Google search, however, turned up this. I've never used it, but it's an interesting idea. Basically it wraps the Ruby application code with the executable(s) and library(s) needed to run it into one single all-encompassing application.