From: David Masover Date: 2009-12-13T08:57:34+09:00 Subject: Re: Is it possible to force a Ruby program to run as a proc name different than "ruby"? On Saturday 12 December 2009 05:29:25 pm Iñaki Baz Castillo wrote: > El Sábado, 12 de Diciembre de 2009, David Masover escribió: > > The usual approach I'd suggest here is, store a configfile path, > > something like the PATH variable, in which later configfiles override > > values set by earlier ones. Then, set all the default values in a sample > > config file inside your gem, and let the admin put a conf file in > > /etc/rb_app (or in ~/.rb_app, > > But can a gem installation generate a default conf file/directory in /etc? Short answer: no. > I know gem installations can generate runnable files into /usr/bin (or > /usr/local/bin). No, they can't. What they can do is provide a runnable file, which the gem system installs to wherever it's configured to install to. I have a completely separate user for each version of Ruby I install, each with their own gems -- my 1.9 rubygems install their scripts to /home/ruby19/home/bin. I like that, because it's easy enough to add and remove PATH elements, yet if something goes horribly wrong, I can always completely blow away /home/ruby19/home (the GEM_HOME path) and rebuild it. If I'd let it install binaries to the system path (/usr/bin or /usr/local/bin), it'd be much harder to sort out which were installed by gems and which weren't, unless I was willing to manually uninstall each one. But part of the point of doing it this way is that Rubygems itself might break, so that doesn't really work. So, basically, right now, Rubygems has explicit support for installing scripts into _somewhere_ in your path, just as it has explicit support for installing libraries into _somewhere_ into $: -- and in both cases, you, as a gem developer, have no control over where that will eventually be. > This is, I wouldn't like that the user has to create by > himself the config fiel/directory in /etc :( That's why I suggested creating a script that doesn't run on installation, but at the user's discretion. Or you could have it run when the app first launches -- Wine is like that. It looks like that's what you decided to do, though.