From: Dave H. <gr...@gr...> - 2005-05-25 09:40:22
|
On May 23, 2005, at 4:54 PM, Jonathan Paisley wrote: > A general comment about moving ruby around: it sounds like things got > initially got confused because you moved ruby to a different path > after installing it. ruby has compile-time paths embedded in it for > the standard library. Not after. I told it to install itself somewhere else in the first place. It was compiled into /Library/Ruby. > You say that it's stupid to put things in an invisible folder on a > mac. I'd argue that this is only the case if the items in question are > intended to be used from the GUI. ruby is not. The RubyCocoa > applications you may create should be GUI-accessible, but this doesn't > mean that ruby itself should be. [Danger. Rant approaching...] I must respectfully disagree. The pinnacle of good design, as Apple's guidelines support and I wholeheartedly endorse, is seen, in part, when "installation" of an application involves dragging it onto my hard drive, and de-installing involves dropping a folder in the trash. Ruby's log file belongs in Ruby's folder (or arguably in [~|]/Library/Logs/). Ruby's documentation definitely belongs in Ruby's folder. I found a RubyCocoa.framework in /Library/Frameworks, exactly where I'd expect to find such a thing, and where a Splat-F Find will turn it up. If something isn't working right, I should be able to hunt down folders and files with my mouse, not by having to open a terminal and start digging around in a foreign environment with unknown command line voodoo. (Or by starting the process via Shift-Command-G and typing the initial path.) NOTHING in the System folder is "intended to be used from the GUI." e.g. to be used by the operator (me) directly. Nevertheless, Apple didn't make the system folder invisible. The fact that they didn't manage to actually put everything in the System folder that they ought to have, that some of the files required to boot the system are wandering around loose in /sbin and other places, has caused me some grief when trying to repair corrupted drives. I can't just duplicate the System drive and the mach files. I have to include various random other directories, but not necessarily all of them. Unix's 'traditional' system of /bin, /sbin, /usr/bin, /usr/local/bin, /var, /etc (et cetera, for ghu's sake?????), and other such nonsense is an embarrassing artifact. We Know Better Now. PostgreSQL, Webmin, and OSX-vnc were all polite enough to allow me to put them where I could see them (to wit, in the /Servers folder on my server, where *I* want them to be). I don't know where Postfix or BIND actually live, since they came invisibly with the OS. So did Ruby, for that matter, which is related to the 1.8's failure to install; information about the need to reconfigure my "path" command was not part of the two or three different opinions I found on how to install it. Ruby and TeX are the only apps (so far) that offered to let me pick a place for them to install, but then failed to run unless allowed their default locations. (A much more egregious fault in TeX, since I have to keep installing new stuff in the part of the tree where local user files go.) GhostScript may or may not have also done that, since I don't know if the install I did is still there or not after a couple of OS upgrades; it installed invisibly in an unknown location. > The proper way I'm afraid I find the following definition of "proper" to be appallingly Unix-command-line-centric, and very much at odds with Apple's standards of propriety. > to identify which version of ruby you want to use (Apple's on /usr/bin > or self-installed in /usr/local/bin) is to update your PATH (using > 'setenv' for tcsh or 'export' for bash/zsh). I didn't have a path command. I didn't have a .login or .bash_login or whichever of an exasperating variety of possible invisible files I would have to have in order to be able to reconfigure my path. And apparently whatever command accomplishes that task depends on what shell I'm using, so now I have to know that too? (Which, oh, yea, *changed* from 10.2 to 10.3) Yes, indeed, which is why it took me hours of searching the web to find out how to actually get my path to change and stay changed, when a different unfriendly application required it. And should I happen to ssh in and get a different shell, or log in as a different user? On my laptop, if I write an AppleScript and include do shell script "ruby -v" it will fail, ONLY because I deleted /usr/bin/ruby. Thank God. If I hadn't, it would be invoking the old version and make debugging a bloody nightmare. (Holy Cow. If, instead, I try $ osascript -e 'do shell script "ruby -v" ' then I get ruby 1.8.2. ) No, that can only reaffirm my belief that obliterating or replacing the 'old' Ruby is the only smart thing to do. If I absolutely destroy it, then it can't surprise me later. And I don't need to Google up the secret to deleting files. I just had to figure out where Apple hid their Ruby in the first place. > It should never be necessary to modify some Apple-installed system > files (like /usr/bin/ruby). And if installing a 'newer' version of Ruby had gone as expected, I wouldn't have had to. When I install Word 2003, I expect that, even if Word 2001 remains on my drive, my files will now use the newer version. When I install OSX 10.3, I expect 10.2 to be overwritten. When I install Ruby 1.8.2, I expect to get Ruby 1.8.2 when I type "ruby." (cd /usr/bin; rm /ruby; ln /usr/local/bin/ruby) There. NOW my install is actually right. Except for some unknown amount of 1.6.8 stuff still hiding out, er, somewhere. So now I have a "textbook" 1.8.2 install on my laptop that didn't actually install itself correctly (by overwriting or moving 1.6.x) which means that the Installer.dmg that somebody made for RubyCocoa can't be used on 1.8.2. This may or may not also be what's preventing RubyCocoa from installing correctly; I don't know, and I don't know of any way to definitively uninstall 1.6.8, since there's no uninstaller, and I can't just throw away a folder named "Ruby 1.6.8". What little I've managed to get done with Ruby so far has made me like it a lot. Good thing, since I haven't had a single ruby-related system yet install itself in a way that resulted in working software. Not Ruby, not RubyCocoa, not RubyOnRails. Well, it could be worse. Gimp/GhostScript/Foomatic is a friggin' nightmare.... |