So ruby 1.9 is really nice in that it'll automatically require rubygems, and hence when you call require 'somegem' without first requiring rubygems it'll work, and that's generally awesome.
But I have a ton of shell scripts using ruby, and they generally don't rely on rubygems. Shell tools should run instantly, and loading rubygems for nothing is a major drag, mostly because it involves a bunch of disk operations with scattered small files.
I want to be able to tell ruby, when running these shell scripts, to skip loading gems. Ideally, something like #!ruby --no-rubygems in the shebang line.
Is there such a thing? Or maybe a compile option that'll tell ruby rubygems must be required manually?
Yes, you can use the --disable-gems option.
Note that whether or not passing options in the shebang line works depends on your operating system. Some operating systems don't support passing options at all, some only support passing one option or argument.
So, if you have for example
#!/usr/bin/env ruby
Then it's pretty unlikely that you will be able to attach the option to the end. If OTOH you change that to
#!/usr/local/bin/ruby --disable-gems
Then you have hardwired the location of the Ruby binary into your script.
And of course there are operating systems that don't interpret shebang lines at all. (After all, they were never specified in any standard, and aren't even properly documented.)
An alternative would be to set the RUBYOPT environment variable in your shell environment and simply switch to a different environment with RUBYOPT unset (or set to -w, my personal favorite) for your Ruby development.
Related
I just started learning Ruby and I ran this command:
vim --version
The output looks like this (look at the yellow circle):
Which means that my Vim does not include the 'ruby' function.
But it seems my Vim supports Ruby fairly well:
q1: Is there any problem with my Ruby programming with the -ruby?
q2: How can I enable Ruby function in Vim?
The functionality on the second screenshot is given by installing the vim-ruby plugin.
The internal Ruby support is to allow people to write plugins and scripts for Vim using Ruby and it's not strictly necessary for what you seem to want to accomplish.
If you REALLY want to add Ruby support, you can always build Vim from source (or get a package with it already built). I suggest you to look into Vim's homepage for more info on this matter.
The difference you are missing is between using Vim to program in a language such as Ruby, and using a given language to program Vim.
Writing Ruby code using Vim is enabled by Vim's native syntax files, as well as various third-party plugins available for Vim. This is the case for many, many languages, not only those mentioned in the :version screen (Perl, Python, and Ruby). You can use Vim to write code in C, Scala, PHP, Javascript, and many other languages, with support for syntax highlighting, smart indenting, and so on.
Writing Vim functions and plugins can only be done in a small set of languages. Natively, Vim code is always written in its own language, Vimscript. However, Vimscript is notoriously difficult to deal with, and most people will not already know it. So Vim also has the ability to use plugins written in other languages, such as Python or Ruby. This enables people to use a more familiar language for plugin development.
However, using those languages requires binding to an interpreter for the language, and this must be decided at the time Vim is compiled. The :version screen is telling you that for your installation of Vim, the Ruby support was not enabled, so you can not write plugins using Ruby, nor can you use any available plugins which were written in Ruby.
Notice that +python is present, so you can use Python plugins (but -python3 is there too, meaning that you do not have Python 3.x support built in).
Confused a little on ruby. I know it makes .rb files, but does it make exe or com files or is it just used as as web application?
I know a bit writing the code, but what to do with the files after.
the question is a bit too broad.
you have to step back and look at how source code in general ends up being executed (i.e. it is used).
In case of some programming languages (e.g. C/C++) it's compiled to a native form and can be executed directly afterwards;
In case of other languages it's compiled to an intermediate form (e.g. Java/C#) and executed by a vm (jvm/clr)
In case of yet other languages is interpreted at runtime (e.g. Ruby/Python).
So in the specific case of Ruby, you have the interpreter that loads the rb files and runs them. This can be in the context of standalone apps or in th e context of a web server, but you almost always have the interpreter making sense of the ruby files. you don't get an executable the same way as the you get for languages that are compiled to machine code.
Normally you just run the .rb file in the shell or command prompt. For example in the windows command prompt:
C:\path\> ruby filename.rb
This will execute the filename.rb file from the command prompt.
If you need to run a ruby program on a computer without a ruby installation there are a few options out there.
Try this website:
https://www.ruby-toolbox.com/categories/packaging_to_executables
I personally have used OCRA to pass a program to relatives who are less computer literate. It was pretty straight forward,I haven't tried the other tools.
Good luck,
I am running within a Ruby script (a Vagrantfile, specifically) and I want to invoke another ruby executable (berks installed against system ruby, specifically). I know I can do something like
PATH=/usr/bin GEM_PATH=/var/lib/ruby/1.9.1 berks ...
But, that's not very portable. (Different machines will need different GEM_PATH, for instance). So, how can I invoke a script installed against a different Ruby environment from within a Ruby script?
Well, the task at hand sounds not-very-portable, since its entire reason for being is a system-specific quirk of different Rubies being installed in different places. Not all systems will even have those specific Ruby versions.
It sounds to me like your best bet would probably be to allow the user to set certain environment variables (I dunno, $BERKS_SUBRUBY_PATH or something) and use those if they are set. That way anyone who needs to use the workaround has an easy way to do so, but you're not forcing everybody to have the same system config.
Whenever I write shell scripts (mostly software development utilities or build tools) I've generally tried to avoid using bash in favor of using plain old sh for portability. However lately I've been running into more and more issues where useful features are not available, or behavior is actually less consistent across systems using sh then it is using bash, since sh is aliased to different shells...
As I understand it, sh is the oldest Unix shell and carefully written sh scripts should in theory run on pretty much any system out there... but it also seems there are about 9000 different variants of every major shell, too. Doesn't using bash as your script interpreter effectively limit your script's portability? Sure, no problems on OS X or pretty much any Linux out there, but what about the BSDs? Solaris, AIX, HP-UX? What do you do if you really want to run on everything?
I know bash can be installed on virtually any OS but it is really a first class citizen on all relevant modern systems? Does it come pre-installed? I'm just not really sure whether it's best to avoid or embrace bash with the intent of having the most consistent and portable overall experience.
What do you do if you really want to run on everything?
You follow the POSIX standard for sh (and the tools you're calling) and hope that the target OS does so too. Any modern product called "UNIX" must follow this standard, and customarily (though not universally), the standard shell will be called /bin/sh. The BSDs and Linux distros tend to aim at POSIX compatibility as well.
Doesn't using bash as your script interpreter effectively limit your script's portability?
Yes, but it depends on your target audience as you noted. If it's a short script, it's worth testing under dash (Ubuntu and Debian's default shell) for POSIX compatibility.
Whenever I start thinking about portability issues in my shell script, I switch to another language. Perl is widely available and generally a good choice for scripts, but if your tools are to be consumed by Python, Ruby, $lang developers, use $lang to its full potential.
bash itself is just a plain C program, does not need special authority to run, can be put in any location. You can easily build it from source. Basically, you can run bash if you need to and doesn't need the administrator of the system to install it.
As long as it is in your path, you can always code your script with the line.
#!/usr/bin/env bash
What are the benefits of using FileUtils methods http://ruby-doc.org/core/classes/FileUtils.html than the equivalent Bash commands?
Over and above the fact that you don't have to worry about ensuring your target platform has the specific tools you're using installed, and over and above the problem of doing proper quoting of shell oddities (especially problematical if you target both Windows and Unix-alikes -- Cygwin, GNUWin32, etc. notwithstanding), if you use Ruby's FileUtils you have the moderately-sized overhead of a Ruby function call while if you use external utilities you have the rather sizable overhead of firing up an external process each and every "call".
The FileUtils methods work on Windows.
They are easier to call from inside Ruby scripts because they accept Ruby objects as arguments. This means that you don't have to handle escaping and what not every time you call them.
when you farm stuff out to the shell, you are adding a dependency on those apps. FileUtils is pure ruby, so it works (and works the same, more or less) anywhere that ruby works.
Works across multiple platforms
Does not spawn a new process to issue the command (so it consumes less resources)
I would not say there is no benefits in using Ruby's FileUtils, since you can use them anywhere you have Ruby( especially if your task is in web development). But that does not mean you can't use those shell tools in other platforms as well. Yes, you can write your scripts in *nix shell, and you can run them as well with little or no modification in, say, Windows using cygwin or GNU win32.(and others).
In terms of benefits of Ruby's FileUtils against shell's, its only minimal, since what you can do with FileUtils you can do also with shell's.