ChadDavis wrote:
Then I probably am not following what you're doing. You don't show the shebang lines in this message, but I thought you wanted your application to use a custom wrapper script, and not run the packaged ruby1.8 directly. On my system /usr/bin/ruby1.8 is a binary, and not a shell script as I thought you were showing.I replaced the ruby1.8 binary, in /usr/bin, with a wrapper script that sets an environment variable and then invokes the binary, which I moved to /etc/alternatives ( perhaps not exactly the way alternatives is meant to be used, but I'm kind of a noob )Here's the wrapper script: #!/bin/sh export RUBYOPT=rubygems exec /etc/alternatives/ruby1.8 "$@"This script is at /usr/bin/ruby1.8 Let me know if I'm doing something bizarre. It's actually my effort at doing things the *right* way, so any advice would be accepted and welcomed.
Putting the original executable in /etc/alternatives is not a good idea. The script you put in /usr/bin may get overwritten at some point, with a security update, but still be at version 1.8, so you'd end up without your wrapper, at least, and perhaps still running the binary you moved, without the fix.
I'd also ask, which I forgot in my first response to your question, is this something that needs to be done for all users on your system or is it a personal script?
I think the Debian policy in this case would guide you only if what you're doing is for all users of the system. If you're doing this for yourself, most UNIX/Linux users I know would create an alias or function to do it, in their own work space (~/bin, ~/.aliases, etc).
-- Bob McGowan Symantec, Inc.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature