Is it possible to force a Ruby program to run as a proc name different than "ruby"?

ISSSSaki_Baz_C · December 13, 2009, 12:58am

On Saturday 12 December 2009 05:29:25 pm IÃ±aki Baz C. wrote:

El SÃ¡bado, 12 de Diciembre de 2009, David M. 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.

ISSSSaki_Baz_C · December 13, 2009, 1:55am

El Domingo, 13 de Diciembre de 2009, David M. escribiÃ³:

1.9 rubygems install their scripts to /home/ruby19/home/bin.
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.

Clear now, thanks a lot.

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.

Yes, thanks to this thread

ISSSSaki_Baz_C · December 13, 2009, 12:15pm

On 13.12.2009 00:51, Iñaki Baz C. wrote:

exit 1
sleep 2

File.open(pid_file, File::EXCL | File::WRONLY | File::CREAT) {|io|
io.write($$)}
trap(0) {File.delete pid_file}

puts “OK, here we go.”
Let me a question: is the above a fragment of a Linux init script written in
Ruby (rather than bash/sh as usual)?

That was hacked together for demonstration purposes. It was not
intended as an init script but rather as the demon itself - albeit
without all the demonization stuff (detaching from terminal etc.)
because I wanted to focus on the aspect of pid file handling and
killing.

If so, according to LSB specifications it should return 0 (success) in case of
“start” action when the daemon is already running.

Well, if you write a start script for that “ruby demon” you would have
to handle exit codes properly.

Kind regards

robert

ISSSSaki_Baz_C · December 13, 2009, 3:22am

IÃ±aki Baz C.:

I suffer same issues. I’ve installed ruby 1.9.1 (installed from
sources) under /usr/local. and ruby 1.8.7 (Debian package) under /usr.

I compile ruby1.9 with these options:
/configure --prefix=/usr/local/ --program-suffix=1.9 ; make ; make install
so all its runnable files are sufixed by 1.9 (ruby1.9, gem1.9, irb1.9…).

I think a much simpler solutions are to either (a) use rvm (which
doesnâ€™t work for me for some reason) or (b) use my approach (below).

I donâ€™t use program suffixes, but rather use

./configure --prefix=/home/shot/opt/ruby-1.9.1-p376

(and similar, for example ~/opt/ruby-1.8.7-git when building 1.8.7 from
the repoâ€™s latest 1.8.7 revision) plus ~/opt/ruby-1.8 and ~/opt/ruby-1.9
symlinks poiting to the hand-compiled versions I want to use for my
development. I then have

export PATH_ORIG="$PATH"

at the end of my ~/.bashrc and

alias r18=‘export PATH=/home/shot/opt/ruby-1.8/bin:$PATH_ORIG’
alias r19=‘export PATH=/home/shot/opt/ruby-1.9/bin:$PATH_ORIG’

in my ~/.bash_aliases, and switching between Ruby 1.8 and 1.9 is as
quick as running â€˜r18â€™ and â€˜r19â€™ in the shell. I leave system-packaged
Ruby alone, if only so that â€˜gem update --systemâ€™ works sanely (and so
no sudo is required for any of my Ruby development whatsoever).

Of course, if you want to have system-wide hand-compiled Ruby 1.8 and/or
1.9, putting them in /opt (rather than ~/opt) might be more elegant.

â€” Shot

ISSSSaki_Baz_C · December 13, 2009, 1:57pm

El Domingo, 13 de Diciembre de 2009, Shot (Piotr S.) escribiÃ³:

doesnâ€™t work for me for some reason) or (b) use my approach (below).
export PATH_ORIG="$PATH"

Of course, if you want to have system-wide hand-compiled Ruby 1.8 and/or
1.9, putting them in /opt (rather than ~/opt) might be more elegant.

This is a very nice solution. However the problem is that I need ruby1.8
deb
package isntalled in my system as many other packages require ruby1.8,
and it
is installed under /usr/ as usual.

ISSSSaki_Baz_C · December 13, 2009, 1:56pm

El Domingo, 13 de Diciembre de 2009, Robert K.
escribió:> >> $stderr.puts “ERROR: already running with PID #{old_pid}”

they would be a new instance. Uncomment sleep to simulate:

That was hacked together for demonstration purposes. It was not
intended as an init script but rather as the demon itself - albeit
without all the demonization stuff (detaching from terminal etc.)
because I wanted to focus on the aspect of pid file handling and killing.

Ok ok, I just asked as curiosity because some time ago I tryed to do a
init
script in Ruby and couldn’t do it properly… not remember the reason
right
now…

If so, according to LSB specifications it should return 0 (success) in
case of “start” action when the daemon is already running.

Well, if you write a start script for that “ruby demon” you would have
to handle exit codes properly.

Ok, so later the init script could get “1” and return “0” as LSB states.

Thanks a lot again.

ISSSSaki_Baz_C · December 13, 2009, 3:20pm

On 13.12.2009 13:55, Iñaki Baz C. wrote:

$stderr.puts "ERROR: already running with PID #{old_pid}"
they would be a new instance. Uncomment sleep to simulate:
without all the demonization stuff (detaching from terminal etc.)
because I wanted to focus on the aspect of pid file handling and killing.
Ok ok, I just asked as curiosity because some time ago I tryed to do a init
script in Ruby and couldn’t do it properly… not remember the reason right
now…

One small thing just comes to mind: you can replace the “trap(0) {…”
with “at_exit {…”. This is probably a bit more rubyish. It also has
the advantage that you can have multiple at_exit handlers while you can
only have one trap:

robert@fussel ~
$ ruby19 -e ‘2.times {|i| at_exit { puts “exiting #{i}…”} }’
exiting 1…
exiting 0…

robert@fussel ~
$ ruby19 -e ‘2.times {|i| trap(0) { puts “exiting #{i}…”} }’
exiting 1…

robert@fussel ~
$

If so, according to LSB specifications it should return 0 (success) in
case of “start” action when the daemon is already running.
Well, if you write a start script for that “ruby demon” you would have
to handle exit codes properly.

Ok, so later the init script could get “1” and return “0” as LSB states.

Exactly.