I was trying to find the list of command-line arguments available for the ruby executable in http://ruby-doc.com/ but I could not find anything. After a Google search for "ruby interpreter command line options" I could only find this page, which applies to Ruby 1.4 only. Where can I find the documentation for the ruby executable in an 'official' source, like ruby-doc.com? Thanks!
Easiest option is to run man ruby. It will show your locally installed interpreter options.
Definitive option is the ruby repository on GitHub. Navigate to the version you need in the releases and locate man/ruby.1 file in the tree. The file contains definitions for CLI arguments.
Example: Ruby 2.3.0 interpreter CLI arguments definitions are here.
There is no such thing as "the Ruby executable". Every Ruby implementation has their own commandline executable. (Actually, come to think of it, SmallRuby and BlueRuby didn't have a commandline executable at all.)
And every Ruby implementation has their own commandline flags. That's why there cannot be a document explaining all the options: which implementation's options would that document?
For example, JRuby's --jdb flag to run under the Java Debugger simply doesn't make sense for IronRuby, Rubinius, MacRuby, Topaz, Cardinal, MRuby, or YARV. Rubinius's flag to turn on the sampling profiler doesn't make sense for implementations that don't have a sampling profiler. Rubinius's flag to turn on the native code JIT compiler doesn't make sense for implementations that don't have a native code JIT compiler. And so on.
However, there are a couple of options that most implementations agree on:
-0
-a
-c
-C
-d
-e
-E
-F
-i
-I
-l
-n
-p
-r
-s
-S
-T
-v
-w
-W
-x
BUT!!!
If you look at MRuby, which is the Ruby implementation written by Yukihiro "matz" Matsumoto, Ruby's creator, which is intended to be a lightweight implementation of the minimum core that can still be called "Ruby", it only supports these options:
-b load and execute RiteBinary (mrb) file
-c check syntax only
-e 'command' one line of script
-v print version number, then run in verbose mode
--verbose run in verbose mode
--version print the version
--copyright print the copyright
Of these, -b is clearly implementation specific, and -c, -v, --version, and --copyright have no runtime impact, so we can interpret this as meaning that -e is the only option that must be supported by a conforming Ruby implementation … after all, it is the only option supported by the Ruby implementation written by the only person who can legitimately have a say in what it means to be "a Ruby implementation".
Related
According to gcc manual, the -E option only preprocesses the .c source file, without running the compiler and just giving an input file (.i). But what does the -E stand for?
Summary
This option was introduced on compilers much earlier than GCC, and GCC used the same naming for compatibility.
My best guess from the historical evidence is that -E stands for "expand macros".
The authors of those earlier compilers couldn't call it -P because there was already a -P option, which also ran only the preprocessor, but wrote the output to .i files instead of to standard output. -p was also taken.
Over time, -E became preferred to -P, and when GCC was written, it supported only -E and not -P.
Despite being supposedly off topic for Stack Overflow, I think a bit of history will help explain how this option got its name.
gcc(1) inherited its basic command line options from much earlier Unix C compilers. Many versions can be found in the Unix Tree archive.
It looks like the first version that supported -E was Research Unix V7, circa 1979: cc(1) source, man page source. There was also a -P option that also just ran the preprocessor, but sent the result to a file foo.i instead of to standard output. V6 had already supported -P but not -E: cc(1) source, man page source.
This at least answers why -E wasn't named -P instead: because -P was already in use. (And -p was also taken, it was used to request profiling.) The only hint I found as to why -E was chosen is that the corresponding flag variable in the source code is named exflag. I would hazard a guess that this stands for "expand", as what -E does is basically to expand macros.
It appears that -P was eventually deprecated in favor of -E. V8 still supported it, but omitted it from the man page. V10 (circa 1989) included two versions of the compiler, cc which compiled traditional C, and lcc for ANSI C. The man page says that cc supports -P with the preprocessor behavior, but for lcc, -P did something else ("write declarations for all defined globals on standard error"). They both supported -E. On other fronts, 32V and BSD, at least initially, supported both, but -P would emit a warning that it was obsolete and -E should be used instead.
It looks like gcc, from its earliest version, only supported -E and not -P. Since then, a -P option has been introduced, but it does something else ("inhibit generation of linemarkers").
I've seen this used to start a process:
ruby -run
What does it do?
Where is the documentation located?
It's a little misleading in appearance... The flag isn't -run as in the verb run, but rather -r to require the un.rb file from the standard library, which according to documentation, contains:
Utilities to replace common UNIX commands in Makefiles etc
The -r<libraryname> flag allows you to require a library from the command line before your program's execution begins.
See ruby --help for the command line flags (I suspect you already did).
I'm using Getopt to parse commandline arguments in commands.ml. So the first line of commands.ml looks like this:
open Getopt
I can't seem to figure out how I compile commands.ml with this module. I've tried so many things and I always get the following error:
File "commands.ml", line 1, characters 5-11:
Error: Unbound module Getopt
I have added #require "Getopt" to my .ocamlinit file.
You say you're using Getopt, "so" you have open Getopt in your code. But there's no direct connection there. It's more usual (and in my opinion usually better) to use modules without opening them.
The use of open only controls the names available in the containing module. It doesn't tell the compiler where to look for the opened modules.
There's no Getopt module in the standard OCaml library. The standard module for parsing command lines is named Arg. If you're using an external library, you need to use the -I flag to tell the compiler where to look for it.
The .ocamlinit file controls the behavior of the OCaml toplevel (the read-eval-print interpreter). It doesn't affect the behavior of compilers.
If you're using a building tool, there are probably easier ways to set things up. But you'll need to explain your build environment more carefully.
The problem, that there're lots of answers to your question. Depending on what build system you chose, there will be different commands. And that is the reason, why we are asking. But it looks like, that you have no preference, so let me try to give you some answers.
With ocamlbuild
$ ocamlbuild -package getopt commands.native
With ocamlfind
$ ocamlfind ocamlopt -package getopt commands.ml -o commands.native
For more explanation read the following.
Personal advice: if you're unsure on what to choose, then use ocamlbuild.
Use ocamlfind with your preferred compiler (I'm using ocamlopt below), like so:
ocamlfind ocamlopt -package getopt -linkpkg commands.ml -o commands
This will still fail if you don't have getopt installed. Getopt may be installed with opam:
opam install getopt
I would like to suggest that you use Arg instead. It's part of OCaml's standard library, and is generally pleasant to work with.
gcc (or other compilers) often generate huge text output and it's very difficult to see where the error is or miss warnings. I've done some search but havn't found a clean simple solution to color code the compiler output (so for instance warnings are yellow, errors are red, etc...)
Gcc 4.9 seems to have added this feature via the -fdiagnostics-color flag:
here's an alternative if you are looking for something very simple:
#!/bin/bash -e
make ${#} 2>&1 | perl -wln -M'Term::ANSIColor' -e '
m/Building|gcc|g++|\bCC\b|\bcc\b/ and print "\e[1;32m", "$_", "\e[0m"
or
m/Error/i and print "\e[1;91m", "$_", "\e[0m"
or
m/Warning/i and print "\e[1;93m", "$_", "\e[0m"
or
m/Linking|\.a\b/ and print "\e[1;36m", "$_", "\e[0m"
or
print; '
Just alias your make to this script and make sure it's executable...
Debian and Ubuntu gives the colorgcc package for that purpose.
And I usually run gcc (and make) thru emacs with M-x compile then the messages are colorized.
addenda
GCC 4.9 has a native colorization facility and GCC 6 - released end of April 2016 - (and probably GCC 5 too) is enabling it by default (when stdout is a terminal).
Ok, I'll just leave a notice about my own (python based) tool also :)
It is called Pluggable Output Processor and designed not only to colorize output of one particular program. Here is sample GCC output before:
After:
See colorgcc, a perl script that coulours the gcc output.
How to install and use colorgcc to colorize your gcc compiler output:
At least 3 answers here so far mention colorgcc, but NONE OF THEM EXPLAIN HOW TO INSTALL IT! (And it's not obvious). So, here's how to install the latest version in Ubuntu!
Go here and click "Clone or download" --> "Download Zip". I saved it into "~/Downloads/Install_Files"
Navigate to it in your file browser and right click it and go to "Extract Here." I now have a directory called "~/Downloads/Install_Files/colorgcc-master".
Copy the "colorgcc.pl" script to "/usr/bin/colorgcc" to "install" it (be sure to use the correct directory according to where you extracted it above): sudo cp ~/Downloads/Install_Files/colorgcc-master/colorgcc.pl /usr/bin/colorgcc
Make it executable: sudo chmod +x /usr/bin/colorgcc
Make the "~/bin" directory if it does not yet exist: mkdir ~/bin
*Make symbolic links that point to "/usr/bin/colorgcc" so that whenever you call gcc or g++ it automatically calls colorgcc instead:
ln -s /usr/bin/colorgcc ~/bin/g++
ln -s /usr/bin/colorgcc ~/bin/gcc
(if you ever want to uninstall colorgcc for some reason just delete these symbolic links "~/bin/g++" and "~/bin/gcc", and the Perl script: "/usr/bin/colorgcc" and you're done)
Done!
Here is a sample g++ output now when I call g++ -Wall -std=c++11 time_until_overflow_2.cpp -o time_until_overflow_2:
*Note: making these symbolic links in "~/bin" only works if "~/bin" is in your PATH variable in a location before the folder where the actual gcc and g++ executables are located. To ensure you have "~/bin" in your path you can view the PATH variable contents with: echo $PATH. If you don't see "/home/YOUR_USERNAME/bin" at the beginning of your path, add it with: export PATH=~/bin:$PATH.
References:
See here for more info. and for where I originally learned most of these steps: https://imranfanaswala.wordpress.com/2009/02/02/setting-up-colorgcc/. Thanks Imran Fanaswala!
~GS
you can use GilCC which is a Ruby tool that will convert GCC output to color in real-time. Right now you have two choices: Perl script (colorGCC) or GilCC and if you already work with Ruby you will like GilCC.
Unique to GilCC; GilCC has warning and errors counters and also shows compile time, very handy when you are trying to improve things. Because it is in Ruby it is cross platform. It is flexible and you can add more gems to customize it anyway you want.
The link to the download page is here.
https://github.com/gilmotta/GilCC
Although GCC 4.9 has -fdiagnostics-color option to enable colored outputs to terminals, I have created a tiny tool called 'crror' to get colorized compiler output.
It supports outputs from make as well. I can add colorize patterns for other tools if anyone requires.
I've recently started using thor. I've set my script up with some global options, such as -l --logging and -v --verbose. I'd like users to be able to call my thor task with -lv rather than -l -v, but this doesn't seem possible.
There are several items in the standard library and should help you support Unixy flags/command-line arguments:
getoptlong is reminiscent of Perl's GetOpt library, so if you've used that (or one of the many clones in other languages) that may be easy for you.
Otherwise, optparse is more Ruby-ish, and thus might feel more natural to use.