Re: Mac::Glue and aliases
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jeff Lowrey) wrote: > So it's easy enough to get the file for a song, I just ask iTunes > for the location of the file track... > my $iTunes = Mac::Glue->new("iTunes"); > my $alias = $iTunes->obj(location, > of=>file_track=>gFirst=>of=>library_playlist=>name=>"Library"); > > This is equivalent to the AppleScript > tell application "iTunes" > set myAlias to get location of first file track of library > playlist "Library" > end tell Are you sure about that? I think it is more like the equivalent of: set myAlias to location "of" of first file track of "library_playlist" of name "Library" or something. "of" is the comma, and you don't need to add in extra ones.* So that's the first problem. Another problem above is that gFirst looks like it is being passed as a string, when it is a subroutine constant. Also, location is being used as a bareword. And I am not sure what "name" is doing there. The way these "obj" things work is that you have key value pairs, where the key is the class (although properties will not have values). To get: set myAlias to get location of first file track of library playlist "Library" You break down the pairs into: key value = == location none (property) file trackfirst library playlist "Library" And this becomes: my $alias = $iTunes->prop(location => file_track => 1, library_playlist => "Library" ); prop() is merely shorthand for what is actually in the Apple event, which is that "location" is the value for the class "property". So you can do obj(property => "location") or prop("location"). And we could also do gFirst there, as long as we make sure it is not followed by the autoquoting => or that it has & or () on it. But "1" is the same thing, so I use that. And then once you get $alias, just call ->get on it. The get() method is when you actually retrieve the value; prop/obj is just building the data structures. In AppleScript, "get" is often implicit, though that might depend on the context, but we don't want it to be implicit, as you might want to save your constructed object to use in multiple places, rather than having a value. So, you need get. And that's all you need. > Now I want to do the equivalent of the Applescript > get quoted form of POSIX path of myAlias You don't need to request the POSIX path or anything. The location is an alias, but Mac::Glue converts that to the native path representation automatically with get(). And here's my version: use Mac::Glue; my $iTunes = Mac::Glue->new("iTunes"); my $alias = $iTunes->prop(location => file_track => 1, library_playlist => "Library" ); print $alias->get; Hope that helps clear some things up. Ask away if you have any trouble. [*] I think the only time you need an "of" is when you are asking for a property of a property, such as "name of startup disk", where "startup disk" is a property of the application "Finder". Then you might do $finder->prop(name => of => startup_disk), but you could also be cool and do $finder->prop('startup_disk')->prop('name') (with recent versions of Mac::Glue that have the new syntax that allows you to call the parent glue's methods on object descriptors, such as those created by obj/prop). -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: opening files whose names contain CRs?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Doug McNutt) wrote: > The cat operation creates a text file with "foo" in the data, and only, fork. > > Rich's problem is "opening" Icon\r files which are surely from Classic icon > resource files zB (using MPW on a 9.1 box): Yes, but he also was asking generally of how to handle files with the CR in them. And I was just making the point that it is not OS-specific, and you can use nulls or sysopen. Actually, I think there is another good way, too: $ perl -e 'open $fh, "<", "Icon\r" or die $!' Yeah, three-arg open, which doesn't have the "magic" of two-arg open. But yes, to get the actual data, you need the resource fork, using either Mac::Resources or similar, or opening namedfork/rsrc/: $ perl -e 'open $fh, "<", "Icon\r/..namedfork/rsrc" or die $!' > If 'Icon'n'' is opened in perl in OS neXt, will perl read from the resource > fork if there is no data fork? Or will it fail to open? This isn't specific to Mac OS X, it is handled by the OS. open() and friends always open the data fork, unless passed a ..namedfork sort of thing (or unless you use POSIX open with the O_RSRC flag, which works on Mac OS, but NOT on Mac OS X, which is kinda weird, as it seems like it would be of use). It will succeed on the open, but there will be no data. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: opening files whose names contain CRs?
At 07:19 -0700 9/15/03, Chris Nandor wrote, and I snipped: > $ cat > Icon^M > foo > ^C > $ perl -e 'open $fh, "Icon\r" or die $!; print scalar <$fh>' > No such file or directory at -e line 1. > # add null > $ perl -e 'open $fh, "Icon\r\0" or die $!; print scalar <$fh>' > foo The cat operation creates a text file with "foo" in the data, and only, fork. Rich's problem is "opening" Icon\r files which are surely from Classic icon resource files zB (using MPW on a 9.1 box): directory Ganymede: files -x br 'Icon'n'' ### "OPTION-d n" is a return character in classic. NameData Sz Rsrc Sz 'Icon'n'' 0b 1982b If 'Icon'n'' is opened in perl in OS neXt, will perl read from the resource fork if there is no data fork? Or will it fail to open? What about a write-enabled open? Will it write to the end of the resource fork or will it create a data fork? $ perl -e 'open $fh, ">>Icon\r\0" or die' -- Applescript syntax is like English spelling: Roughly, but not thoroughly, thought through.
Re: opening files whose names contain CRs?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Peter N Lewis) wrote: > At 7:23 PM -0700 13/9/03, Rich Morin wrote: > >This is interesting, but it doesn't answer the question of how one > >opens a file with this sort of name weirdness. Basically, I think > >I've found a bug. Prolly should check for it in Panther... > > There is no problem with opening a file with a CR in its name. > > The problem is only with a file who ends in any sequence of carriage > returns or line feeds. It would appear these are stripped from the > file name by perl (presumably trying to be helpful so you can open a > file even if the name is read from a file and you forget to chomp it). Yes, open() is "magic" and will open files similarly to if you passed it the name in the shell. The solution is to use sysopen(), or to add a null to the end of the filename. $ cat > Icon^M foo ^C $ perl -e 'open $fh, "Icon\r" or die $!; print scalar <$fh>' No such file or directory at -e line 1. # add null $ perl -e 'open $fh, "Icon\r\0" or die $!; print scalar <$fh>' foo # use sysopen $ perl -e 'sysopen $fh, "Icon\r", 0 or die $!; print scalar <$fh>' foo $ -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Mac::Glue and aliases
So maybe I'm going about this the wrong way (well, probably). I need to play around with the ID3 tags of some songs in my iTunes library. So I want to get the path to an actual file for a particular song, and then do stuff with the file. So it's easy enough to get the file for a song, I just ask iTunes for the location of the file track... my $iTunes = Mac::Glue->new("iTunes"); my $alias = $iTunes->obj(location, of=>file_track=>gFirst=>of=>library_playlist=>name=>"Library"); This is equivalent to the AppleScript tell application "iTunes" set myAlias to get location of first file track of library playlist "Library" end tell Now I want to do the equivalent of the Applescript get quoted form of POSIX path of myAlias And I'm stuck. I can get an Mac::AEObjDesc just fine my $path = $alias->obj(quoted_form,of=>posix_path); But I can't seem to find the right way to get the string back from that. And putting it into string context doesn't seem to work (at least not with the concatenation operator). And 'as=>"string"' doesn't work. And and and... Any suggestions? -Jeff Lowrey