[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Mac OSX Ruby Configuration Question

Dave Howell

7/20/2006 8:08:00 AM


On Jul 18, 2006, at 8:33, Ryan Raaum wrote:

3) Two days ago, I once again had a Ruby program fail because it's
running the wrong Ruby, and I eventually had to give up on this one. My
text editing program lets me run text through shell scripts as text
filters; so I wrote a Ruby script to pretty-format HTML. Except I can't
run it, because all the gems are installed into 1.8.4. The scripts
inherit their environment from the text editor, which inherits it from
the Finder, which does not use ~/.bash_login, nor /etc/profile, nor
/etc/bashrc, nor any other file which I can find on my system.

[It's using SOMETHING, because it has
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/Users/dave, which isn't what you
get from "bash --noprofile"]

Configuring ~/.MacOSX/environment.plist will probably help this one.

Alas, I have no such file on my system. Nor even a ~/.MacOSX directory.

$ cd ~/.MacOSX
-bash: cd: /Users/dave/.MacOSX: No such file or directory

Today, in 10.4, the unix way works most of the time

Note that I do not run 10.4. There was insufficient value compared to
cost to justify upgrading from 10.3, especially since reliability is
greatly enhanced through consistency, and running 10.4 would mean
upgrading 4 systems to OSX 10.4, and one to OSX 10.4 Server, a
monumental expense. So I'm keeping all my systems synchronized on 10.3
for now.

I believe that most of the time, it is best to recommend the unix way of
doing things as that knowledge will both continue to be useful on OS X
and is transferable to other unices.

Unlike most of the people on this list, I have every intention of
avoiding "other Unixes." A solution that is specific to OSX with
greater reliability is significantly more valuable to me than one that
applies to Unix in general but only works "most of the time" on OSX.

Your Mileage May Vary.
7 Answers

Mat Schaffer

7/20/2006 12:39:00 PM

0

On Jul 20, 2006, at 4:08 AM, Dave Howell wrote:
> Configuring ~/.MacOSX/environment.plist will probably help this one.
>
> Alas, I have no such file on my system. Nor even a ~/.MacOSX
> directory.
The developer link provided previously seems like you just have to
create the directory/file yourself.

> Unlike most of the people on this list, I have every intention of
> avoiding "other Unixes." A solution that is specific to OSX with
> greater reliability is significantly more valuable to me than one
> that applies to Unix in general but only works "most of the time"
> on OSX.
You might find more information OSX-centric mailing lists, then.
Good luck!
-Mat

Stefan Lang

7/20/2006 12:58:00 PM

0


On Thursday, July 20, 2006, at 5:08 PM, Dave Howell wrote:
>
>On Jul 18, 2006, at 8:33, Ryan Raaum wrote:
>>Configuring ~/.MacOSX/environment.plist will probably help this one.
>
>Alas, I have no such file on my system. Nor even a ~/.MacOSX directory.

From the link that was posted:

Q: How do I set environment for all processes launched by a specific user?

A: It is actually fairly simple process to set environment variables for
processes launched by a specific user.

There is a special environment file which loginwindow searches for each
time a user logs in. The environment file is: ~/.MacOSX/
environment.plist (be careful it's case sensitive). Where '~' is the
home directory of the user we are interested in.

You will have to create the .MacOSX directory yourself using terminal
(by typing mkdir .MacOSX).

You will also have to create the environment file yourself. The
environment file is actually in XML/plist format (make sure to add the
plist extension to the end of the filename or this won't work). An
example environment file is shown below. The file was created using /
Developer/Applications/PropertyListEditor.app

>
>$ cd ~/.MacOSX
>-bash: cd: /Users/dave/.MacOSX: No such file or directory




--
Posted with http://De.... Sign up and save your mailbox.

Dave Howell

7/20/2006 10:07:00 PM

0


On Jul 20, 2006, at 5:39, Mat Schaffer wrote:

> On Jul 20, 2006, at 4:08 AM, Dave Howell wrote:
>> On Jul 18, 2006, at 8:33, Ryan Raaum wrote:
>>> Configuring ~/.MacOSX/environment.plist will probably help this one.
>> Alas, I have no such file on my system. Nor even a ~/.MacOSX
>> directory.
> The developer link provided previously seems like you just have to
> create the directory/file yourself.

[sheepishly takes the time to RTFM] I just assumed that "configuring"
meant editing an existing file. Oops.

>> A solution that is specific to OSX with greater reliability is
>> significantly more valuable to me than one that applies to Unix in
>> general but only works "most of the time" on OSX.

And look, here's a more-reliable OSX-specific solution dropped in my
lap.

Thanks Ryan, and how the *heck* did you ever find out about that in the
first place?

Stefan Lang

7/21/2006 9:12:00 PM

0


On Friday, July 21, 2006, at 7:07 AM, Dave Howell wrote:
>
>On Jul 20, 2006, at 5:39, Mat Schaffer wrote:
>
>> On Jul 20, 2006, at 4:08 AM, Dave Howell wrote:
>>> On Jul 18, 2006, at 8:33, Ryan Raaum wrote:
>>>> Configuring ~/.MacOSX/environment.plist will probably help this one.
>>> Alas, I have no such file on my system. Nor even a ~/.MacOSX
>>> directory.
>> The developer link provided previously seems like you just have to
>> create the directory/file yourself.
>
>[sheepishly takes the time to RTFM] I just assumed that "configuring"
>meant editing an existing file. Oops.
>
>>> A solution that is specific to OSX with greater reliability is
>>> significantly more valuable to me than one that applies to Unix in
>>> general but only works "most of the time" on OSX.
>
>And look, here's a more-reliable OSX-specific solution dropped in my
>lap.
>
>Thanks Ryan, and how the *heck* did you ever find out about that in the
>first place?
>

Pain, frustration, aggravation, more frustration, and more pain. I have
no idea why it is not more extensively advertised in the apple docs.
But given how long it took me to find it out, it will probably be the
one piece of information I will take to my grave - long after I have
lost track of my own name, I will still know about that
environment.plist file.

Best,

-r

>




--
Posted with http://De.... Sign up and save your mailbox.

Dave Howell

7/22/2006 12:21:00 AM

0


On Jul 21, 2006, at 14:12, Ryan Raaum wrote:

>> And look, here's a more-reliable OSX-specific solution dropped in my
>> lap.

Too bad it didn't actually work.

What I want to be able to do is auto-path to ruby, by having shell
scripts start with

#!/usr/bin/env ruby

This works beautifully from the command line, but gives me 1.6.8 ruby
when I call the script from TextWrangler.

I modified my environment.plist to contain the following:

<key>PATH</key>
<string>/Library/Ruby/Bin:$PATH</string>

So what did I get for a path?

"/Library/Ruby/Bin:$PATH"

No variable expansion. Sigh. I assigned BASH_ENV the value
"/etc/profile", which is good for other things, but doesn't help this
case, because unless I specify /bin/bash, it uses an implicit /bin/sh,
which has no mechanism for specifying profiles when run
non-interactively.

So I'm back to #!/Library/ruby/bin/ruby for now, and scheming to throw
old ruby out of /usr/bin so new ruby can sit there instead the next
time this comes up. Alas.

Stefan Lang

7/22/2006 1:20:00 AM

0


On Saturday, July 22, 2006, at 9:20 AM, Dave Howell wrote:
>
>On Jul 21, 2006, at 14:12, Ryan Raaum wrote:
>
>>> And look, here's a more-reliable OSX-specific solution dropped in my
>>> lap.
>
>Too bad it didn't actually work.
>
>What I want to be able to do is auto-path to ruby, by having shell
>scripts start with
>
> #!/usr/bin/env ruby
>
>This works beautifully from the command line, but gives me 1.6.8 ruby
>when I call the script from TextWrangler.
>
>I modified my environment.plist to contain the following:
>
> <key>PATH</key>
> <string>/Library/Ruby/Bin:$PATH</string>

You're going about it backwards. If you have PATH in your
environment.plist file, then it is the ultimate source for your path -
so you should put in a fully qualified set of default paths, something like

<key>PATH</key>
<string>/Library/Ruby/bin:/bin:/sbin:/usr/bin:/usr/sbin</string>

and then if you modify your PATH in .bash_profile (or wherever) like so

export PATH=/monkey/bin:$PATH

then you will end up with an ultimate path of

/monkey/bin:/Library/Ruby/bin:/bin:/sbin:/usr/bin:/usr/sbin

at the end of the day

-r
>
>So what did I get for a path?
>
> "/Library/Ruby/Bin:$PATH"
>
>No variable expansion. Sigh. I assigned BASH_ENV the value
>"/etc/profile", which is good for other things, but doesn't help this
>case, because unless I specify /bin/bash, it uses an implicit /bin/sh,
>which has no mechanism for specifying profiles when run
>non-interactively.
>
>So I'm back to #!/Library/ruby/bin/ruby for now, and scheming to throw
>old ruby out of /usr/bin so new ruby can sit there instead the next
>time this comes up. Alas.
>
>




--
Posted with http://De.... Sign up and save your mailbox.

Dave Howell

7/24/2006 12:02:00 AM

0


On Jul 21, 2006, at 18:20, Ryan Raaum wrote:

> You're going about it backwards. If you have PATH in your
> environment.plist file, then it is the ultimate source for your path -

Well, the ultimate source for that user. What I want is for it to
respect the path as set by /etc/profile for all users, or better yet,
just find out where the Ur-path comes from, so that I can include Ruby
on the path for every shell ever created anywhere on the system
(interactively or not) by anything except when specifically excluded.

Particularly when I'm working on my server, I frequently need to switch
back and forth between my "regular" account, my "administrator"
accounts (local and domain), and the super-user account, and having all
my handy scripts, aliases, and whatnot vanish between them is
inconvenient. :/

Hmm. If there were a way to "include" my home account's
environment.plist in
/etc/profile . . . yikes.

But this is now way off topic, so I guess I'll go fiddle with RDoc some
more. :)