[MacOS X] finding the orig file of an alias

[Une bévue]

for the time being i'm using the finder thru AppleScript and then aeosa
in order to find the original path of an alias.

that's time consuming ))

does exist a direct rubyish way to do that (as in perl for ex.) ?

 

[Logan Capaldo]

for the time being i'm using the finder thru AppleScript and then =20
aeosa
in order to find the original path of an alias.

that's time consuming ))

does exist a direct rubyish way to do that (as in perl for ex.) ?
--=20
une b=E9vue

You might be able to use RubyCocoa to do it a little more directly.=

 

[Dave Howell]

from ruby side.

if writing :

fm=OSX::NSFileManager.defaultManager

i get :

NameError: uninitialized constant OSX::NSFileManager

That's odd. I got this:

irb(main):002:0> require 'osx/aeosa'
=> true
irb(main):003:0> require 'osx/cocoa'
=> true
irb(main):004:0> fm=OSX::NSFileManager.defaultManager
=> #<OSX::NSFileManager:0x2fc3e0 class='NSFileManager' id=0x434470>
irb(main):005:0>

Did you require 'osx/cocoa'?

 

[Dave Howell]

first, how to get the constant : "kCFURLPOSIXPathStyle" ? (I've put
0...)
second how to call the method "CFURLCreateWithFileSystemPath" ?

Oh, yea, I forgot to mention that the fastest place to find answers to
these questions would be on the rubycocoa-talk mailing list....

 

[Une bévue]

Oh, yea, I forgot to mention that the fastest place to find answers to
these questions would be on the rubycocoa-talk mailing list....

they have a tendancy, fo such a question, to direct me by Cocoa-Dev ))

 

[Une bévue]

irb(main):004:0> fm=OSX::NSFileManager.defaultManager
=> #<OSX::NSFileManager:0x2fc3e0 class='NSFileManager' id=0x434470>
irb(main):005:0>

ok thanx

Did you require 'osx/cocoa'?

generally speaking yes, both of them (rubycocoa and aeosa).

but in a small trying script i might have forgot this "small detail" )))

 

[Une bévue]

Did you require 'osx/cocoa'?

not at all, i'm sure about that ))

because, when :
require 'osx/cocoa'

i get an error within my text editor (TextMate) or at terminal :

LoadError: no such file to load -- rubycocoa
method gem_original_require
in custom_require.rb at line 27
method require
in custom_require.rb at line 27
at top level
in cocoa.rb at line 11
method require
in custom_require.rb at line 27
at top level
in read-alias.rb at line 5

when using "require 'osx/cocoa'" within XCode : no prob...

 

[Dave Howell]

not at all, i'm sure about that ))

because, when :
require 'osx/cocoa'

i get an error within my text editor (TextMate) or at terminal :

LoadError: no such file to load -- rubycocoa

when using "require 'osx/cocoa'" within XCode : no prob...

Hmm. I suspect if you hunt around in ~/Library/Frameworks or=20
/Library/Frameworks, you'll find the RubyCocoa framework. Which is to=20
say, nowhere on your command-line path directories, but exactly where=20
Cocoa apps expect to find such things.

Based on the misery I've experienced in this situation, were I you, I=20
would now try to wipe every last trace of RubyCocoa off my system, then=20=

do a new install in order to get *one* copy of RubyCocoa that's visible=20=

to all the different ways you can run Ruby.

If you don't wipe it first, then you can easily get in a situation=20
where the command line is running a *different* version of RubyCocoa=20
than XCode, and that's hideous to debug.

Trust me on that one.

 

[Dave Howell]

i've tried several times having the same setup for ruby from command
line and from XCode, and i've learned today darwinports isn't the
best...

what kind of install would you advice ?

from cvs sources ?

PS : on RubyCocoa list they advice me to use dp )))

Yes, people are always telling me about the lovely powers of
Darwinports/Fink/CVS/Gem and on and on. I don't believe them any more,
though. (Well, RubyGems has worked reasonably well for those things
that are available as gems.)

My current RubyCocoa (and Ruby 1.8.4) was installed by downloading a
tar.gz file or some such thing, and running
./configure
make
make install

Whatever that's called. Is that the best way? I have no idea. But it
did let me put things exactly where I wanted them, which for me, meant
that all my Ruby junk is in the highly visible /Library/Ruby, not in
/usr/local/whatever or /sw/someplace or /opt/secret/hiding/spot.
(Although I did get to discover that some part of the RubyCocoa
installer couldn't cope with installing from a path with spaces in it.
That's been fixed.)

And it seems to work, which is more than I can say for 66% of my
attempted Fink installs and 100% of my DarwinPorts attempts. I haven't
tried any CVS-ing yet, because I'm allergic to unripe software in
general.

 

[Phillip Hutchings]

I can't help you with calling the CF functions, the rubycocoa list
might know more

i seems that "OSX::NSFileManager.defaultManager" couldn't do the
trick...

Unfortunately Cocoa can't actually handle aliases itself, you need to
use other functions. Google for 'Cocoa alias resolve', there's a few
informative pages.

 

[Une bévue]

Unfortunately Cocoa can't actually handle aliases itself, you need to
use other functions. Google for 'Cocoa alias resolve', there's a few
informative pages.

fine thanx, i've found something by googleing...

this is at <http://bdistributed.com/Projects/BDAlias/>

they have implemented a class following Apple's rcomandation :
<http://developer.apple.com/documentation/Cocoa/Conceptual/LowLevelFileM
gmt/Tasks/ResolvingAliases.html>

(that's the BDAlias#fullPath method calling #fullPathRelativeToPath:nil)

here is my little test :

require 'osx/cocoa'

OSX.ns_import('BDAlias')
f=OSX::BDAlias.alloc.initWithPath("/Users/yvon/work/RubyCocoa/MacSOUPSwi
tcher/map/read-alias/search/for/the/original/file/read-alias.pl")
p "f.class=#{f.class}"
# => "f.class=OSX::BDAlias"
p "f.fullPath=#{f.fullPath}"
# =>
"f.fullPath=/Users/yvon/work/RubyCocoa/MacSOUPSwitcher/map/read-alias/se
arch/for/the/original/file/read-alias.pl"

using BDAlias from ruby works very well however the return path isn't
the path of the file pointed by the alias rather the path of the alias
itself )))

i've compared ObjC version of BDAlias versus Apple's recomandation :
looks good...

then, i don't understand why this desapointing result...

something i misunderstood ???

 

[Luc Heinrich]

something i misunderstood ???

Yes. The BDAlias class does not support resolving existing aliases, =20
it allows to create alias record to provide persistent file =20
references which can be better then simple pathnames in some cases. =20
Just look at the source code or, even better, read the documentation, =20=

it's all explained there :>

--=20
Luc Heinrich - (e-mail address removed) - http://www.honk-honk.com

 

[Une bévue]

Yes. The BDAlias class does not support resolving existing aliases,
it allows to create alias record to provide persistent file
references which can be better then simple pathnames in some cases.
Just look at the source code or, even better, read the documentation,
it's all explained there :>

then i misunderstood also the Apple's page :
<http://developer.apple.com/documentation/Cocoa/Conceptual/LowLevelFileM
gmt/Tasks/ResolvingAliases.html> ???

BDAlias and this are using about the same methods.

 

[Luc Heinrich]

then i misunderstood also the Apple's page :
<http://developer.apple.com/documentation/Cocoa/Conceptual/=20
LowLevelFileM
gmt/Tasks/ResolvingAliases.html> ???

BDAlias and this are using about the same methods.

...to resolve the alias record *you* create in the initWithXXX or =20
aliasWithXXX methods, not existing aliases.

--=20
Luc Heinrich - (e-mail address removed) - http://www.honk-honk.com

 

[Une bévue]

..to resolve the alias record *you* create in the initWithXXX or
aliasWithXXX methods, not existing aliases.

i understood : alias record != alias file )))