Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Work with resource forks in the Terminal UNIX
While visiting a friend the other night, he showed me a trick in the terminal that I hadn't seen before, and I'm pretty sure hasn't been mentioned here as of yet. I'm also not sure of the usefulness of this trick, but it is interesting.

You can work with the resource fork for any file by simply adding "/rsrc" to the end of some file handling commands. For example, you could use this method to see which files within a directory contain resource forks:
% ls -al */rsrc
-rw-r--r-- 1 robg staff 0 Apr 25 2001 top.term/rsrc
-rwx---rwx 1 robg staff 0 Nov 21 22:33 travel.pdf/rsrc
You can also use this flag on "cat" and "cp" commands, allowing you to display (not very useful) or copy the resource fork of a given file.

I'm not sure how long this has been there, nor if the Developer Tools are required or not, but perhaps someone can find a good use for this modifier.
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)

Work with resource forks in the Terminal | 5 comments | Create New Account
Click here to return to the 'Work with resource forks in the Terminal' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
more /rsrc info
Authored by: maclaw on Feb 24, '02 03:00:27PM

The /rsrc convention has been used all along in OS X and is not dependent on the developer's tools. Anyone with a BSD install can type ls -l */rsrc and see the (normally hidden) resource forks, or ls -l * */rsrc to see the visible data files with their accompanying resource fork, if any.

This is the reason why it is necessary to use "ditto -rsrc" when copying a folder that contains classic-style mac documents or applications. Mac files have historically been two files bound together (an overly simple explanation). Because Unix does not use resource forks, the standard Unix command "cp" will only copy the visible data file ("fork") but not retain the accompanying resource file ("fork"). This will render a classic app useless (menus and the such are often contained in a resource fork) and will probably strip your document files of various preference info such as creator, type, last window position, etc.

ditto -rsrc does not require the developer's tools -- it is included with the standard BSD install. If you have installed the developer's tools, you will also have CpMac and MvMac which are resource-fork-aware versions of cp and mv.

[ Reply to This | # ]
more /rsrc info
Authored by: ret on Feb 25, '02 03:03:11AM

I have been caught by this before - using cp and losing the resource info. So are there any inherent issues in aliasing or soft-linking cp and mv to CpMac and MvMac so that they are always used in preference to /bin/cp and /bin/mv?

[ Reply to This | # ]
more /rsrc info
Authored by: mervTormel on Feb 25, '02 03:21:08AM

beware! CpMac and MvMac seem to be deprecated tools with no docs and very wonky results.

probably best to use ditto for all your sundry file needs. it works well, is documented and supported.

[ Reply to This | # ]
more /rsrc info
Authored by: tochoa on Feb 25, '02 11:11:20PM

Yes- CpMac and MvMac are useful, but beware of using them with a -r switch on directory copying / moving. They will make all dot files you've moved visible at the destination. So soft linking them to cp and mv, is not a good idea! Better to use these cl tools on individual files, that you know will have resource forks (an example would be files that open in classic only applications, such as Quark.)

[ Reply to This | # ]
more /rsrc info
Authored by: daniel_steffen on Feb 25, '02 11:57:09AM
note that foo/rsrc is obsolete and might go away in the future, the official [1] way to access forked files in HFS+ is via foo/..namedfork/forkname, most files only have foo/..namedfork/data and foo/..namedfork/rsrc, but HFS+ supports an unlimited number of named forks, which can be created using the FSCreateResourceFile Carbon API [2].

[ Reply to This | # ]