0

I have a Perl script that creates files, and I want to write into their resource forks, in order to specify the default application they should be opened with (I can't just change it using get information in Finder, it keeps reverting).

I could find out about Apple's arcane resource fork stuff, but for my purposes I'm happy to read the data from an existing resource fork that opens with the right application, and hard-code it into my script. The trouble is, I'm too new to Perl to know how to read the hex numbers from the file, copy and paste it into my script, and have it written correctly as hex into my new .rsrc files.

I want to do something like:

my $theHex="DEADBEEF" #<---this is where I would paste the hex from the existing rsrc file
open (OUT, ">$filename/rsrc"); #<--this is the resource fork for file $filename
printf OUT "%x" $theHex #<----I'm not sure that this formatting is right

Edit: Yes I know, resource forks are deprecated. Please tell that to Apple so they can stop using them in their OS to determine things like what application opens a particular file. Sheesh!

stib
  • 3,346
  • 2
  • 30
  • 38
  • 1
    None of this makes any sense. MacOS filesystems haven't had resource forks in ten years. Are you talking about a "Resources" directory within an application bundle? What do you mean by "read the hex from the file?" – friedo Jul 04 '11 at 03:34
  • 1
    @friedo: Weren't resource forks finally killed off in Snow Leopard but just deprecated before that? – mu is too short Jul 04 '11 at 03:47
  • 1
    @friedo: Wrong. They still exist, and they still get used by the system and by applications such as Firefox. Try going to a directory full of different files and trying 'for i in *;do ls "$i/rsrc";done' and you'll see plenty of the suckers. – stib Jul 04 '11 at 05:30

2 Answers2

1

You have a couple problems in that code. First of all, you need a comma after your format string:

printf OUT "%x", $theHex

Now that we have some syntactically valid source code, we can move on to your real problem. The %x format string for printf expects to be given an integer but you're giving it a non-numeric string. When the string value of $theHex is converted to an integer, you'll get zero. The fix for this is easy, you just need to properly initialize $theHex:

my $theHex = 0xDEADBEEF;

The "0x" prefix tells Perl that you're writing the number as hex; similarly, a zero prefix (e.g. 0666) indicates octal.

Now you have a hexadecimal string representation of your 0xDEADBEEF integer.

If you just want to copy four bytes from one resource fork to another, then you're better off using read to read four raw bytes and then use print to write those bytes to the other resource fork.

You might want to have a look at pack if you're slinging bags'o'bytes around. AFAIK, the resource fork wants four bytes rather than an eight byte human readable hexadecimal representation of a four byte integer.

mu is too short
  • 426,620
  • 70
  • 833
  • 800
  • Thanks for that (+1 for not lecturing me about resource forks being deprecated). Now the other half of my problem is working out a way of reading the data from the rsrc file so that I can paste it into my code. Every method I have thought of for reading this data always ends up turning the numbers into ascii. Is there a simple way of reading hex from a file and displaying it as something I can copy and paste to substitute for 0xDEADBEEF? – stib Jul 04 '11 at 05:02
  • 1
    @stib: Use `read` to read the four bytes, `pack` to convert them to an unsigned integer, and `printf` to get that integer as a nice hex value that you can stick in your script. – mu is too short Jul 04 '11 at 05:09
  • Thanks for the advice about read and pack, I'm researching them now. However the rsrc file is more than 4 bytes. Is there a something like read that works on variable length input? using 'cat thefile.foo/rsrc|xxd' tells me that it's a bit more than 1Kb long. – stib Jul 04 '11 at 05:28
  • @stib: If you know the offset you can use [`seek`](http://perldoc.perl.org/functions/seek.html) and then `read`. Or you could read the whole thing into a scalar (use `-s $file` to get the size first). – mu is too short Jul 04 '11 at 05:33
  • there seems to be some sort of buffer overflow thing going on. If I read it thus: 'read IN $buffer, 1338' (1338 is the length given by -s) it equates to 65536 or 0x10000. I don't think this is right. – stib Jul 04 '11 at 06:54
  • Too much for my poor ol' head. I think I'm just going to have to do it the kludgy way. Make a file with the right resource fork, and then run this shell script on my created files: 'for i in *;do cat /the/dummy/file.foo/rsrc>"$i/rsrc";done' This works but t'aint exackerly elegant. – stib Jul 04 '11 at 06:58
  • @stib: You're probably unpacking the wrong bytes, 65536 is a highly suspicious number. As far as your shell script hack goes: Nothing that works is silly. – mu is too short Jul 04 '11 at 07:06
0

Mac OS X still has resource forks, but they've been deprecated for years. Resources don't play well with other operating systems. This tended to make Macs not play well with others and thus isolated Macs into little islands by themselves.

Resource forks were mainly used with executables, but a Mac OS X application is really a folder (aka bundle) that contains the resources inside of it.

Data files could have resource forks, but most did not. If they did, it was mainly to implement the APPL/TYPE resources to say what the file type was and the application to open it. Now, Mac OS X uses file suffixes. It's not as neat as resource forks, but it's a lot more compatible with other applications.

However, if you really want to futz with resource forks and other Mac oddements, take a look at CPAN::Mac-Carbon. That'll give you what you need.

NOTE!!

This is Mac-Carbon which means this will go bye-bye with Lion. Much of this is from the old System 6/7/8/9 days before Mac OS X, and some of this Mac OS X retained for compatibility purposes.

Community
  • 1
  • 1
David W.
  • 105,218
  • 39
  • 216
  • 337
  • 1
    I realise they've been deprecated for years, but that doesn't mean they don't get used by the OS to do stuff like determine what application opens a particular file. See this for an example of resource forks being used when opening .webloc files: http://superuser.com/questions/303710/osx-some-weblocs-open-in-firefox-some-dont-wtf – stib Jul 04 '11 at 04:44
  • Well, CPAN::Mac-Carbon is the way to go if you need to futz with the resource fork. I am not sure if it's really used though. According to the post you linked to, the .webloc file use to use the resource fork, but now is just a simple plist. Come Lion, it's completely obsolete. IN fact, in Snow Leopard, it's [obsolete](http://www.macworld.com/article/142937/2009/09/snowfiles.html). See [Launch Services](http://developer.apple.com/library/mac/#documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCIntro/LSCIntro.html) on how it should be done. – David W. Jul 04 '11 at 14:24
  • 1
    Firefox still uses the resource fork - it ignores the contents of the plist completely. That's why I'm doing this - I want my bookmarks to be searchable through spotlight. – stib Jul 05 '11 at 04:20