# Acts\_as\_ferret server\_manager fails under Capistrano

**URL:** <https://www.ruby-forum.com/t/acts-as-ferret-server-manager-fails-under-capistrano/144298>\
**Category:** Ferret\
**Created:** [July 28, 2008, 1:06pm UTC](https://www.ruby-forum.com/t/acts-as-ferret-server-manager-fails-under-capistrano/144298 "2008-07-28T13:06:05Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![johnlester](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@johnlester](https://www.ruby-forum.com/u/johnlester)\
**Post date:** [July 28, 2008, 1:06pm UTC](https://www.ruby-forum.com/t/acts-as-ferret-server-manager-fails-under-capistrano/144298/1 "2008-07-28T13:06:05Z")

</div>

Hi,

in lib/server\_manager.rb we have lines 38 and 39:

#require(File.join(File.dirname( **FILE** ),  
‘…/…/…/…/config/environment’))  
require(File.join(File.dirname(ENV[‘\_’]), ‘…/config/environment’))

This works fine if I run it in a normal shell but borks when the server  
is run using Capistrano:

\*\* [out :: [server-001.vm.brightbox.net](http://server-001.vm.brightbox.net)] no such file to load –  
/bin/…/config/environment

Confirmed here by someone else too:

> **[Capistrano and Ferret DRB](https://www.zorched.net/2008/06/19/capistrano-and-ferret-drb/)**

Any idea why ENV[‘\_’] is being used here rather than  **FILE**? Looks  
a bit like it’s supposed to work better when aaf is installed as a gem,  
rather than as a plugin in the vendor dir (as I’m using it here).

Actually, it looks like this is good behaviour by aaf and bad behaviour  
by Capistrano, but was wondering if anyone can shed any light on it.

Thanks,

## John.

[http://johnleach.co.uk](http://johnleach.co.uk)

---

<div class="post-metadata">

**Author:** ![johnlester](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@johnlester](https://www.ruby-forum.com/u/johnlester)\
**Post date:** [July 28, 2008, 2:25pm UTC](https://www.ruby-forum.com/t/acts-as-ferret-server-manager-fails-under-capistrano/144298/2 "2008-07-28T14:25:21Z")

</div>

Fixed!

> From the bash man page:

“When bash invokes an external command, the variable \_ is set to the  
full file name of the command and passed to that command in its  
environment.”

cap\> on [server-009.vm.brightbox.net](http://server-009.vm.brightbox.net) ruby -e “puts ENV[‘\_’]”  
\*\* [out :: [server-009.vm.brightbox.net](http://server-009.vm.brightbox.net)] /bin/sh

Found a solution though. Setting the following option in my Capistrano  
recipe:

default\_run\_options[:shell] = false

gets me:

cap\> on [server-009.vm.brightbox.net](http://server-009.vm.brightbox.net) ruby -e “puts ENV[‘\_’]”  
\*\* [out :: [server-009.vm.brightbox.net](http://server-009.vm.brightbox.net)] /usr/bin/ruby

Now the ferret\_server runs properly. This change hasn’t affected  
anything else for me - according to the Capistrano 2.1 announcement, if  
your default shell is POSIX compliant it should be fine (most cases I’d  
guess this is true, unless you have some weird setup).

[http://groups.google.com/group/capistrano/browse\_thread/thread/531ad32aff5fe5a8](http://groups.google.com/group/capistrano/browse_thread/thread/531ad32aff5fe5a8)

For reference, the code to use ENV[‘\_’] was added here:

[http://projects.jkraemer.net/acts\_as\_ferret/ticket/185](http://projects.jkraemer.net/acts_as_ferret/ticket/185)

Hope that helps someone.

John.

On Mon, 2008-07-28 at 11:55 +0100, John L. wrote:

> \*\* [out :: [server-001.vm.brightbox.net](http://server-001.vm.brightbox.net)] no such file to load – /bin/…/config/environment  
> by Capistrano, but was wondering if anyone can shed any light on it.
> 
> Thanks,
> 
> ## John.

–  
[http://johnleach.co.uk](http://johnleach.co.uk)

---

<div class="post-metadata">

**Author:** ![johnlester](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@johnlester](https://www.ruby-forum.com/u/johnlester)\
**Post date:** [July 29, 2008, 5:16am UTC](https://www.ruby-forum.com/t/acts-as-ferret-server-manager-fails-under-capistrano/144298/3 "2008-07-29T05:16:37Z")

</div>

I’ve came across that same issue a few times. I solved it by  
uncommenting line #38 and commenting #39.