I explained the situation in detail in the following comment:

https://github.com/asciidoctor/asciidoctor-pdf/issues/208#issuecomment-114648212

The simple solution is to update your PATH environment variable so that it can see the launch script (e.g., asciidoctor or asciidoctor-pdf). Once the launch script is found, Ruby will handle the rest.

If you're on Cygwin, by default `gem install` will install the gem into your home directory. The launch scripts (aka binstubs) will end up in the bin directory. Thus, you need to add $HOME/bin to your PATH environment variable.

 $ export PATH="$HOME/bin:$PATH"

(Cygwin really should setup the PATH this way by default).

If you're in an environment where `gem install` installs the gem to system location, such as /usr/local/bin, then you need to add this path to your PATH environment variable instead.

 $ export PATH="/usr/local/bin:$PATH"

You shouldn't need to mess with GEM_PATH unless you want the gems to install to a different location than the default.

Different distributions (including Cygwin and OSX) like to setup Ruby differently. This is not really Ruby's fault. These distributions are just being difficult IMO...

which is why I like and recommend RVM (https://rvm.io). RVM manages the Ruby environment so that it just works. It rarely, if ever, lets me down.

Cheers,

-Dan

On Tue, Jun 23, 2015 at 11:11 AM, wolandscat [via Asciidoctor :: Discussion] <[hidden email]> wrote:

I'm not sure if the problems I have with getting gem paths to work properly are just generic ruby/gem problems but since a lot of gem installs are needed in asciidoctor, I thought I would ask here (after spending many hours scouring StackOverflow and similar places for help)...

I had a lot of trouble getting asciidoctor-pdf to run, because it installed in /usr/local/gems, but when I try to run it, it couldn't be found. gem env showed that /usr/local was indeed in the Gem path, but if I did

$ruby -r rubygems -e "p Gem.path"

it wasn't. I fixed this by doing 'export GEM_PATH=/usr/local:$GEM_PATH'. However, I would prefer to know how gem figures out its paths, and why ruby has different paths.

After this, I tried to get the compass stylesheet stuff going. Similar problem, except compass, sass etc all installed in my ~/.gem area (why?!?!) and then could not be found when invoking it. I moved it manually to /usr/local/gems, and copied the /bin scripts to /usr/local/bin, but still no luck. Using bundler appears to have messed with the paths.

If I get a new bash shell, and do 'gem env', I get 4 paths:

     - /usr/local
     - /home/Thomas/.gem/ruby
     - /usr/share/gems
     - /usr/local/share/gems

If I then do 'compass compile' I get this:

/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require': cannot                                                                     load such file -- compass (LoadError)
        from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:54:in `require'
        from /usr/local/bin/compass:20:in `block in <main>'
        from /usr/local/bin/compass:8:in `fallback_load_path'
        from /usr/local/bin/compass:19:in `<main>'

Compare this to ruby's idea of the paths:

$ ruby -r rubygems -e "p Gem.path"
["/home/Thomas/.gem/ruby", "/usr/share/gems", "/usr/local/share/gems"]

... no /usr/local!

But if I do 'export GEM_PATH=/usr/local:$GEM_PATH', I end up with only /usr/local as the GEM path according to gem env....

As you might guess, this situation is pretty irritating for someone who is a non-ruby/gem user! I have been unable to locate anywhere online clear information about how these paths are set, and why 'gem' and 'ruby' have different ideas of these paths. I have seen a lot of other posts relating to similar problems however.

Is the ruby/gems world really so arcane?

any help appreciated...

---

If you reply to this email, your message will be added to the discussion below:

http://discuss.asciidoctor.org/Gem-paths-craziness-on-cygwin-tp3425.html

To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML

--

Dan Allen | http://google.com/profiles/dan.j.allen